Hi,
2006/8/21, Arkady V.Belousov <[EMAIL PROTECTED]>:
Hi!
21--2006 02:30 [EMAIL PROTECTED] (Aitor Santamarэa) wrote to
[email protected]:
>> - DISPLAY somehow manages to resist LOADHIGH, Aitor! Maybe it
>> just tries to be too clever...
AS> Not at all. I remind you (discussed long ago) that it happens because
AS> of UPX. The creation of DISPLAY is:
AS> NASM => COM2EXE => UPX
AS> I must use UPX, because (as I asked here long ago) I cannot, as a
AS> device driver (and will not do for EXE, as I will explain for KEYB)
AS> EXPAND my memory block.
AFAIR, device driver not need to "expand" memory block - it already own
all free memory... As for .EXE, then its header already says to executable
loader, how much of memory it required, so not need to expand anything.
Well, I was told (and I agree) that it is NOT safe to extend yourself
beyond the memory that you initially own as a device driver. After
all, DOS should have placed you in a hole big enough for it, but not
guaranteed that I can go beyond. I could be wrong, of course (I wish I
was).
AS> Hence I have to book a lot of room with 0's
AS> and then UPX it (code is around 2Kb, the rest to 11KB (using XMS) is
AS> just that bunch of 0's, which is UPX-ed and compressed to less than
AS> 4KB.
But why at all store all zeros in executable? Why not clear memory
after loading (if you need zeros)? Just ensure, that after program loading
there is enough memory for this "bunch of 0's" - for this, ensure, that EXE
header field "min memory" contains required value.
I do not need 0's. I just place 0's as they are better compresible
(UPX-able) in my original file.
The problem is that the program (in the future read: driver) resident
size is NOT known at compile time, because it depends from the
parameters specified by user in commandline (basically how many 9.5KB
buffers).
So the program is just the resident code plus a large amount of 0's
(ìnit code) to be used as heap.
21--2006 03:41 [EMAIL PROTECTED] (Eric Auer) wrote to Aitor
Santamarэa:
Wow! UPXed executable requires 128336 bytes to load! This explains, why
DISPLAY resist to load high... Interesting, where is bug/issue? When I
Yeah, I supposed at Eric's analysis.
repack DISPLAY by UPX ("upx --8086 --brute"), it again begins require 128k
to load - looks like bad algorithm in UPX. After packing executable by
aPACK ("apack -x"), it now requires only original 64k of memory to load.
Pity, that aPACK doesn't support exe/sys.
Well, DISPLAY is just a transformed COM, so I could use it. However,
will be a SYS in a near future.
EA> Because your program is an EXE, the DOS kernel can figure
EA> out how much it needs to be run. Either your MS DOS has
EA> 128k consecutive UMB space when your run DISPLAY or your
EA> MS DOS is violating its own specs... However, UPX is quite
EA> pessimistic about needed space. If you would NOT UPX your
EA> program, you would only need roughly 64k to load DISPLAY!
Precisely. The more so, if not preserve all zeros in executable, then
it will be reduced even more, than after packing.
Yes, but as I explained in my other message, I don't want to expand
own memory block, as I won't be able to do it as a device driver
(unless unfortunately I am not wrong).
EA> There are various possible solutions. If you UPX a DISPLAY.com
EA> file,
No! NEVER-NEVER-NEVER make resident programs as .COM files (I mean,
resident should be compiled as .EXE or converted from .COM to .EXE), because
.COM files don't have header, which notifies system, how much precisely
programs it need! Without this, .COM program may be loaded into too small
UMB block, and, if program doesn't check this, it will overwrite MCB chain
headers!
The thing is that I don't need MORE memory than the original one that
I have (in fact, once gone resident I just need something like 11KB,
if you have XMS).
EA> If you make DISPLAY a true EXE
Converted (from .COM to .EXE) executable _is_ "true EXE". Of course,
when you convert, you shouldn't forget to specify, how much memory will be
required after program loading. With my COM2EXE, use option -s.
Interesting... I'll see available options.
EA> which knows well about how
EA> much heap it needs and preferrably also has a real stack
EA> (not "initial SS:SP = PSP:fffe"),
For .COM and .COM with .EXE header, this _is_ real stack. But, with my
COM2EXE, if you specify (by -s option), that program requires less than 64k
of memory after load, stack (SP) will be consequently adjusted.
EA> You either have to use another compressor, design your
EA> program as a proper EXE with own stack, or ask some UPX
EA> expert to fix the sub-optimal workings of UPX for your
EA> case.
Second advice is ir-relevant, third (I think) is best (if UPX will be
really fixed). And you miss there advise with eliminating zeros from
executables - this allows to not use packer at all (because I doubt that
compressing 2k to, say, 1.4k gives much advantage).
I wouldn't do it if I could dynamically expand myself as a device driver.
Interesting, that when I re-pack unpacked executable ("upx --8086
--brute"), UPX says:
UPX 2.01d Markus Oberhumer, Laszlo Molnar & John Reiser Jun 06th 2006
File size Ratio Format Name
-------------------- ------ ----------- -----------
62535 -> 3652 5.84% dos/exe DISPLAY.up
-------------------------------------^^^^^^^
so, I wonder, how Aitor packs his _driver_?
Well, I don't have your nice ASCII quoting blackboard :), but here you
have my make:
===
nasm display.asm -o display.com -i.\egavga\
com2exe display.com display.exe
upx display.exe --8086
===
Aitor
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
