The smallest executable

[frktons]

I'd like to create the smallest executable with the attached source.

If anybody has experimented combinations of assembler/linker to get
the smallest running executable, please give it a shoot, post your
complete command lines/batch files, and the executable and obj file
you get. Any combination of Masm/JWasm/Any compatible and Link/Polink...
that you are aware of and can create an exe file with the attached
source is welcome.

Thanks

Frank

[jj2007]

These global variables produce very bloated code:
    mov windowSize.Left, 0
    mov windowSize.Right, 79
    mov windowSize.Top, 0
    mov windowSize.Bottom, 24
Make them local, or use a register to load them. Besides, m2m is often shorter than mov.

[frktons]

These global variables produce very bloated code:
    mov windowSize.Left, 0
    mov windowSize.Right, 79
    mov windowSize.Top, 0
    mov windowSize.Bottom, 24
Make them local, or use a register to load them. Besides, m2m is often shorter than mov.

Thanks for the note Jochen. That's surely a way of sparing some bytes.  :t

However I was asking about Assemblers/Linkers and their options to make an
executable program smaller compared to the same program assembled/linked
with different parameters and/or tools.
And an "exe compactor" could do the final job to get the smallest executable
program as the final touch.

[nidud]

deleted

[frktons]

Code Select Expand

JWasm ascii.asm
JWlink format win pe file ascii.obj

12288 byte

Code Select Expand

upx ascii.exe
3072 byte

Hi nidud. I've tried using these instructions in a bat file:

Code Select Expand


\masm32\bin\JWASM.exe /c /coff /Cp /Zg /zlf /zls /nologo ASCII.asm
\masm32\bin\polink /SUBSYSTEM:CONSOLE /ALIGN:4096 ASCII.obj


and I get an executable file of 3072 bytes, as you did with your commands.
I'm wondering if a small file like this is compressable, considering the new
exe has to contain the decompressor code as well.
So I think upx is not useful in this case. Maybe a better combination of
parameters for Assembler/Linker could gain some bytes.  ::)

[dedndave]

Code Select Expand

    mov windowSize.Left, 0
    mov windowSize.Right, 79
    mov windowSize.Top, 0
    mov windowSize.Bottom, 24

    mov bufferSize.x, 80
    mov bufferSize.y, 25

    mov startPoint.x, 0
    mov startPoint.y, 0

nah - put them in initialized data
it takes more bytes of code to initialize them, whether it's local or global, than it does to stick them in
initialized data
the exception to that is startPoint
put that one in uninitialized data - it's initialized to 0 automatically   :P

now - i know that's not what you were asking about - lol
if you use PoLink, you will get an EXE that is 512 bytes smaller
or, you can use ms Link, and combine sections like this

Code Select Expand

Link /SUBSYSTEM:CONSOLE /OPT:NOREF /MERGE:.data=.text /ALIGN:4 MyFile.obj

[Antariy]

Code Select Expand

JWasm ascii.asm
JWlink format win pe file ascii.obj

12288 byte

Code Select Expand

upx ascii.exe
3072 byte

Hi nidud. I've tried using these instructions in a bat file:

Code Select Expand


\masm32\bin\JWASM.exe /c /coff /Cp /Zg /zlf /zls /nologo ASCII.asm
\masm32\bin\polink /SUBSYSTEM:CONSOLE /ALIGN:4096 ASCII.obj


and I get an executable file of 3072 bytes, as you did with your commands.
I'm wondering if a small file like this is compressable, considering the new
exe has to contain the decompressor code as well.
So I think upx is not useful in this case. Maybe a better combination of
parameters for Assembler/Linker could gain some bytes.  ::)

Frank, have a look into \masm32\examples\exampl10\MemInfoMicro, there should be a batch file with commands to build that old version of this prog.
Also have a look into the BAT file used for building MemInfoMicro25. Take your notice on the /MERGE options, and, especially for an old linkers, /OPT:NOWIN98.

[frktons]

Using Polink with these options, I get an executable of 2,560 bytes  :t

Code Select Expand


\masm32\bin\polink.exe /SUBSYSTEM:CONSOLE /MERGE:.data=.text /SECTION:.text,rwe "ascii.obj" > nul

Probably for this program only source code changes [as Dave and Jochen suggest] can spare some
more bytes.

[nidud]

deleted

[dedndave]

Frank,
if you want to make it smaller, look at the code and data  :P

a lot of times, looking at the disassembled code will bring out things you don't notice in the source
and - when you have related data - put them in a structure
then, instead of...

Code Select Expand

    mov     SomeData1,1
    mov     SomeData2,20
    mov     SomeData3,30
use

Code Select Expand

    mov     edx,offset SomeStruct
    mov     [edx].SOMESTRUCT.SomeData1,1
    mov     [edx].SOMESTRUCT.SomeData2,20
    mov     [edx].SOMESTRUCT.SomeData3,30

look at those 2 snippets in a disassembled listing   :P

as Jochen mentioned, using m2m makes code smaller when the constants are small

Code Select Expand

    push    20
    pop     [edx].SOMESTRUCT.SomeData2
that's because the immediate data (20) is stored in the code stream in a reduced form
whereas

Code Select Expand

    mov     [edx].SOMESTRUCT.SomeData2,20
the immediate data (20) is stored in the code stream as a dword (assuming SomeData2 is a dword)

however, push/pop is slower
it quite often doesn't matter when API calls are involved, anyway

[frktons]

Hi nidud.

About compressing the exe see my previous post.
Regarding the Text File Compressor and Scanner I'm collecting
the one thousand PROC I need, and the 10,000 necessary info.

The overall scheme is ready. Probably one of this ideas would
give the program the capability to compress a little even the
considered impossible to compress random files, it'd be a surprise
but I'm not sure for the time being it'll work as expected, after
all if it is considered an impossible task it has to mean something.
In few months I'll see and in case I'll show the results on the forum.

As they say the project is still work in progress, and all the
threads I started have something to do with it in a way or another.

I'm quite slow 
so don't expect fast results, and the project is quite complex to manage in Assembly
for a n00bist of my level  :P

[dedndave]

i should mention that talking about small code, we will get a message from Hutch - lol
be sure to use LODSB, STOSB, and LOOP, wherever possible   :lol:

[frktons]

Dave, your suggestions and Jochen's ones intrigue me. Considering you
have far more knowledge/experience than me I've to take these notes
in great consideration, so as time permits I'll try them and post the results.

LODSB, STOSB, and LOOP

whooooaaa, I've never used them, are they nice ones?  :lol:

[dedndave]

i use them all the time, where speed isn't critical - like parsing the command line or something

Hutch barks at me every time - but, he probably likes you more than me   :lol:

[frktons]

i use them all the time, where speed isn't critical - like parsing the command line or something

Hutch barks at me every time - but, he probably likes you more than me   :lol:

So they aren't fast, but I hope they are small at least  :lol:

You know what they say, the more far away you are the more they like you :super-lol: