how to optimize the code, so that the exe file becomes the smallest minimum in size? is it possible?
don't tell me to remove the strings or make them shorter :grin:
.data
MSGINHALT db "Hallo ollaH",0
MSGTITEL db "hi :)",0
.code
start:
invoke MessageBox, 0, ADDR MSGINHALT, ADDR MSGTITEL, MB_YESNO or MB_ICONQUESTION
cmp eax,IDYES
je start
invoke ExitProcess, 0
end start
don't tell me to remove the strings or make them shorter :grin:
Only use one section in stead of two. Put your data in your code section, instead of where they are now.
Fake
Fake
.386
.model flat, stdcall
option casemap:none
include \masm32\include\windows.inc
include \masm32\include\kernel32.inc
include \masm32\include\user32.inc
includelib \masm32\lib\user32.lib
includelib \masm32\lib\kernel32.lib
.code
MsgCaption db "Iczelion's tutorial no.2",0
MsgBoxText db "Win32 Assembly is Great!",0
start:
invoke MessageBox, NULL,addr MsgBoxText, addr MsgCaption, MB_OK
invoke ExitProcess,NULL
end starthmm, but why do we use a .data section in other programs then if we can define our data in the .code section..
-NOP-
-NOP-
You might want to read this. :)
thx, but i don't think that this thread answered my question why we use .data section when we can define data in the .code section.. i couldn't extract any answer of this thread...
thx,
-NOP-
thx,
-NOP-
I'm not sure since this hasn't happened to me yet...I've heard that there might be some problems during the loading of the .exe when the code section and the data sections are merged(the sample code of what just happened above or using the linker options /merge ...)
ehm...does anyone have some linker parameters to merge the .text end the .rdata sections as described in the thread?
/Delight
/Delight
The problem with merging comes from the fact that by default the code section is read-only.
Try modifying the buffer in the code section and ka-boom!
You can change this at link time, but then there are security concerns... If the data is read-only by its nature (or use) as in this case, then there is no problem.
Mirno
Try modifying the buffer in the code section and ka-boom!
You can change this at link time, but then there are security concerns... If the data is read-only by its nature (or use) as in this case, then there is no problem.
Mirno
MASM32\BIN\LINK.EXE /SUBSYSTEM:WINDOWS filename.obj /MERGE:.data=.rdata /MERGE:.data=.text
oh yeah, I remember most code sections are setup up like this(declaring segments the other way around)...
_TEXT SEGMENT READONLY PAGE PUBLIC USE32 'CODE'
_TEXT ENDS
try removing READONLY maybe it'll work...
oh yeah, I remember most code sections are setup up like this(declaring segments the other way around)...
_TEXT SEGMENT READONLY PAGE PUBLIC USE32 'CODE'
_TEXT ENDS
try removing READONLY maybe it'll work...
Back in the 16 bit days, code was usually addressed with the CS segment register, and data by the DS and/or ES segment register.
As mentioned, under Win, the code section is normally read-only, and the data section read/write. It makes no difference in your example, but it won't work if you try to modify a data item.
Also today's CPUs have a code cache and a data cache. In larger applications, mixing code and data results in inefficient cache utilization, and slows down the program. See Agner Fog's optimization guide for details.
:)
As mentioned, under Win, the code section is normally read-only, and the data section read/write. It makes no difference in your example, but it won't work if you try to modify a data item.
Also today's CPUs have a code cache and a data cache. In larger applications, mixing code and data results in inefficient cache utilization, and slows down the program. See Agner Fog's optimization guide for details.
:)
Stryker, your parameters works great, but I have a new problem. linking with /section:.text,rwe dont work-
LINK : fatal error LNK1181: cannot open input file "rwe.obj"
What's wrong here??
/Delight
LINK : fatal error LNK1181: cannot open input file "rwe.obj"
What's wrong here??
/Delight
You probably had a space character between the commas and rwe option.
The problem only appears when using RadASM (by editing the .rap file). It looks like I have to link manually to solve this.
/Delight
/Delight
You can also use your own dos stub to cut down the size.
sub edi,edi
push edi
push ofs MsgCaption
push ofs MsgBoxText
push edi
callW MessageBox
push edi
callW ExitProcess
altought we loose 2 bytes with the SUB EDI,EDI, we save 3, one for each PUSH EDI
result: 1 byte less :grin:
ancev
it doesn't matter how small you get it. it's still gonna take up 4k on the disk. maybe 8k on fat32 i think
push 0 ; 6A 00
push ofs MsgCaption ; 68 xx xx xx xx
push ofs MsgBoxText ; 68 xx xx xx xx
push 0 ; 6A 00
jmp MessageBoxA ; E9 xx xx xx xx or FF 15 xx xx xx xx
is even smaller :), after box, kernel will jmp to the where ExitThread + xx address is stored and will exit our application
for bigger code i would use special table with offsets + constans
table label byte
lpMsg dd offset MsgCaption
lpText dd offset MsgBoxText
dd offset MessageBoxA
dd offset ExitProcess
...
or use structure, then load table address into EBX ESI or EDI, and call it using call dword ptr or call .lpMsg
sloat, default cluster size on fat32 is 4k. Won't matter (and is pretty damn silly) for normal executables, but if you're messing with injection or other size-limited coding (4k intros for instance), it can matter.
Be careful about depending on the "exitthread-offset-on-stack-at-program-entry" trick. First, I don't really know if this is ExitThread. Second, if it is, it's not guaranteed to be this. And even while it does exit your thread on all current win32 versions I know of, there's problems if you're doing MultiThreading.
Be careful about depending on the "exitthread-offset-on-stack-at-program-entry" trick. First, I don't really know if this is ExitThread. Second, if it is, it's not guaranteed to be this. And even while it does exit your thread on all current win32 versions I know of, there's problems if you're doing MultiThreading.
ret trick does work with all current versions of Windows, when its used in thread, thread is terminated, if you dont belive me, or you have read it in some shitty ms bulletin, just trace it under si and you'll see :), its present in windows for so long, that's why i think it wont change in the future, but who knows :)
might be corrupted, when file is packed by some exe packer/protector eg. FSG, coz EBP is corrupted and after ret, kernel does mov ,reg32 :rolleyes:
might be corrupted, when file is packed by some exe packer/protector eg. FSG, coz EBP is corrupted and after ret, kernel does mov ,reg32 :rolleyes: