Some enchancement to packer plugin API

[Dinosaur]

Hi all!

I think it'd be nice to let packer plugins tell compression method ("Method" field in packer file properties). Currently this feature exists only for built-in packers, but external plugins should have it too.

My suggestions:
1. Add appropriate text field in tHeaderData structure. Not very good, as it may get existing plugins unusable.
2. Add function for retrieving list of compression methods and use Method field in tHeaderData as element index in that list. Use current behavior for old plugins. Better, as it wouldn't affect existing ones.

[ghisler(Author)]

For displaying: this isn't currently planned - it would only affect the packer properties dialog anyway.

For packing: the way you should handle this in your plugin is as follows: When packing in TC, there is a "configure" button. This button calls the plugin function ConfigurePacker() of your plugin, where you can let the user choose the compression ratio. As an example, see my .bz2 packer plugin.

[Dinosaur]

I know how it can be done for packing. I ask support for displaying compression method in third-party plugins.

I think it isn't hard to implement so I'm disappointed a bit that you aren't planning this enchancement.

[TrePe]

Hello, I do not want to make another thread, and this seems appropriate...
My suggestion is to somehow make possible to send to TotalCommander files larger than 4GB. The limitation now is tHeaderData.UnpSize (PackSize), which is int and not unsigned long long (or similar).
I have this problem with my DiskDirExtended plugin. The file size is correctly written in the list file (e.g. 5GB), but TotalCommander displays it modulo 2^32 (e.g. 1GB), due to conversion to int.
Or is there some workaround?
Thanks

[ghisler(Author)]

Well, I could add a new variable filesize_high to the end of the structure, where plugins could write the high dword of the size. This would be backwards compatible to old plugins, but risky if a plugin writer forgets to check the plugin version number - it would crash older versions of TC if plugins would write to this field. What do you think?

[Sheepdog]

I think, if this is a known issue, we could tell all the people having this problem (and maybe inform the plugin author).

sheepdog

[TrePe]

Hm, crashing does not sound good...

I see two solutions:
quickFix: use of any cmt* field; e.g. cmtBuf may be used arbitrarily - one can even put some data behind '\0' byte if necessary (if this field is actually used by someone, as the WCX Writer's Reference states that it is not used in TC)

New API with new data structures, preserving old API for backward compatibilty.
For my plugin for example even limit of 260 bytes on file name is restricting, because it lists files inside archives. So the solution similar to cmtBuf would be more appropriate (i.e. passing pointer and length). But this is for longer discussion, because it may drastically affect your code and it would be nice to achieve mutual agreement in community what to include in new structure (I'm dreaming, I know ;) ). But I would certainly suggest to incorporate into new structure some means of expansion in the future.

[ghisler(Author)]

2TrePe
You are right, a new function ReadHeader2 would probably be the best solution. Sorry, 260 characters is an internal limit of Total Commander. Many Windows functions even crash when passing longer names to them, at least on Windows 9x/ME!