Hi!
10-Апр-2005 15:40 [EMAIL PROTECTED] (Eric Auer) wrote to
freedos-user@lists.sourceforge.net:
EA> FDSHIELD has no problem with loading to UMBs: If the selected UMB
EA> is too small, then the stack pointer will be too low when the UPX
EA> stub of the compressed FDSHIELD starts, and the stub will exit to
EA> DOS at once, before any damage is done.
This behavior better, than destroying memory, but worser, than user
expects. Why at all not prevent such dumb situations (user runs programs,
but it silently exits and does nothing - or says something dumb like "not
enough memory")?!
EA> If you do not UPX FDSHIELD,
EA> then you cannot load it to too small UMBs anyway -
Program _must_ be loaded into UMB, which _not smaller_, than required
by program (at any stage - initialization or working). Notwithstanding,
packed it or not. For .EXE (notwithstanding, packed or not) there is no
problem with "too small" UMB, because program requirements described in
header.
BTW, if program autoload itself high, then this should give better
result, because program may allocate best fit UMB _for resident part_ (not
for full program, including transient part with its initialization and stack
requirements).
EA> it does not need more RAM than the decompressed binary size
Stack!
EA> (plus a small stack,
!
EA> but even if you start it with "no" free stack space, the stack will
EA> only overwrite part of the help message.
Why not prevent such events at all?! This costs only 32 bytes of
executable image (on disk)!
EA> Anyway, if you like, you can create a sample EXE binary, which should
EA> be UPX compressed (either before or after converting to EXE, as long
EA> as it is compressed at all) and at most 4 kB in size. Enjoy :-).
?
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
