On 01/09/2015 19:47, Rugxulo wrote:
> And I also announced it for News (but it hasn't shown up on front page yet).

That's cool, thanks!

> P.S. I knew that LZMA was slower for older-class machines, but I
> traditionally just unpacked/repacked

But keep in mind that you are a "special case" ;)
What's obvious to you (unpacking/repacking to gain on de-UPXing times) 
is not necessarily that obvious to a user that runs FDNPKG for the first 
time. The LZMA gain is not high, less than 20%, so I believe it's better 
to have something running reasonably fast on every 386+. For FDNPKG, the 
UPX loading times are as follows on my 25 MHz 386:

Not UPXed           : 1s
UPX -9              : 3.5s
UPX -9 --all-filters: 4.5s
UPX --lzma          : 35s (!)

> Also, the whole linking with libemu.a was probably unnecessary (due to
> emu387.dxe loadable at runtime) except for user convenience.

Without linking with -lemu, FDNPKG was immediately crashing with a 'no 
coprocessor' fault on computers without an FPU. There are ways around 
that, like using a 387 TSR emulator or runtime DXE loading, but FDNPKG 
is supposed to be working even in a minimal environment (ie. only 
kernel+command.com available), since it is used for installing all the 
rest of the system. That's also the reason it comes with a CWSDPMI stub 


Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
Get real-time metrics from all of your servers, apps and tools
in one place.
SourceForge users - Click here to start your Free Trial of Datadog now!
Freedos-user mailing list

Reply via email to