Newbie: Huge EXE files for simple programs - why?

I used bcc32 (Borland C++ 5.5.1) command-line compiler to compile a simple "hello world" program, and it's about 70KB. When I used Turbo C++ 3.0 it was a lot smaller. Simple 15-20 line C programs have gone up to 180KB! Why is this?

Is it to do with the compiler itself, the code, or the fact that it's a Windows compiler? How can I produce very small EXE's using C and not assembly language?

Is it possible to compile for DOS with bcc32, or to .COM files?


Thanks,
Dom.

I don't know Borland but I would submit that you're probably building in a special mode called "Debug mode". This adds on debug information so that you can step through your code. THere should be a way of building in "Release Mode"

The libraries that are being linked in with your program when you #include header files is probably your culprit.

ditto. the stl can easily make your simple program 500k.

WTF?

The STL is template-based, that means, it costs nothing to runtime!!
Header files only contain declarations!!

170KB means you compile in Debug Mode.
Or you have LINKED many libraries.

#include does NOT increase the size of your program! (it only increases compile-times)

Quote:

---

Originally posted by Dominic
I used bcc32 (Borland C++ 5.5.1) command-line compiler to compile a simple "hello world" program, and it's about 70KB. When I used Turbo C++ 3.0 it was a lot smaller. Simple 15-20 line C programs have gone up to 180KB! Why is this?

Is it to do with the compiler itself, the code, or the fact that it's a Windows compiler? How can I produce very small EXE's using C and not assembly language?

Is it possible to compile for DOS with bcc32, or to .COM files?


Thanks,
Dom.

---

COM files are limited and crap...not as efficient as proper exe files...

If I were you, I wouldnt worry about small details like this

Well he may need to wrry bout it, what if he has limited webspace or a file size limit?

I would have to agree with the others on the DEBUG build.

Quote:

---

Originally posted by Ride -or- Die
Well he may need to wrry bout it, what if he has limited webspace or a file size limit?

I would have to agree with the others on the DEBUG build.

---

I dont know anyone working on a hard disk where this would be a serious issue....people who are that vain should follow thier instincts and work solely in assembler as far as I'm concerned :)

If he were working on an embedded system where there may be real constraints, would he be using these tools?...

Quote:

---

Originally posted by Shade
(it only increases compile-times)

---

That's not always true

>Header files only contain declarations!!<

Yes, but many compilers determine what libraries to link in based on those declarations. :rolleyes:

Quote:

---

I dont know anyone working on a hard disk where this would be a serious issue

---

I didn't say hard disk, i said WEBSPACE. As in how much room you are alloted by your webhost for files and webpage files and such. Some host, most eve, give u 20mb and a 200kb file size limit.

Quote:

---

Originally posted by Ride -or- Die
I didn't say hard disk, i said WEBSPACE. As in how much room you are alloted by your webhost for files and webpage files and such. Some host, most eve, give u 20mb and a 200kb file size limit.

---

If you were working with a webhost that confined you to such restrictions, I doubt they would allow you to use C/C++ as your CGI tool....more likely ASP, JSP, PHP or some other script that's more controllable

I meant as far as zipping his exe and storing it on his webhost for downloading. Like my hos (www.nelie.org) i have a 10mb limit and 500kb file size limit. So if i wanted someone to download a 501kb file, i couldn't host it on my site...

Geezuz boy! Get a new host!

www.tilted.com

>>I used bcc32 (Borland C++ 5.5.1) command-line compiler to compile a simple "hello world" program, and it's about 70KB.<<

If you use -v in your linker switches then you are building a debug version which will be larger; remove the -v switch if not required.

Use O1 compiler switch for smaller exes, O2 for faster (this seems to be a fairly common switch among the few windows compilers i've played around with).

I sympathise entirely with your desire to understand why there is an increase in size but am unfortunately as much in the dark as you.

I could speculate that rtti (run time type information) is the reason or that better exception handling is involved or that it's just simply byte alignment but I honestly do not know.

As an example of a similar scenario, the latest MinGW compiler is a lot slower to compile and builds larger exes than the 295.x versions. The reasons given for this were: better compliance with c++ standards, better exception handling capability and faster exes built.

Good luck in finding answers regarding differences between bcc5.5 and earlier versions. :)