Smallest Windows Application code

[srfpala]

The MASM32 Package is outstanding!
1. I'm trying to build the smallest widows application –> No Menus, No Messages Boxes.                 
2. Would the code I copied from generic.asm and trimmed be the minimal amount
           of code for an acceptable do-nothing Windows application or could it be further reduced ?
3. The code can be found here www.n2006b.com/asm

If the above is proper, then I intend to expand the code to include a Button and MessageBox -
which displays "Hello World" .

TIA for comments and suggestions.

[box]

The smallest legal .exe according to the PE spec is 1024 bytes

Check out \masm32\examples\exampl10\masm1k to see how it's done

The absolute smallest possible .exe that the windows loader will process is somewhere around 90-300 bytes depending on which windows version you're running, which means a 400-500 byte windowed app is possible by writing the PE header yourself. (which is pointless)

[hutch--]

box is right, 2 x 512 byte sections is the minimum working PE 32 bit executable file. You see attempts to make them smaller by running a non-standard 1st section which includes both the MZ and PE headersa but they don't run reliably on all windows versions. 32 bit PE is a specification and where you deviate from it you produce unreliable results.

For a 1k application, you put you data in the code section and do not include a resource section so you have 1 512 byte section that has the legal headers and the second 512 byte section that contains both data and code.

[Queue]

I think srfpala wants to know what the minimum ASM source file framework to make a program with a window, not what the smallest executable file is.

Queue

P.S. - One of the first things I did when I started with MASM was to make a miniscule EXE. I made a 512 byte console EXE that simply returns an exit code of 1, as does the DOS stub. I've tested it on 98SE, XP and Vista (and real DOS and DOSBox); I don't know if it works on NT or 2000, but I think I followed everything to the letter, so it should. I barely had to do anything by hand since POLINK's layout for a merged code and import section is so convenient; I just deleted the precisely 512 bytes from 0x160 to 0x360 to place my executable code next to my PE header, and changed my .text section's start location from 02 to 01, and it works. I can optionally change the entry point, and the section flags for .text, but neither should be necessary. I also made the same EXE with icon at 1KB, and it's been equally functional. My point is, you can follow the PE specs to the letter, and just load the first 512 block for code and imports and you'll have 160 bytes in which to fit your code and imports so it'll be a proper exe (no overlapping the header, which ends at 0x160 if there's a 32 byte DOS stub and only 1 section).

[hutch--]

Well,

His question was about making the minimum size window smaller and it has been answered in that context, that is what MASM1K is, a minimum window.

[theunknownguy]

If there are not rules against loading your soft (i guess you are in a challenge) with other application then you can make much less than that.

The way is to make your own file format (i use mine in my softs) with just ImageBase + Reloc Section (most of time needed) + Import section (if needed) and other important data.

I would remove the section list, names, etc, etc and just leave those info that could make you map your application from another one (with your own algo). That will reduce the file size to much less than 1024 bytes.

PS: I think he ask this, caused there is a challenge over internet for build the most reduced window box application with a reward in exchange.

[dedndave]

hex dump of Minimal.com.....

Code Select Expand

        C3
can't get much smaller than that   :P

[theunknownguy]

hex dump of Minimal.com.....

Code Select Expand

        C3
can't get much smaller than that   :P

Lol the less i can think of is:

4 bytes + 4 pushes + 1 CALL ADDR

Code Select Expand


first 4 bytes the header:

ImageBase

4 pushes (of MessageBox)
1 CALL ADDR (MessageBox)

Set the MessageBox addr from the loader application. Isnt that the less size for a non conventional file format?  :lol

Ive never understand the needing for those challenge of less size...

[hutch--]

 :bg

> If there are not rules against loading your soft

There ARE rules, its called the Portable Executable Specifications published by Microsoft. Contests to make non-specification files that will run in some versions of Windows have been with us for the last 15 years and they all suffer the same problem, the OS loader in at least some versions will not load them. The best way to make something that breaks is to do it the wrong way. Microsoft specifications are all over the place at best and you simply compound these problems by using non-specification executable layouts.

[theunknownguy]

:bg

> If there are not rules against loading your soft

There ARE rules, its called the Portable Executable Specifications published by Microsoft. Contests to make non-specification files that will run in some versions of Windows have been with us for the last 15 years and they all suffer the same problem, the OS loader in at least some versions will not load them. The best way to make something that breaks is to do it the wrong way. Microsoft specifications are all over the place at best and you simply compound these problems by using non-specification executable layouts.

Well hutch battlenet 2.0 load their own files in a different format for avoid idiots to debug...

I dont see them argue about the PE format... in fact its kind of mine idea, just reloc section...

Also the word "loader" would explain why you want to do such a file with different format.

PS: I never expect to those files load by themself i mean they dont even have the PE signature (it would be mad to think OS will load them). Thats why i say loaded from another application (manual map)  :lol

[hutch--]

Outside of the natively supported executable formats in Windows up to Vista you have MZ, LE, PE and a few other deviations that are respectively 16 bit real mode, 16 bit protected mode and 32 bit protected mode but as soon as you start talking about non-natively supported files you are no longer talking about EXECUTABLE files but INTERPRETED files that are supported elsewhere via capacity supplied by the operating system. Writing a "loader" in Windows is using the existing operating system to create the capacity, the alternative is to write a seperate operating system that runs as a VM within a virtualisation framework but none of this stuff is a valid Windows executable.

In 32 bit Windows an EXECUTABLE file is one loaded by the operating system, LE and MZ files are run in a type of VM. 64 bit Windows runs seperate subsystems for 32 and 64 bit executable files and no longer runs 16 bit code natively.

[theunknownguy]

Outside of the natively supported executable formats in Windows up to Vista you have MZ, LE, PE and a few other deviations that are respectively 16 bit real mode, 16 bit protected mode and 32 bit protected mode but as soon as you start talking about non-natively supported files you are no longer talking about EXECUTABLE files but INTERPRETED files that are supported elsewhere via capacity supplied by the operating system. Writing a "loader" in Windows is using the existing operating system to create the capacity, the alternative is to write a seperate operating system that runs as a VM within a virtualisation framework but none of this stuff is a valid Windows executable.

In 32 bit Windows an EXECUTABLE file is one loaded by the operating system, LE and MZ files are run in a type of VM. 64 bit Windows runs seperate subsystems for 32 and 64 bit executable files and no longer runs 16 bit code natively.

100% agree with what you say. But those contest want the less size "executable" file. Meaning by Executable anyway that you can actually execute the god danm messagebox and having the file store in drive.
(Well actually not all contest have the same rules)

Regarding to the portable termination they could be adaptable as long as the algo and the loader are also acceptable by the OS. So actually there is no reason to edit the already good one PE format file...

But in these days, you would waste investment on virtualizers/obfuscators/crypters (bla bla bla) and why not a format for avoid guys to debug (at least for a while).  :lol
My congrats for those who go far and far for stop unpackers. Nothing compares to one good challenge... (security)

And sports seems not good enough in this days for having fun...  :lol