Re: Visual C++ vs MASM32's Win32 API

From: Al Leitch (spamtrap_at_crayne.org)
Date: 10/29/04

  • Next message: Scott J. McCaughrin: "Re: math co-processor exceptions" 
    Date: Fri, 29 Oct 2004 18:59:31 +0000 (UTC)

    They had an article in Hugi magazine about this. I wish I could remember
    the exact magazine issue.
    http://hugi.de

    Matt Taylor wrote:

    > "Bryan Parkoff" <nospam@nospam.com> wrote in message
    > news:%6knb.26738$%x5.11734@twister.austin.rr.com...
    >
    >> I write a very short WinMain that contains CreateWindow, ShowWindow,
    >
    > and
    >
    >>UpdateWindow before the loop contains TranslateMessage and DispatchMessage
    >>under PeekMessage and WindowProc contains only one WM_Close that has
    >>PostQuitMessage(0). They are written in Visual C++. The debug version
    >
    > has
    >
    >>172,073 bytes and release version has 36,864 bytes.
    >>
    >> I do the same above that is written in MASM32. It only shows 2,560
    >>bytes. All three different bytes are in Win32.Exe (My own code).
    >> I am so curious why MASM32 has the shortest version than Visual C++'s
    >>release byte? Do you think that MASM32 has the best optimization over
    >>Visual C++'s release version? If I want to avoid writing Visual C++
    >
    > because
    >
    >>optimization is not so great, MASM32 will be recommended. Please advise.
    >
    >
    > There are several reasons:
    >
    > 1. Debug executable contains debug information and extra padding.
    > 2. VC-generated executables by default include the C runtime library. If you
    > use the C runtime library, you automatically get standard I/O and a number
    > of other bloated pieces of code.
    > 3. Masm does not align sections to 4K as is the default in VC.
    >
    > I have written programs that fit in 1-4 KB using pure C and compiling with
    > VC. If you call only Win32 functions (nothing from the runtime library), you
    > can use /NODEFAULTLIB and /ENTRY to remove the C runtimes and set your main
    > function respectively. Most of the string/memory routines from the runtime
    > library also have Windows equivalents (lstrlen, lstrcpy, RtlZeroMemory,
    > etc.) which can be used.
    >
    > If you can't avoid the C runtime library, you can dynamic link it. This not
    > only reduces your code size, it results in fewer bugs. The C runtime library
    > should *never* be statically linked, and yet this has been the default for
    > years.
    >
    > For really tiny executables, use /ALIGN:512 and /MERGE:rdata=text. Normally
    > sections (segments) in executables are aligned to 4 KB for performance
    > reasons. The /ALIGN option allows you to go as low as 1 sector or 512 bytes.
    > The /MERGE option merges the rdata (read-only data) and text sections to
    > save 512 bytes. If you have no non-constant global variables, your only
    > section will be the text section, and your executable can be as small as 1
    > KB.
    >
    > -Matt
    >
    >

  • Next message: Scott J. McCaughrin: "Re: math co-processor exceptions"