Hi,
Eric Auer escribió:
About DISPLAY:As far as I recall, the idea of using COM2EXE is that there is a bug in kernel about loading high COM programs that resize their chunks (when there is no room, it aborts instead of loading low), and to avoid this problem. The experiments by Bernd showed that under MS-DOS it works fine (a growing COM file).
UPX first, COM2EXE next, produces smallest size.bad idea. COM2EXE cannot detect de-UPX-ed size! So the exe header
will tell how much space the compressed COM needs. But the whole idea
of using COM2EXE was to let DOS know the de-UPX-ed size explicitly:
...that we don't need because the problem [might] doesn't happen for EXE files.UPXing EXE files has that ad*antage...
If you load an UPXed COM intoWell, maybe. But Bernd has showed in those strange-MEM experiments that DISPLAY loads high this way well.
a too small memory block (or an com2exed UPXed com), you can end up
in the situation 'upx stub sees that there is not enough memory, so
it throws int 20 (exit with errorlevel 0, no message) instead of
unpacking and running the program'...
As far as for resident size, it doesn't change at all. So I could just try and revert the order of the steps for the next version. The only thing that will change is that DISPLAY.EXE will grow a bit (but it will be the LAST COM/EXE version anyway).
By the way, does anyone know how to mount a drive or directory as a drive for VMWARE? (something like DOSEMU's lredir).All my testing is done in VMware 4.5.2, btw. No Bochs/Qemu/DosEMU/VirtualPC etc.
Aitor
------------------------------------------------------- This SF.Net email is sponsored by: thawte's Crypto Challenge Vl Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam Camcorder. More prizes in the weekly Lunch Hour Challenge. Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
