Other Compilers/Linkers...
-
I've just been messing around with LCC-Win32. It's a very small (3 meg) development environment for making C win32 programs: http://www.cs.virginia.edu/~lcc-win32/ I'm still using VC6 for my main work, and probably always will, but after comparing some of the results between the two, I've noticed that the .exes it produces are much smaller than VC6 ones. For example, I did a basic Hello world program that just consisted of printf("hello world\n"); in it, and VC6 managed 20 kb, and LCC managed 7 kb. In VC6, I set opt:nowin98, and I got rid of all the unneeded .lib files. Then I made a simple dialog program, which just had the OK and Cancel buttons - exactly the same code, resources, .mak file, and: LCC: 10 kb VC6: 30 kb Again, I set opt:nowin98, and got rid of all unneeded .lib files. Have other people noticed similar things with other compilers, for example, Intel's, Borland's, etc, as unless I'm doing something stupid, or not doing something I could be (quite possible, I admit) it does seem that VC6 is being rather inefficient. I might try a larger project of mine (45,000 lines) and see how that compares, but I'll have to change the code to C from C++, as LCC only supports C, so I doubt I'll have time. Cheers, Peter
-
I've just been messing around with LCC-Win32. It's a very small (3 meg) development environment for making C win32 programs: http://www.cs.virginia.edu/~lcc-win32/ I'm still using VC6 for my main work, and probably always will, but after comparing some of the results between the two, I've noticed that the .exes it produces are much smaller than VC6 ones. For example, I did a basic Hello world program that just consisted of printf("hello world\n"); in it, and VC6 managed 20 kb, and LCC managed 7 kb. In VC6, I set opt:nowin98, and I got rid of all the unneeded .lib files. Then I made a simple dialog program, which just had the OK and Cancel buttons - exactly the same code, resources, .mak file, and: LCC: 10 kb VC6: 30 kb Again, I set opt:nowin98, and got rid of all unneeded .lib files. Have other people noticed similar things with other compilers, for example, Intel's, Borland's, etc, as unless I'm doing something stupid, or not doing something I could be (quite possible, I admit) it does seem that VC6 is being rather inefficient. I might try a larger project of mine (45,000 lines) and see how that compares, but I'll have to change the code to C from C++, as LCC only supports C, so I doubt I'll have time. Cheers, Peter
-
I've just been messing around with LCC-Win32. It's a very small (3 meg) development environment for making C win32 programs: http://www.cs.virginia.edu/~lcc-win32/ I'm still using VC6 for my main work, and probably always will, but after comparing some of the results between the two, I've noticed that the .exes it produces are much smaller than VC6 ones. For example, I did a basic Hello world program that just consisted of printf("hello world\n"); in it, and VC6 managed 20 kb, and LCC managed 7 kb. In VC6, I set opt:nowin98, and I got rid of all the unneeded .lib files. Then I made a simple dialog program, which just had the OK and Cancel buttons - exactly the same code, resources, .mak file, and: LCC: 10 kb VC6: 30 kb Again, I set opt:nowin98, and got rid of all unneeded .lib files. Have other people noticed similar things with other compilers, for example, Intel's, Borland's, etc, as unless I'm doing something stupid, or not doing something I could be (quite possible, I admit) it does seem that VC6 is being rather inefficient. I might try a larger project of mine (45,000 lines) and see how that compares, but I'll have to change the code to C from C++, as LCC only supports C, so I doubt I'll have time. Cheers, Peter
VC compiler by default optimizes for speed and as you know speed is inversely propotional to size of exe. I think LCC-Win32 is optimizing for size. :) ;) ;P :-D :cool: Farhan Noor Qureshi
-
I've just been messing around with LCC-Win32. It's a very small (3 meg) development environment for making C win32 programs: http://www.cs.virginia.edu/~lcc-win32/ I'm still using VC6 for my main work, and probably always will, but after comparing some of the results between the two, I've noticed that the .exes it produces are much smaller than VC6 ones. For example, I did a basic Hello world program that just consisted of printf("hello world\n"); in it, and VC6 managed 20 kb, and LCC managed 7 kb. In VC6, I set opt:nowin98, and I got rid of all the unneeded .lib files. Then I made a simple dialog program, which just had the OK and Cancel buttons - exactly the same code, resources, .mak file, and: LCC: 10 kb VC6: 30 kb Again, I set opt:nowin98, and got rid of all unneeded .lib files. Have other people noticed similar things with other compilers, for example, Intel's, Borland's, etc, as unless I'm doing something stupid, or not doing something I could be (quite possible, I admit) it does seem that VC6 is being rather inefficient. I might try a larger project of mine (45,000 lines) and see how that compares, but I'll have to change the code to C from C++, as LCC only supports C, so I doubt I'll have time. Cheers, Peter
The c-runtime(crt) is statically linked with your binary by default. There are 2 ways to avoid this situation.
- Dynamically link with the CRT by specifying the /MD flag in your project options. This casues the compiler to not statically link the CRT into your binary, but links at runtime with the MSVCRT.DLL. Goto Project->Settings->C++ tab->Code Generation in the category dropdown and then select Mutithreaded DLL from the "Use run-time library" dropdown. Just re-compile and your binary should be about 4k.
- Write your own CRT as explained in this article :
http://msdn.microsoft.com/msdnmag/issues/01/01/hood/hood0101.asp
-
VC compiler by default optimizes for speed and as you know speed is inversely propotional to size of exe. I think LCC-Win32 is optimizing for size. :) ;) ;P :-D :cool: Farhan Noor Qureshi
Hmmm. I tend to find quite the opposite! OK, if you let the compiler inline everything it could, the exe size will get larger, and it _might_ get faster (but not by much in the average case). When you take into account the time taken to load code segments, you'll often find that optimizing for size ends up generating code that executes faster... :) Matthew Adams Development Manager Digital Healthcare Ltd
-
I've just been messing around with LCC-Win32. It's a very small (3 meg) development environment for making C win32 programs: http://www.cs.virginia.edu/~lcc-win32/ I'm still using VC6 for my main work, and probably always will, but after comparing some of the results between the two, I've noticed that the .exes it produces are much smaller than VC6 ones. For example, I did a basic Hello world program that just consisted of printf("hello world\n"); in it, and VC6 managed 20 kb, and LCC managed 7 kb. In VC6, I set opt:nowin98, and I got rid of all the unneeded .lib files. Then I made a simple dialog program, which just had the OK and Cancel buttons - exactly the same code, resources, .mak file, and: LCC: 10 kb VC6: 30 kb Again, I set opt:nowin98, and got rid of all unneeded .lib files. Have other people noticed similar things with other compilers, for example, Intel's, Borland's, etc, as unless I'm doing something stupid, or not doing something I could be (quite possible, I admit) it does seem that VC6 is being rather inefficient. I might try a larger project of mine (45,000 lines) and see how that compares, but I'll have to change the code to C from C++, as LCC only supports C, so I doubt I'll have time. Cheers, Peter
Hi, You are right: LCC-Win32 can make very small programs, but this is because its C-run-time is smaller than visual-c's However, Visual C can optimize much better than LCC-Win32, so you will reach a point when VisualC is making smaller programs than LCC once your program's source get bigger. By the way, I regularly create 2Kb programs in Visual C, by removing the C-run-time and using pure WinAPI instead. Look for an article by Matt Pietrek on MSDN magazine, Janurary 2001, entitled "Under the hood". This is an update of the original October 1996 October 1996 by Matt, when it appeared in MSJ magazine. Here's the link: http://msdn.microsoft.com/msdnmag/issues/01/01/hood/hood0101.asp James.