I'll check

Update available

Changes

- added partial unreal engine lzo support (thanks to Edison007 for lzo1x_99 args)

Notes

This is might as well be a useless update at the moment because I'm pretty sure either old or few UE games use the method that is precompressed by 0.10, I'm still trying to figure out how to precompress the rest of the streams which are common.

With 0.10 update - also not decompressing

Razor but for the decompression of the archive the folder can only contain the file xtool.exe, without any *.dll right?

Couldn't understand your question but you need to have the dll for the codec you used, in the same folder as xtool.exe. Suppose you used lz4, you just need liblz4.dll not the others.

No, for decompression u r going to need same dlls which u used for xompression. that means if u used plz4 during compression u r going to need xtool + liblz4 for decompression.

Strange for the decompression seems to work without any DLL, only xtool.exe, tried on a data folder of generic files, that's why I was curious to understand ...:confused:

If it had zlib streams then it works without dll as well because xtool has internal zlib/deflate libraries but dont know if razor did that for other codecs too maybe yes he did considering how stupid people can actually get :D

But its always recommended to use latest external libraries for faster processing.

wow how many masters and experts in compression lately here in the forum, it's been a while that I'm not here in the forum, it's not about ease of use for people, it's about knowing whether or not to insert the DLL for decompression, "Faster Processing" explain to me what it means because the decompression speed is the same, since we are talking about decompression and not compression.

If I remember correctly, razor once said that internal processing can be actually slower at certain stages when compared to its usage with external libraries. I might be wrong but thats what I remember. Plus I am not even sure what internal libraries are present in xtool, only razor knows, maybe reflate libraries are not present. With ZTool, I noticed size was better with external libraries in some cases and faster too, but its XTool so who knows, maybe Razor improved it. But one thing I can tell, its always better with the external libraries so I don't see the problem in using them.

But really the main reason for internal libraries is for the ease of people. Razor implemented the internal libraries so that processing will still work in case people don't even put the dlls at the correct places, that was the main reason I think.

This is what I do not understand, I wanted a concrete motivation, in my concept of coder, a file if needed I use it, if I do not need I do not use it, I do not insert files because I like the dll extension or others, as many they do, without really understanding their use and necessity.
I wait Razor look for a response aimed at my curiosity, thanks anyway for your intervention.

excuse me for post this. i googled before but not good results. is there a link to a tutorial on how to use x-tool i wanna test it to sve some data in my hdd and im totally noob in this .

i ve used the bat file but didnt compress or i really didnt see the difference with the actual file. (a ps2 iso files, even unrared)

It all depends what actual "internal processing" is. Does it mean just dll's included inside exe, does it mean official source code translated to Pascal and included/compiled with project, or does it mean having your own self-written routines?

For 1. case there should be no difference, for case 2. and 3. my guess is that since Razor code in Borland's Delphi, that could be one reason for slower internal routines vs external dll's. Because I used to code in Borland's C++ back then and I remember it was not that fast. Also B. Pascal, just like B. C++ use own libraries, own compiler and both are object based languages. Which will be slower than standard direct C routines, say through MinGW. In most cases that is, few exceptions like STL aside.

Since dll's of codecs like lz4, zstd and most others are written in C and already optimized by its devs, they should be quicker as Delphi is then only used as a bridge for io calling. Yes normally internal routines should be always faster than calling external dll's, but only if under same environment and optimizations. Here we are basically talking B. Pascal vs C overhead and thats assuming routines are perfectly written or translated/optimized to Pascal which they may not be, so you get a speed difference based from both factors.

Dll's also give you ability to switch between different versions as long as they use same API which is another plus.

And?:)

i think pascal compiler's abi is compatible with maybe gcc(if gcc not, i think its borland(embarcadero) c++ itself which sucks at optimizations) so they used compiled objects and directly links with the pascal code see https://github.com/madler/zlib/blob/...al/zlibpas.pas
Another trickery can be, represents your dll as hexadecmial literals in your code and using some library like, to directly load from memory, quickbms uses it

For what I have tested the borland compiler is based on clang(msvc edition), as far as minGW posix is not compatible, I just do not know if it is possible with minGW win32. Since you use msys2 then it's posix!