Re: Which compiler to create small windows exe's ??

"cr88192" <cr88192@xxxxxxxxxxx> wrote in message

"Bedwal_Da_Bond" <jai1988bajrangbali@xxxxxxxxx> wrote in message
Hi all,

At the moment i am using DevC++, it produces very large exe's. I have
ried many compiler options, but still its way too big (around 200K,
whereas i need around 5-10K, and the code is not much 2-3K
Please suggest me a better (or the best :P) compiler to do it.

use C or ASM, and avoid and C runtime calls.

actually, this may be harder, since control will often be transferred to a
special stub (often called 'crt0.o' and containing '_start' or similar),
which will initialize the C library, followed by transferring control over
to 'main' or 'WinMain' (although sometimes the init code is embedded
directly into 'main', so it depends on various factors, such as compiler
and build target...).

avoiding this then, may well require providing ones' own entry stub, in
assembler, and then staying clear of any and all runtime calls (on both
Windows and Linux there are ways to address the kernel directly, and AFAIK
in Windows it is possible to use DOS-style 'int 21h' calls to access
kernel-provided services in 32-bit code, presumably with a similar
interface to DOS, but this would likely need verification, whereas on
Linux it is 'int 80h' and uses a somewhat different interface...).

one could then continue using C, by manually invoking it from ASM, and
providing their own (ASM based) interfaces into the OS kernel.

otherwise, there is no real way out of it, one will have to tolerate some
level of additional code making their EXE bigger (after all, this does
such useful things as giving one calls such as 'fopen', 'printf',
'malloc', ...).

one can use import libraries, and thus gain access to DLLs (and thus the
Win32 API), however, this will very quickly get one back up into the 10's or
100's of kB for the EXE range...

similarly, attempting to implement such functionality for themselves (for
example, a working 'malloc' implementation...), will also inflate the size
of the EXE, very possibly, back up into these ranges...

so, it is, in a way sort of a necessary evil...

one can just be glad they are not doing a non-trivial app, where one may
easily find even just their own code measuring in the 10s of MB, by far
dwarfing that of the runtime libraries...

similarly, from what I can gather (going and looking around), the 'int 21h'
calls are more provided as a sort of 'backwards compatibility' feature
(rather than an interface into the kernel...).

that is, of course, assuming they work correctly (or at all) from native
32-bit code (I had heard that they do, but have not personally verified

or such...