Quote:
Originally Posted by elit
I apologize for stupid question but was there specific reason for using extra "precomp" word, aka e  recomp... instead of just e:... d:... as was in ztool? To me it seems redundant as e: and d: already imply default behavior(encode vs decode) and precomp seem'd to me at first confused with precomp tool by schnaader. Also using different separators, aka ',' and ':' for specific areas of cmd make it prone to type error, as happened to me before and I seem to be not the only person. Pure ':'s in ztool were fine and easier for inclussion with other utilities IMO. BTW I am not complaining, this tool is fantastic and ultimate, just being curious about new design. |
There methods planned apart from precomp to be added in xtool, stuff like preprocessing of data, encryption, data reconstruction (rebuild), compression and etc.
Quote:
Originally Posted by felice2011
Razor but for the decompression of the archive the folder can only contain the file xtool.exe, without any *.dll right?
|
xtool requires dll at all times, even zlib requires dll. no code of compresssion algorithms are stored within xtool except for special cases but even those special cases do not execute if a specific dll that goes hand in hand with aren't available.
Quote:
Originally Posted by dixen
And?  |
And I think there is something wrong with the parser for FAT v9 (FC3, FC4) for big dat files, I kinda rushed adding this feature without conducting any proper tests.
Quote:
Originally Posted by KaktoR
Yes tested with 0.9 and 0.10
Code:
Compressing 122 files, 69,051,449,344 bytes. Processed 10.0% ==>> xtool
Compressing 69,353,227,695 bytes with ==>> srep
Correction: xtool is just working for about ~250mb, then stop |
Bugs everything, when are they gonna stop .... -_-