Total Commander

ghisler,
It seems that you need to add to that project some C/CPP files with formats in order to support formats. I've added theese files (format registration file and references) to that project to make LZMA format working (tested using Total7zip): In Release mode I've got 145K DLL (VS 2010).

After removing LzmaRegister.cpp from project I've got DLL that can't unpack LZMA again.

Also, LzmaRegister.cpp contains preprocessor directive #ifndef EXTRACT_ONLY that makes me thinking that you can define EXTRACT_ONLY macro in the project settings to support unpacking only.

Hmm, that doesn't work for me - the C files do not include stdafx.h, so I get immediately:

LzFind.c
E:\VCC\7zip\C\LzFind.c(762) : fatal error C1010: unexpected end of file while looking for precompiled header directive
LzFindMt.c
E:\VCC\7zip\C\LzFindMt.c(794) : fatal error C1010: unexpected end of file while looking for precompiled header directive

Removing the C files, I get

Linking...
Creating library Release/7z.lib and object Release/7z.exp
LzmaEncoder.obj : error LNK2001: unresolved external symbol _LzmaEnc_Create@4
LzmaEncoder.obj : error LNK2001: unresolved external symbol _LzmaEnc_Destroy@12
LzmaEncoder.obj : error LNK2001: unresolved external symbol _LzmaEnc_SetProps@8
LzmaEncoder.obj : error LNK2001: unresolved external symbol _LzmaEncProps_Init@4
LzmaEncoder.obj : error LNK2001: unresolved external symbol _LzmaEnc_WriteProperties@12
LzmaEncoder.obj : error LNK2001: unresolved external symbol _LzmaEnc_Encode@24
LzmaDecoder.obj : error LNK2001: unresolved external symbol _LzmaDec_Free@8
LzmaDecoder.obj : error LNK2001: unresolved external symbol _LzmaDec_Allocate@16
LzmaDecoder.obj : error LNK2001: unresolved external symbol _LzmaDec_Init@4
LzmaDecoder.obj : error LNK2001: unresolved external symbol _LzmaDec_DecodeToDic@24
LzmaDecoder.obj : error LNK2001: unresolved external symbol _LzmaDec_DecodeToBuf@28

These C files don't include stdafx.h so they can't use precompiled headers. You need to disable precompiled headers in their properties. That will just slow down compilation a bit.

After adding macro EXTRACT_ONLY (and removing 7zHandlerOut.cpp from project because of multiple symbol error) I've got 120 KB DLL that allows unpacking from 7Z archives.

It seems that in case of extracting only theese files may be removed too: LzmaEnc.c, LzmaEncoder.cpp, 7zEncode.cpp, 7zOut.cpp, 7zUpdate.cpp. Now my DLL is 118 KB and it is still able to unpack 7Z.

2ghisler(Author)
I noticed that you are compiling a wrong directory. You should compile projects in "CPP\7zip\Bundles\". For the full library, compile "CPP\7zip\Bundles\Format7zF\". For the "7z extract only" compile "CPP\7zip\Bundles\Format7zExtract\". And so on - purpose of each folder is described in "DOC\readme.txt".

I've compiled project in CPP\7zip\Archive\7z too and it works fine. Also it may be debugged, it is easier to edit its properties and to remove unused stuff.

ghisler(Author) wrote: 2MVV
I don't see the advantage compared to the existing plugins. But including an unpack-only dll would help the "normal" users, though, who would get a 7zip download and don't know what to do with it. Advanced users could still install one of the 7zip plugins.

I use dualboot 98/XP with some shared utilities as TC, 7zip plugin hangs completely under w98, so internal support would be great as I use 98 for backups or restores or emergencies and most of my files are under 7z.

isidro wrote:

ghisler(Author) wrote: 2MVV
I don't see the advantage compared to the existing plugins. But including an unpack-only dll would help the "normal" users, though, who would get a 7zip download and don't know what to do with it. Advanced users could still install one of the 7zip plugins.

I use dualboot 98/XP with some shared utilities as TC, 7zip plugin hangs completely under w98, so internal support would be great as I use 98 for backups or restores or emergencies and most of my files are under 7z.

Sorry, but there is no need for W98 at all.
Emergency boot media can be made with WinPE.
Compatibility with such old systems should be no design goal for TC or other modern software.

Horst.Epp wrote:

isidro wrote:

ghisler(Author) wrote: 2MVV
I don't see the advantage compared to the existing plugins. But including an unpack-only dll would help the "normal" users, though, who would get a 7zip download and don't know what to do with it. Advanced users could still install one of the 7zip plugins.

I use dualboot 98/XP with some shared utilities as TC, 7zip plugin hangs completely under w98, so internal support would be great as I use 98 for backups or restores or emergencies and most of my files are under 7z.

Sorry, but there is no need for W98 at all.
Emergency boot media can be made with WinPE.
Compatibility with such old systems should be no design goal for TC or other modern software.

All my systems are wxp/w98 dual boot in same C: fat32 partition (in different w98/wxp folders and different ProgramFiles folders) with an ntfs data partition, you don't always have any boot media when something happens, and total commander under w98 had always saved me, I could do a manual registry restore, delete virus, or restore a deleted system file. As I have most of my backup files in 7zip, I have 7zip installed on w98, if total commander could handle natively would be better, not worst.

isidro,
You may try older plugin versions for Win98. E.g. you can set some environment variable to different paths for OS-specific plugins and install such plugins in TC, they will work for that OS only (TC in other ones won't load them because of wrong path).

BTW I used two OS within the same C: drive before and now I find that it is much better to use two small separate volumes for them (e.g. FAT32 for W98 and NTFS for XP), and it is more secure. E.g. I now have W7 on C: and WXP on D: (both 30GB but WXP volume has only 2.5GB used so 5-10 GB would be enough - I install commonly used programs to large data volume) and boot loader allows to choose desired OS at startup.

ghisler(Author),
Would be useful to have wincmd.ini parameter to set path to 7z.dll in case user wants to use full library from installed 7-Zip to support unpacking all formats instead of tiny '7z only' one.

MVV,
Support++ for ability to use full 7z.dll.

Roman

Unfortunately I couldn't find a way to determine which formats are supported by full 7zip dll, so TC will only support unpacking of 7z files internally. Just use the plugin if you need this. It's not more work to install the plugin than to change a path...

It is really interesting why there are two 32-bit DLLs for 7-Zip (TC7Z.DLL, TC7ZIPIF.DLL) and the only 64-bit one (TC7Z64.DLL).

Also, w/o TC7ZIPIF.DLL I can't enter 7Z SFX archives (7-Zip 9.20) using TCx32 while TCx64 reads both 7Z and 7Z SFX...

What does mysterious TC7ZIPIF.DLL and why there's no 64-bit one?

TC7ZIPIF.DLL is used to access the C++ classes in TC7Z.DLL, which cannot be accessed directly from Delphi 2. Lazarus (64-bit) has no troubles to access them, so no TC7ZIPIF.DLL is needed. I could combine the two dlls into one, but the plan is to use standard 7zip dlls without modifications.

Thank you for the clarification! Now it is clear why there is no 64-bit TC7ZIPIF.