News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

Weird observation with Visual Studio [Mystery solved]

Started by Lonewolff, March 17, 2016, 06:07:31 PM

Previous topic - Next topic

Lonewolff

Hi guys,

I was just playing with Visual Studio 2015 and I thought I'd take a look at the resultant ASM code for a very basic 'Hello world' style program.


int main()
{
return 0;
}


As you can see, it is basic as it gets.

VS did and awesome job and even did the XOR EAX,EAX trick on the zero return value.


.686P
.XMM

.model flat

INCLUDELIB OLDNAMES

_TEXT SEGMENT
_WinMainCRTStartup PROC
; Line 3
xor eax, eax
; Line 4
ret 0
_WinMainCRTStartup ENDP
_TEXT ENDS
END


This is where it gets interesting.

The output exe generated by VS.Net is 8.5 KB. But if you run the ASM generated file directly through ml.exe and link.exe the result is a file of only 1 KB.

Why is this?   :dazzled:

jj2007

"INCLUDELIB OLDNAMES" means the compiler adds code in a lib file. If you are curious, open the exe in Olly.

Lonewolff

Why the huge size difference though?

[edit]
Just opened in Olly now. Can't tell how to find what lib it loaded in there though.

jj2007

Instead of letting us guess what your problem is, why don't you zip the exe and attach it here? Would save a lot of time.

Lonewolff

Quote from: jj2007 on March 17, 2016, 07:42:41 PM
Instead of letting us guess what your problem is, why don't you zip the exe and attach it here? Would save a lot of time.

Um what? Not sure that you even read the OP.  ::)

There is no problem. Just an observation. This is why I posted in 'The Laboratory' and not as a question.

Compile in VS.net = 8.5 KB
Compile the resultant ASM file that VS.net supplies = 1.0 KB

Same end program but 7.5 KB difference in size.

GoneFishing

I guess VS does a debug build with full debug info

Lonewolff

Possibly. But it was in release mode with full optimisations enabled.

GoneFishing

Ok, then use one of PE viewers and compare both variants
VS likes link crt libs too :-)

mabdelouahab

Lonewolff
I tried the same thing with VS2012

int main()
{
return 0;
}

the output listing generated by vs is diferent

; Listing generated by Microsoft (R) Optimizing Compiler Version 17.00.50727.1

TITLE C:\foo.cpp
.686P
.XMM
include listing.inc
.model flat

INCLUDELIB MSVCRT
INCLUDELIB OLDNAMES

PUBLIC _main
; Function compile flags: /Odtp
_TEXT SEGMENT
_main PROC
; File c:\foo.cpp
; Line 2
push ebp
mov ebp, esp
; Line 3
xor eax, eax
; Line 4
pop ebp
ret 0
_main ENDP
_TEXT ENDS
END



The output exe generated by VS  (6 KB) = The output exe generated by ml.exe (6 KB).

jj2007

Quote from: mabdelouahab on March 17, 2016, 11:30:43 PMThe output exe generated by VS  (6 KB) = The output exe generated by ml.exe (6 KB).

It will remain a mystery forever ::)

(unless, of course, somebody is courageous enough to zip the exe and attach it here)

Vortex

Hi Lonewolff,

The functions introduced by the C run-time libraries are the reason of the size increase of C executables. My solution is to use my own tiny C run-time library. Attached is an example displaying a blank windows coded with VC Express 2010 + Win 7 SDK. The executable is only 2 Kb.

Lonewolff

Quote from: Vortex on March 18, 2016, 06:17:59 AM
Hi Lonewolff,

The functions introduced by the C run-time libraries are the reason of the size increase of C executables. My solution is to use my own tiny C run-time library. Attached is an example displaying a blank windows coded with VC Express 2010 + Win 7 SDK. The executable is only 2 Kb.

Ah, ok. Now that makes sense  :biggrin:

[edit]
Hang on a sec, no it doesn't - LOL

If the program is only doing this...


xor eax, eax
ret 0


How can it be requiring any lib functions behind the scenes?

Vortex

Hi Lonewolff,

Are you building a .NET executable? My method cannot be applied to .NET

Lonewolff

#13
No just a bare bones c++ application.

[edit]
After much playing around this morning it is all making sense now.

The entry point isn't actually what we see in our part of the source code (in this case '_main'). The entry point is '_mainCRTStartup' which is hidden away in the lib files.

It appears that _mainCRTStartup is doing all of the initialisation of the console etc.

So, even though I asked VS to compile a program that returns zero to the operating system, it is adding in all sorts of other crap assuming that I want this to all happen in a console window (which in this case is all additional unwanted stuff).

Mystery solved  8)