Hi!
21--2006 17:22 [EMAIL PROTECTED] (Aitor Santamarэa) wrote to
[email protected]:
>> 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.
AS> Well, I was told (and I agree) that it is NOT safe to extend yourself
AS> beyond the memory that you initially own as a device driver. After
Aitor, let me repeat again: not need to "extend" anything. MZ header
(for plain executable and for driver in .exe) already says for kernel, which
minimum memory is required. If you eliminate some garbage from executable
image and wish to keep total required memory, just increase MIN= filed in
header (in case of COM2EXE, use -s option; for plain .exe-s, move DB's from
initialized segments to uninitialized one - linker eliminates uninitialized
areas from executable and increases MIN= for you).
AS> all, DOS should have placed you in a hole big enough for it, but not
Of course. Proper values in header will guarantee this.
AS> guaranteed that I can go beyond.
It _guaranteed_ if you properly set value for MIN= filed in header
(through -s option for COM2EXE or explicitly defining all uninitialized
variables in uninitialized segment for plain .EXE).
AS> I could be wrong, of course (I wish I was).
Sorry, you wrong. :)
>> 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.
AS> I do not need 0's. I just place 0's as they are better compresible
AS> (UPX-able) in my original file.
Nothing is "better compressible", than void! :)
AS> The problem is that the program (in the future read: driver) resident
AS> size is NOT known at compile time, because it depends from the
AS> parameters specified by user in commandline (basically how many 9.5KB
AS> buffers).
AS> So the program is just the resident code plus a large amount of 0's
AS> (имnit code) to be used as heap.
Aitor, you wrongly mix two issues: storing or not storing zeros in
executable doesn't solves issue with variable dynamic memory. As I
understand, currently you just (pre)allocate maximum possible memory, and
later just remain as resident only part of it. But again: this NOT relates
to storing or not zeros in executable. Pre-allocate memory you may by
explicitly filling executable by some garbage (by defining variables in
initialized segment) OR by reserving space in MIN= field of header (by -s
option, when you convert .COM by COM2EXE, or by moving definition to
uninitialized segment for .EXE).
Let me show examples. First source is .COM, converted to .EXE, in your
style (with explicitly initialized garbage), second source is converted .COM
without this garbage in executable, third source is plain executable:
______________O\_/_________________________________\_/O______________
; tasm/m testc1.asm
; tlink/t testc1.obj
; com2exe -s256 testc1.com testc1.exe
.model tiny
.code
.startup
.exit 0
.data
font1 db 31*1024 dup (0)
font2 db 31*1024 dup (0)
end
_____________________________________________________________________
O/~\ /~\O
______________O\_/_________________________________\_/O______________
; tasm/m testc2.asm
; tlink/t testc2.obj
; com2exe -s63744 testc2.com testc2.exe
; (63744=62*1024+256)
.model tiny
.code
.startup
.exit 0
.data?
font1 db 31*1024 dup (?)
font2 db 31*1024 dup (?)
end
_____________________________________________________________________
O/~\ /~\O
______________O\_/_________________________________\_/O______________
; tasm/m teste.asm
; tlink teste.obj
.model small
.code
start:
.exit 0
.data?
font1 db 31*1024 dup (?)
font2 db 31*1024 dup (?)
.stack 256
end start
_____________________________________________________________________
O/~\ /~\O
> >dir *.exe
TESTC1 EXE 63 526
TESTC2 EXE 37
TESTE EXE 517
(TESTE.EXE uses 517 bytes because dumb TLINK always generates 512 bytes for
header, even though it really smaller than 32 bytes). See the difference?
Now, let study headers:
______________O\_/_________________________________\_/O______________
Pages to load/last page size: 007D/0026h (125 pages/38 bytes)
Relocation table offset/size: 001C/0000h (28 bytes/0 dwords)
Header size: 0002h (2 para)
Min/max memory to allocate: 0010/0010h (16/16 para)
CS:IP: FFF0:0100h
SS:SP: FFF0:FA0Eh
----
File size: 0000F826h (63526 bytes)
Header size: 00000020h (32 bytes)
Program image size: 0000F806h (63494 bytes)
Required memory to load: 0000FA10h (64016 bytes)
_____________________________________________________________________
O/~\ /~\O
______________O\_/_________________________________\_/O______________
Pages to load/last page size: 0001/0025h (1 pages/37 bytes)
Header size: 0002h (2 para)
Min/max memory to allocate: 0F90/0F90h (3984/3984 para)
CS:IP: FFF0:0100h
SS:SP: FFF0:FA0Eh
----
File size: 00000025h (37 bytes)
Header size: 00000020h (32 bytes)
Program image size: 00000005h (5 bytes)
Required memory to load: 0000FA10h (64016 bytes)
_____________________________________________________________________
O/~\ /~\O
______________O\_/_________________________________\_/O______________
Pages to load/last page size: 0002/0005h (2 pages/5 bytes)
Header size: 0020h (32 para)
Min/max memory to allocate: 0F91/FFFFh (3985/65535 para)
CS:IP: 0000:0000h
SS:SP: 0F81:0100h
----
File size: 00000205h (517 bytes)
Header size: 00000200h (512 bytes)
Program image size: 00000005h (5 bytes)
Required memory to load: 0000FA20h (64032 bytes)
_____________________________________________________________________
O/~\ /~\O
Compare "Program image size" for each example and compare "Required memory
to load" for each example and feel the difference!
And now, let compare, how much UPX compression may "beats" void:
>dir testc2.exe
TESTC2 EXE 37
>upx --8086 --brute TESTC1.EXE -oTESTC1.UPX
>dir testc1.*
TESTC1 COM 63 494
TESTC1 EXE 63 526
TESTC1 UPX 315
Feel the difference!
>> 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
AS> Yeah, I supposed at Eric's analysis.
Sorry, Aitor, above was only mine analysis. But results of Eric's
analysis is equal to mine.
>> 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.
AS> Well, DISPLAY is just a transformed COM, so I could use it.
You "could use" what? aPACK? You wish to say, that currently DISPLAY is
only plain executable, but not combo of executable and driver (which may be
loaded through DEVICE=, similar to EMM386)?
AS> However, will be a SYS in a near future.
Why not combo, as EMM386?
>> Precisely. The more so, if not preserve all zeros in executable, then
>> it will be reduced even more, than after packing.
AS> Yes, but as I explained in my other message, I don't want to expand
AS> own memory block,
Let me repeat again: not need to expand anything.
AS> as I won't be able to do it as a device driver
AS> (unless unfortunately I am not wrong).
AFAIR, for driver you have no possibility to control memory management.
But .EXE header says for kernel, how much driver expects of available
memory!
>> 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!
AS> The thing is that I don't need MORE memory than the original one that
1. What about stack (do you fill it by garbage to increase .COM executable)?
2. This is cost for us in increased executable size (ie, instead MIN= field
in MZ header, .COM specifies required memory through its size).
AS> I have (in fact, once gone resident I just need something like 11KB,
AS> if you have XMS).
This (how program manages memory _after_ starting) is another question.
>> 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).
AS> I wouldn't do it if I could dynamically expand myself as a device driver.
Let me repeat again: not need to expand anything.
>> so, I wonder, how Aitor packs his _driver_?
If DISPLAY isn't combo, but plain executable only, then I take off this
question.
AS> Well, I don't have your nice ASCII quoting blackboard :) ,
?
AS> but here you have my make:
AS> ===
AS> nasm display.asm -o display.com -i.\egavga\
AS> com2exe display.com display.exe
AS> upx display.exe --8086
AS> ===
Definitely not the best usage of COM2EXE. Reread help screen about
assumed memory usage. I mean, that in given case, when you not need
additional extra memory (except space for stack), you may use something like
com2exe -s128 display.com display.exe
(where 128 is space for stack), and you decrease required for load memory
from 64k to smaller value.
-------------------------------------------------------------------------
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
