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:
"INCLUDELIB OLDNAMES" means the compiler adds code in a lib file. If you are curious, open the exe in Olly.
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.
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.
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.
I guess VS does a debug build with full debug info
Possibly. But it was in release mode with full optimisations enabled.
Ok, then use one of PE viewers and compare both variants
VS likes link crt libs too :-)
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).
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)
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.
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?
Hi Lonewolff,
Are you building a .NET executable? My method cannot be applied to .NET
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)
Quote from: Lonewolff on March 18, 2016, 07:47:10 AM
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)
If your problem is The entry point then you can be specify by
/ENTRY:main ,or by Setting Visual C++ Project Properties. (https://msdn.microsoft.com/en-us/library/669zx6zc.aspx), In this case, the linker does not include anything and the size of the program becomes 1kb
The way you put the problem tired Mr.Jochen