[TC 8.0 x64 all betas] Missing internal ACE unpacker

[petermad]

In TC 8.0 x64 there is no dll file corresponding the 32bit version's UNACEV2.DLL - hence internal unpacking is not supported in the x64 version, but it is still mentioned in the Help file:

ACE (>= 1.2b) ENTER the name and path of the ACE-packer (ace.exe or ace32.exe). It will create files with the extension '.ace'. You need ACE version 1.2b or later.
Use internal un-ACE if possible
Use UnACEv2.DLL which comes with Total Commander

[mame]

Not sure if this is the place to post this, it's not really a reply but related.

UnACEv2.DLL is 32-bit DLL, doesn't work with 64-bit TC, hence:

1. UnACEv2.DLL is written by original author, not TC author. If he's not going to write a new DLL, it's not the latter's obligation...
2. That opens the possibility of a third party to produce something (eg. Wrapper DLL* for UnACEv2.DLL, or Wrapper Plugin for ACE32.EXE (like MultiArc))
3. Otherwise, ACE format will be as good as dead format as UC2 in the 64-bit world. Nevertheless some people already suggested the format as dead long ago in 2005.

As of now, I can no longer read ACE archives on my 64-bit TC:
- ACE32.EXE v2.04 crashed (not TC bug)
- ACE32.EXE v260 treats TC parameters erroneously (not TC bug)
- UnACEv2.DLL not supported (not TC bug)

32-bit TC with UnACEv2.DLL on 64-bit Windows still works, obviously.

* Wrapper DLL: I'm not sure if such thing already exist for 64bit-loading-32bit DLL. I get the idea from Linux MadWiFi driver, a wrapper for Windows SYS driver.

Also I'm not sure if UnACE source code is/was available, as in UnRAR or UnARJ but I never heard of one...

Question: Will ACE format will continue to be supported in the future 64-bit?

[ghisler(Author)]

Try using Winace.exe as external packer/unpacker.

[mame]

Found a workaround!

- I don't want to install WinACE on Win x64 ...
- ace32.exe 2.60 has bug...
- ace32.exe 2.04 crashed on mine ...

Actually all needed is:
- Configure TC not to use internal Un-ACE ...
- ace32.exe 2.04
- set compatibility bit on ace32.exe property (win9x/winxp all works)
- Done!

[petermad]

- Configure TC not to use internal Un-ACE ...
- ace32.exe 2.04 Exclamation
- set compatibility bit on ace32.exe property (win9x/winxp all works)
- Done!

Hmm, here it is the opposite - Here ace32.exe v. 2.04 works in TC x64 out of the box, but if I change the comptability setting to for example "Windows 95" or "Windows XP (Service Pack 3)", then TC gives this message:

Cannot find external pack program! You need to install and configure an external packer to handle this specific archive.

But if I run ace32.exe without comptability setting, it almost works alright - I can pack, unpack, delete files and add files, but I cannot read or edit files (F3 or F4), because the file is unpacked to the current directory where the .ace file is located in stead of into the temp dir. This is the same for the 32bit version.

[mame]

Seems like an ACE bug to me, not TC.

Like you said before, v2.04 works on your's so doesn't need comp. mode. While on mine it didn't work, unless comp. mode is set.

So I guess for everybody else, one way or the other will work.

I rest my case.

[ghisler(Author)]

Yes, it's obviously a bug in ace32.exe. Using winace.exe works just fine.

[petermad]

Using winace.exe works just fine.

But unfortunately winace isnt excatly portable (or free).

As I wrote, here on my Win 7 x64 computer ace32.ex v. 2.04 works just as good in my TC x64 as in the 32bit version, but in both instances using F3 or F4 inside an ace archive doesn't work because the file is unpacked to the current directory where the .ace file is located in stead of into the temp dir where lister expects to find it.

Is that something that could be fixed for both 32bit and 64 bit TC

[mame]

Using winace.exe works just fine.

But unfortunately winace isnt excatly portable (or free).

Exactly my point. ACE32.EXE is portable and will work without ACE.KEY (only it will mark the archive *UNREGISTERED*)

...because the file is unpacked to the current directory where the .ace file is located in stead of into the temp dir where lister expects to find it.

You will need an ACE.CFG in the same dir as ACE32.EXE, and configure a 'TempDir' environment. Mine works fine (Lister F3 on a file in archive extracts to %TEMP%\_tc).

Code: Select all

[Archives]
....

[Files, Directories]
TempDir = %TEMP% 

To create the file, initially I run ACE32 in full-screen mode, save setup. Then edited the ascii file by hand, put the required lines.

One more bug in ACE:
You can't set read-only attribute on ACE.KEY if you have one, otherwise it reverts to unregistered. That includes read-only UNC path or CD-ROM. In my case, a read-only USB stick didn't work too.

Hope this helps.

[petermad]

You will need an ACE.CFG in the same dir as ACE32.EXE, and configure a 'TempDir' environment. Mine works fine (Lister F3 on a file in archive extracts to %TEMP%\_tc).

Code:
[Archives]
....

[Files, Directories]
TempDir = %TEMP%

I already did that !!! - but it ONLY works if I happen to have the %TEMP%\_tc folder opened in the opposite panel.

I my previous post I wrote that the file is unpacked to the current directory - that is not correct - it is unpacked to the directory that happen to be open in the opposite panel - that's why it works when I have %TEMP%\_tc in the opposite panel.

Mine works fine (Lister F3 on a file in archive extracts to %TEMP%\_tc).

Are you talking about 32bit TC or 64bit TC here - and if it is 32bit TC you are referring to, are you 100% sure you have disabled "Use internal un-ACE if possible"?

[mame]

Sorry for the mess, peter. It is really a mess.

I already did that !!! - but it ONLY works if I happen to have the %TEMP%\_tc folder opened in the opposite panel

Not to me. Actually, it doesn't work. See below.

I my previous post I wrote that the file is unpacked to the current directory - that is not correct - it is unpacked to the directory that happen to be open in the opposite panel - that's why it works when I have %TEMP%\_tc in the opposite panel.

In my case, sometimes it unpacks to *current dir*, sometimes to %TEMP%, sometimes %TEMP%\_tc (the opposite panel was tried w/different options).
* Here I feel like it's TC doing something wrong, not ACE32...

Are you talking about 32bit TC or 64bit TC here - and if it is 32bit TC you are referring to, are you 100% sure you have disabled "Use internal un-ACE if possible"?

I might have *mistaken* of the multiple installations, and might have run the 32-bit EXE by mistake. Sorry for that (I was concentrating to try to make ace32.exe works).

Yes, internal un-ACE was disabled all the time.

I tried multiple configs in ace.cfg (%TEMP%, %TEMP%\_tc, full_path\_tc, while making sure TC is using _tc of course) almost every different config gives different result, also confirmed your tests that unpacking while the other panel was different, indeed gave different results every time. Looks like somewhat there's TC mishandling too, somewhere. If Ghisler decides not to support ace32.exe anymore, then I give up, since it becomes very unpredictable. Who uses ace anymore right?

So my results as of now:
- ace32.exe works (compatibility mode)
- in TC/32 on Win/64 works
- in TC64/Win64 NOT WORK (unpredictable results)

So now you, me, back to square one.

Using winace.exe works just fine.

Oww.

[Romaschka]

Yes, it's obviously a bug in ace32.exe. Using winace.exe works just fine.

Hi!
We have no winace in our enviroment...

TC 8.01 x86 works fine, TC 8.01 x64 seems to have a bug, because you can't unpack ACE archives with a stock installation and internal un-ACE. Does't matter, if TC uses libraries of other programer or not, if you tell, you can unpack ACE archives, you should be able to do this.

Romaschka.

[ghisler(Author)]

Unfortunately there is no 64-bit unace dll available, and no source code. Therefore you will need to use the 32-bit version of TC if you need to handle ACE unpacking.