Cannot list .uc2 files when using uc.pif

[petermad]

As Subject says - for further information see: http://ghisler.ch/board/viewtopic.php?p=187968#187968

[ghisler(Author)]

You shouldn't put uc.pif in the "packer name" field. uc.pif is used by Windows automatically when a 16-bit program uc.exe is started. Windows then looks for uc.pif in program dir, and then in the path.

[petermad]

OK - I still find it peculiar that using the pif file in the packer name field works for all the other external packers, and for uc.exe except for listing files.

And can you explain why using relative path in the packer name field also works for all packers except for file listing with uc.exe ? It seems to be related ??

If I place uc.exe in %COMMANDER_PATH%\packers folder and write packers\uc.exe in the packer name field, then listing of .uc2 files doesn't work, but I can still pack and unpack .uc2 files. If I write %COMMANDER_PATH%\packers\uc.exe everything works.

If I on the other hand place uc.exe directly in TC's program folder and only write uc.exe in the packer name field - everything works too.

[Clo]

+2petermad

Hello Peter !

• Here I've :

[Packer]
UC2=C:\compress\UC.EXE

with the files :

UC.EXE 121,2 Kio 08/01/2002 03:05 -a--
AIP-NL.INI 504 o 08/01/2002 03:05 -a--
UC2ERROR.LOG 691 o 03/04/2006 11:59 -a--

and

E:\Windows\UC.PIF 2,7 Kio 04/10/2009 08:28 -a--

My TC 7.50a folder is

E:\TC_7-03_beta\…

- Thus, three different locations, but still that works as expected…

…If I on the other hand place uc.exe directly in TC's program folder and only write uc.exe in the packer name field - everything works too.

• That isn't surprising. AFAIK, when you call any executable (EXE - DLL etc) from a Delphi programme,
it looks for it into its own directory prior. I did so for my old Hélios HTML editor having a hitch with some XP-Pro DLLs…

 FR
Claude
Clo

[ghisler(Author)]

It works for other packers when the program is either somewhere in the path, or stored in the registry (app paths).

[petermad]

2Clo
That is not what I am talking about - I can make uc work by writing the full path to uc.exe, but not by writing the relative path (I have my packers in a subdir to TC.

2ghisler(Author)
I have none of my other packers (arj, lha, rar, ace, pkunzip) in either the path environment variable or in the Windows registry - and they all work just by using the relative path in the configuration. Even uc.exe works for packing (Alt+F9) and unpacking (Alt+Shift+F9) but just not for listing the content of the archive (Enter/Ctrl+PgDn/doubleclick) !

This is what I am talking about: http://madsenworld.dk/tcmd/uc_exe.png The red circled field does not work for listing files - it works for the other packers.

[karlchen]

Hello, petermad.

I am not sure what you are complaining about.

ARJ-packer ENTER the name and path of your ARJ-packer (ARJ.EXE)
[..]
LHA-packer ENTER the name and path of your LHA-packer (lha.exe).
[..]
RAR-packer ENTER the name and path of the RAR-packer (rar.exe).
[..]
UC2-packer ENTER the name and path of your UC2-packer (uc.exe).
[..]
ACE (>= 1.2b) ENTER the name and path of the ACE-packer (ace.exe or ace32.exe)

And let me add that in these cases the German help is more precise, because it clearly states for all external packers: ENTER the name and full path of the xyz-packer.

Entering relative path names is unsafe, because you cannot be sure what the current folder will be when you invoke the external packer. So assuming that relative means relative to %COMMANDER_PATH% is somewhat starry-eyed.

If this works in a lot of cases, fine. In these cases you are lucky, because for whichever reason, the current folder seems to be %COMMANDER_PATH% when you invoke the packers. This does, however, not mean that you should and can depend on this coincidence.

Simply prefix %COMMANDER_PATH%\ to all your packer names and be happy. Using absolute pathnames is the only reliable and correct way.

Kind regards,
Karl

[petermad]

So assuming that relative means relative to %COMMANDER_PATH% is somewhat starry-eyed.

Off course relative should always mean relative to %COMMANDER_PATH% - anything else wouldn't make sence.

Anyway I have realized that listing archives is done internally from totalcmd.exe (except for uc2 files), so that is why I always get the listing for all the other packers no matter what I write in the options fields, and no matter whether I chose "Use internal un-XXX if possible" or not

That was my mistake - I thought TC used either external programs or the shipped .dll to get the listings - but I see now that that is not the case.

[karlchen]

So assuming that relative means relative to %COMMANDER_PATH% is somewhat starry-eyed.

Off course relative should always mean relative to %COMMANDER_PATH% - anything else wouldn't make sence.

It is true that Christian might have implemented it this way thus breaking the general rule that relative path specifications are interpreted relative to the current working folder. But he has not done so.

Karl