From: Marcus G. <mar...@ho...> - 2002-05-29 06:16:47
|
You are all talking about C++ features (streams etc). I noticed that EXEs produced from pure C (with gcc) get bigger with GCC 3.1 than with 2.x. I get the exact same figures as Anders Rand mentioned in the original post, when I compile a standard C hello world program with GCC. In general I get at least 6 KB "bonus" in my executables with 3.1 compared to 2.95.3. Those are 6 KB I would rather do without (I'm using MinGW to generate some _very_ tiny apps, like a 2D texture generator in 9 KB total, 6 KB compressed with UPX). So the question really is: Why are C program executables larger with GCC 3.1 than with GCC 2.x? I guess it has to do with the stdc lib implementation. Perhaps it's just a missing -Os in the compilation of the stdc lib? Marcus |
From: Wu Y. <ad...@ne...> - 2002-05-30 03:50:27
|
[OT] I share some of the opinions of Andres Rand. Sometimes I am reluctant to upgrade, because I have been used to the older one and the newer one seems always have some "feature" I don't like. Now return to topic. I have two cents. 1) Let's see what options MSVC provides: /GR[-] enable C++ RTTI /GX[-] enable C++ EH (same as /EHsc) /EHs enable synchronous C++ EH /EHa enable asynchronous C++ EH It does provide ways to get rid of things people does not need. 2) Big run-times are not necessary. Borland has a big overhead because of its design. It may not care much about making small executables, though it is possible. I have shown that one could produce an HelloWorld.exe as small as 2560 bytes with MSVC dependent only of USER32.DLL and KERNEL32.DLL. [OT] Users, as well as developers, have rights. Linux's success depends on the enthusiasm of developers, while Microsoft's success depends on its sense of what most users need. Best regards, Wu Yongwei |
From: Bob W. <bo...@ph...> - 2002-05-30 05:19:42
|
>> Linux's success depends on the enthusiasm of developers, while Microsoft's success depends on its sense of what most users need. << More accurately, Linux's success depends on the mainline software suppliers porting their products to Linux and giving their user base an inexpensive upgrade. If that would happen, Lunix would really take off and Microsoft strangle hold on the PC world would be broken. Frankly, I don't think there is a chance in hell of that happening. Regards, Bob |
From: Wu Y. <ad...@ne...> - 2002-05-30 09:00:41
|
Though I respect you very much personally, Danny, I must say that your word is one that I most hate and fear to hear in the "free" world. I don't think I am a bad programmer, but I do not like to spend time fixing everything I think imperfect. I would much rather pay for it. No flame, please. It's hard word to say. But many times was I FRUSTRATED by the word "submit a patch". I do not suppose I am born to enjoy free and perfect software, but there are really areas I am not familiar with and there is simply too much overhead for me to submit a patch for a giant like GCC (say, a fix that costs you an hour may cost me a week or so, just because I need to be familiar with the relevant data structures, algorithms, tools, etc.). The majority of users are more suitable to give opinions, not patches. In the area of compiler, I think I am one of the "majority". One more maybe unsuitable analogy: You got a free car, and you didn't like its panel; you told the vendor, and he told you that you need to !#$%^& ... (patch) and install (make) it yourself. Of course, it's a free car and you should not complain. Best regards, Wu Yongwei --- Original Message from Danny Smith --- > We are arguing for some tuning mechanisms, for > the right of choice. You always have the right to submit a patch. Danny |
From: F. <j_r...@ya...> - 2002-05-30 09:55:54
|
Wu, although is perfectly understandable that each one has is own interests, and yours don't necessarely have to include tweaking with compilers, you have to realize that those who do, do it as a volunteers and are also free to not choose implementing a particular feature. You have to remind that most developers of free software work for fun, and not money. Arguing with any developer to do this or that, will eventually make you hear what you don't want to hear... which is "fix it yourself". Nevertheless, if there are features that one need so much in any free software, nothing prevents that person to pay to someone to get them included. It happens all the time. (Unfortunately what happens even more often is people with the "give-me, give-me" mindset are always complaining but never contribute back in any form.) IMHO, the Free Software model is more democratic and is the one that can easily adapt to everyone's need. While with both free and proprietary software you may ask/pay to the original developers to get some feature implemented, only the free software gives you the option to do yourself (or pay a third party to do it). So I really think that you should face those words differentely - not as a frustrating answer, but as a manifest of each own free will... Regards, José Fonseca On 2002.05.30 09:58 Wu Yongwei wrote: > Though I respect you very much personally, Danny, I must say that your > word > is one that I most hate and fear to hear in the "free" world. > > I don't think I am a bad programmer, but I do not like to spend time > fixing > everything I think imperfect. I would much rather pay for it. > > No flame, please. It's hard word to say. But many times was I FRUSTRATED > by > the word "submit a patch". I do not suppose I am born to enjoy free and > perfect software, but there are really areas I am not familiar with and > there is simply too much overhead for me to submit a patch for a giant > like > GCC (say, a fix that costs you an hour may cost me a week or so, just > because I need to be familiar with the relevant data structures, > algorithms, > tools, etc.). The majority of users are more suitable to give opinions, > not > patches. In the area of compiler, I think I am one of the "majority". > > One more maybe unsuitable analogy: You got a free car, and you didn't > like > its panel; you told the vendor, and he told you that you need to !#$%^& > ... > (patch) and install (make) it yourself. Of course, it's a free car and > you > should not complain. > > Best regards, > > Wu Yongwei > > --- Original Message from Danny Smith --- > > > We are arguing for some tuning mechanisms, for > > the right of choice. > > You always have the right to submit a patch. > > Danny |
From: Nabil L. <Nab...@in...> - 2002-05-30 10:35:04
|
Hi Jos=E9 and all, I do definetly agree with these comments,=20 Just to remain constructive external influence is good for the project anyway but must/have to remain moderate. Especially "requirements" from the "external world" are generating profits there even if it is not in terms of money. I wish to thank you all for the effort beiing spent here, the outcome of this project is so far of an extraordinary excellent quality. I started using mingw a couple of months ago and I am a happy user. Just to tell you that there is also some other fronts than just the code. I have chosen to get involved a bit in standards WAR (W3C). I belieave that Open source and open standards are not only important=20 but VITAL for this crazy planet. Huge thanks again Jos=E9 Fonseca wrote: >=20 > Wu, although is perfectly understandable that each one has is own > interests, and yours don't necessarely have to include tweaking with > compilers, you have to realize that those who do, do it as a volunteers > and are also free to not choose implementing a particular feature. >=20 > You have to remind that most developers of free software work for fun, = and > not money. Arguing with any developer to do this or that, will eventual= ly > make you hear what you don't want to hear... which is "fix it yourself". >=20 > Nevertheless, if there are features that one need so much in any free > software, nothing prevents that person to pay to someone to get them > included. It happens all the time. (Unfortunately what happens even mor= e > often is people with the "give-me, give-me" mindset are always complain= ing > but never contribute back in any form.) >=20 > IMHO, the Free Software model is more democratic and is the one that ca= n > easily adapt to everyone's need. While with both free and proprietary > software you may ask/pay to the original developers to get some feature > implemented, only the free software gives you the option to do yourself > (or pay a third party to do it). >=20 > So I really think that you should face those words differentely - not a= s a > frustrating answer, but as a manifest of each own free will... >=20 > Regards, >=20 > Jos=E9 Fonseca >=20 > On 2002.05.30 09:58 Wu Yongwei wrote: > > Though I respect you very much personally, Danny, I must say that you= r > > word > > is one that I most hate and fear to hear in the "free" world. > > > > I don't think I am a bad programmer, but I do not like to spend time > > fixing > > everything I think imperfect. I would much rather pay for it. > > > > No flame, please. It's hard word to say. But many times was I FRUSTRA= TED > > by > > the word "submit a patch". I do not suppose I am born to enjoy free a= nd > > perfect software, but there are really areas I am not familiar with a= nd > > there is simply too much overhead for me to submit a patch for a gian= t > > like > > GCC (say, a fix that costs you an hour may cost me a week or so, just > > because I need to be familiar with the relevant data structures, > > algorithms, > > tools, etc.). The majority of users are more suitable to give opinion= s, > > not > > patches. In the area of compiler, I think I am one of the "majority". > > > > One more maybe unsuitable analogy: You got a free car, and you didn't > > like > > its panel; you told the vendor, and he told you that you need to !#$%= ^& > > ... > > (patch) and install (make) it yourself. Of course, it's a free car an= d > > you > > should not complain. > > > > Best regards, > > > > Wu Yongwei > > > > --- Original Message from Danny Smith --- > > > > > We are arguing for some tuning mechanisms, for > > > the right of choice. > > > > You always have the right to submit a patch. > > > > Danny >=20 > _______________________________________________________________ >=20 > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm >=20 > _______________________________________________ > MinGW-users mailing list > Min...@li... >=20 > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users --=20 Nabil Laya=EFda http://www.inrialpes.fr/opera/people/Nabil.Layaida/ INRIA - projet OPERA: http://www.inrialpes.fr/opera ZIRST - 655 avenue de l'Europe - Montbonnot F-38334 ST ISMIER CEDEX TEL: 04 76 61 53 84 FAX: 04 76 61 52 07 |
From: Oscar F. <of...@wa...> - 2002-05-29 16:55:43
|
Marcus Geelnard <mar...@ho...> writes: > You are all talking about C++ features (streams etc). I noticed that > EXEs produced from pure C (with gcc) get bigger with GCC 3.1 than > with 2.x. I get the exact same figures as Anders Rand mentioned in the > original post, when I compile a standard C hello world program with > GCC. In general I get at least 6 KB "bonus" in my executables with > 3.1 compared to 2.95.3. Those are 6 KB I would rather do without > (I'm using MinGW to generate some _very_ tiny apps, like a 2D texture > generator in 9 KB total, 6 KB compressed with UPX). Why small executable size is so important for you? I'm really curious. Often, my executables are distributed over 33kbps lines and small size is a bonus, but correctness is more important (and, for my specific case, run-time performance). > So the question really is: Why are C program executables larger with > GCC 3.1 than with GCC 2.x? I think Luke Dunstan explained this. [snip] -- Oscar |
From: Andres R. <lo...@ho...> - 2002-05-29 23:01:45
|
Hello! <ot> I had my OS reinstalled twice and I lost my malbox in process.. (I destroyed my partitions with overwhelming anger, but that's another storie.. ;) So, now I got time to look at my mail. </ot> My point here wos simple C prog. #include <stdio.h> int main ( void ) { printf ( "Hello world!\n" ); return 0; } Trivial, heh ;) Now, can you tell me, why on earth do I need C++ specific stuff in that executable?? (refering to first three-four replies) Sec: Why do I need exception handling here?? Why do I need small exes?? Example: My old Borland Builder used to make simple application (a window and a menu) around 140kb, I couldn't get anything less from that. Now, with MinGW I [used to] get an exe around 6-7kb. There is a difference. But that does not explain the need. So, let me think. Firstly, isn't MinGW: Minimalist GNU for Windows?? I guess it refers more like to a whole project (IMHO). Secondly, It goes against logic somehow. Why do I need lots and lots of code just to display a few lines in console? Blaah.. That can continue on and on, but not getting to bottom of that matter. Conclusion: At least I know now that 3.1 is good for programming in C++. For C apps I'm will use gcc2.95.3-xxxx (at least for now) but for C++ I will use gcc3.1-xxxx. Simple?? ;) Andres. > -----Original Message----- > From: min...@li... [mailto:mingw-users- > ad...@li...] On Behalf Of Oscar Fuentes > Sent: 29. mai 2002. a. 19:56 > To: min...@li... > Subject: Re: [Mingw-users] EXE file size > > Marcus Geelnard <mar...@ho...> writes: > > > You are all talking about C++ features (streams etc). I noticed that > > EXEs produced from pure C (with gcc) get bigger with GCC 3.1 than > > with 2.x. I get the exact same figures as Anders Rand mentioned in the > > original post, when I compile a standard C hello world program with > > GCC. In general I get at least 6 KB "bonus" in my executables with > > 3.1 compared to 2.95.3. Those are 6 KB I would rather do without > > (I'm using MinGW to generate some _very_ tiny apps, like a 2D texture > > generator in 9 KB total, 6 KB compressed with UPX). > > Why small executable size is so important for you? I'm really curious. > > Often, my executables are distributed over 33kbps lines and small size > is a bonus, but correctness is more important (and, for my specific > case, run-time performance). > > > So the question really is: Why are C program executables larger with > > GCC 3.1 than with GCC 2.x? > > I think Luke Dunstan explained this. > > [snip] > > -- > Oscar > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Oscar F. <of...@wa...> - 2002-05-29 23:33:05
|
"Andres Rand" <lo...@ho...> writes: [snip] > Now, can you tell me, why on earth do I need C++ specific stuff in that > executable?? (refering to first three-four replies) > Sec: Why do I need exception handling here?? AFAIK, the C++ exception handling is necessary in the case object code generated from C source is linked with C++ code to create an application. I agree that it would be nice to have a switch to get rid of that "extra". You need somebody's work in order to implement that switch, though. > Why do I need small exes?? > > Example: > My old Borland Builder used to make simple application (a window and a > menu) around 140kb, I couldn't get anything less from that. Yea, Borland's runtime library is not distributed with Microsoft's operative systems. <g> > Now, with MinGW I [used to] get an exe around 6-7kb. There is a > difference. But that does not explain the need. So, let me > think. Firstly, isn't MinGW: Minimalist GNU for Windows?? I'm quite sure that "minimalist" does not alludes to executable's size. > I guess it refers more like to a whole project (IMHO). Secondly, It > goes against logic somehow. Why do I need lots and lots of code just > to display a few lines in console? Well, 'cause nobody implemented the necessary logic needed for knowing if certain functionality is necessary. > Blaah.. That can continue on and on, but not getting to bottom of that > matter. > Conclusion: At least I know now that 3.1 is good for programming in C++. > For C apps I'm will use gcc2.95.3-xxxx (at least for now) but for C++ I > will use gcc3.1-xxxx. Simple?? ;) Do you renounce to 3.1 because C executables are 6 KB larger? Weird. -- Oscar |
From: <dan...@ya...> - 2002-05-29 23:55:04
|
--- Oscar Fuentes <of...@wa...> wrote: > "Andres Rand" <lo...@ho...> writes: > > [snip] > > > Now, can you tell me, why on earth do I need C++ specific stuff in that > > executable?? (refering to first three-four replies) > > Sec: Why do I need exception handling here?? > Actually, the "extra" code is for generic exception handling and not just restricted to C++. There is probably a way to not link in crtbegin.o and crtend.o if the -fno-exception switch is passed, and that may happen eventually. But as the release notes say this is a beta, and if your worried about exe size in your production releases you shouldn't be using it. I think the Dwarf2 EH is worth the extra cost. One reason is that sjlj exceptions may eventually become a "poor relative" that gets neglected in mainstream development. The other reason is that for exception-intensive apps, it is more efficient wrt both size and speed. But if most users want sjlj, that can be arranged. Now is the time to decide, because if we change back and forth it will create big compatability problems Danny > AFAIK, the C++ exception handling is necessary in the case object code > generated from C source is linked with C++ code to create an > application. I agree that it would be nice to have a switch to get rid > of that "extra". You need somebody's work in order to implement that > switch, though. Putting the switch in is no problem. Testing it takes time. > Danny > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users http://travel.yahoo.com.au - Yahoo! Travel - Plan and book your dream holiday online! |
From: Oscar F. <of...@wa...> - 2002-05-30 00:09:34
|
Danny Smith <dan...@ya...> writes: [snip] > But if most users want sjlj, that can be arranged. Now is the time > to decide, because if we change back and forth it will create big > compatability problems Seems that everybody agrees that Dwarf2 EH is more efficient and hence the risk of sjlj being poorly maintained is considerable, as you said. For both reasons (efficiency and quality of maintenance) the choice should be obvious, IMHO. [snip] -- Oscar |
From: Luke D. <cod...@ho...> - 2002-05-30 02:19:07
|
----- Original Message ----- From: "Oscar Fuentes" <of...@wa...> To: <min...@li...> Sent: Thursday, May 30, 2002 8:09 AM Subject: Re: [Mingw-users] EXE file size > Danny Smith <dan...@ya...> writes: > > [snip] > > > But if most users want sjlj, that can be arranged. Now is the time > > to decide, because if we change back and forth it will create big > > compatability problems > > Seems that everybody agrees that Dwarf2 EH is more efficient and > hence the risk of sjlj being poorly maintained is considerable, as you > said. > > For both reasons (efficiency and quality of maintenance) the choice > should be obvious, IMHO. > > [snip] > > -- > Oscar Yes, please don't go back to features (sjlj) that are less tested and supported by the GCC maintainers. Nobody actually needs 9 KB executables on Windows and there are plenty more important ways to spend time than "fixing" features like this. Luke |
From: <je...@in...> - 2002-05-30 06:25:18
|
> > Danny Smith <dan...@ya...> writes: [snip] > > Seems that everybody agrees that Dwarf2 EH is more efficient and > > hence the risk of sjlj being poorly maintained is considerable, as you > > said. [snip] <ot> Can anyone point my to a descent page for a breakdown/explanation of Dwarf2 and sjlj. A google search just points me to list-conversations, amoungs others, this one :). Id like to learn more about the differenses and bonuses inherit in these EH schemes. </ot> Thanx -- Jean le Roux Binary Entropy Catalyst |
From: Greg C. <chi...@mi...> - 2002-05-30 05:40:57
|
[3.1: "hello world" binary perceived as large; effect of dwarf exception handling discussed] Danny Smith wrote: > > I think the Dwarf2 EH is worth the extra cost. One reason is that sjlj > exceptions may eventually become a "poor relative" that gets neglected in > mainstream development. The other reason is that for exception-intensive apps, > it is more efficient wrt both size and speed. But if most users want sjlj, > that can be arranged. Now is the time to decide, because if we change back and > forth it will create big compatability problems Just to offer another perspective: The app I'm working on produces a seventy-nine megabyte binary; for my needs, a few hundred kilobytes is a rounding error. I use exceptions extensively. So from my POV it sounds like what you're doing is preferable to sjlj. But I'd guess the best reason to move away from sjlj is to stay in the mainstream. |
From: <je...@in...> - 2002-05-30 06:35:33
|
On Thu, 30 May 2002, Greg Chicares wrote: > The app I'm working on produces a seventy-nine megabyte > binary; for my needs, a few hundred kilobytes is a > rounding error. I use exceptions extensively. So from > my POV it sounds like what you're doing is preferable > to sjlj. YIKES!, ever hear of shared libs ? :) That beast must take a goodly while to compile ;D -- Jean le Roux Binary Entropy Catalyst |
From: Andres R. <lo...@ho...> - 2002-05-30 00:21:22
|
Hello! <ot> My theory goes: Older software products are better than new ones. For backing up my theory, take for example Linux. How many bugs it had in "childhood" and how many it has now?? My OS installing was all about upgrading from Win98 to Win2k. Not XP as MS and many users suggest. I think 2-2.5 years of bug-hunt and development is enough for somewhat stable run on Win system. With that, I think I will install XP on Christmas 2004 or in 2005 ;) </ot> In first place, I thought the size problem was connected to binutils. Andres. > -----Original Message----- > From: min...@li... [mailto:mingw-users- > ad...@li...] On Behalf Of Oscar Fuentes > Sent: 30. mai 2002. a. 2:33 > To: min...@li... > Subject: Re: [Mingw-users] EXE file size > > "Andres Rand" <lo...@ho...> writes: > > [snip] > > > Now, can you tell me, why on earth do I need C++ specific stuff in that > > executable?? (refering to first three-four replies) > > Sec: Why do I need exception handling here?? > > AFAIK, the C++ exception handling is necessary in the case object code > generated from C source is linked with C++ code to create an > application. I agree that it would be nice to have a switch to get rid > of that "extra". You need somebody's work in order to implement that > switch, though. [Andres Rand] Now, if we get rid of that C++ "extra" the exe size would drop, wouldn't it?? I'm not saying C++ is evil, but why do I need it in "pure" C program? > > > Why do I need small exes?? [Andres Rand] If I want REALLY small exes, I consider using pure assembler programming. It's like going to hunt elephant in Africa, but only on your knees and crawling through every square inch of desert :D > > > > Example: > > My old Borland Builder used to make simple application (a window and a > > menu) around 140kb, I couldn't get anything less from that. > > Yea, Borland's runtime library is not distributed with Microsoft's > operative systems. <g> [Andres Rand] I figured it myself, that it was runtime hanging around. > > > Now, with MinGW I [used to] get an exe around 6-7kb. There is a > > difference. But that does not explain the need. So, let me > > think. Firstly, isn't MinGW: Minimalist GNU for Windows?? > > I'm quite sure that "minimalist" does not alludes to executable's > size. [Andres Rand] Read next line ;) > > > I guess it refers more like to a whole project (IMHO). Secondly, It > > goes against logic somehow. Why do I need lots and lots of code just > > to display a few lines in console? > > Well, 'cause nobody implemented the necessary logic needed for knowing > if certain functionality is necessary. [Andres Rand] IMO, can't it go smth like this: After preprocessing and sometime before linking a function table could be built to see, what functions are needed from libraries. Then linker links only needed objects (not C++ objects ;) to final output. Or smth like that. In my case it would link only printf function to final exe (and other snips to get printf to work). Ok, I have actually no idea how compiling and linking take place. I know I will improve my knowledge on that matter someday. > > > Blaah.. That can continue on and on, but not getting to bottom of that > > matter. > > > Conclusion: At least I know now that 3.1 is good for programming in C++. > > For C apps I'm will use gcc2.95.3-xxxx (at least for now) but for C++ I > > will use gcc3.1-xxxx. Simple?? ;) > > Do you renounce to 3.1 because C executables are 6 KB larger? Weird. [Andres Rand] Fine, fine. Sad, I do not have Linux box at hand, so I could check their differences in 2.9x and 3.1 So I say 3.x is not so mature for me. You can sue me or do what ever you see fit, but that's my opinion. > > -- > Oscar > Andres. |
From: F. <j_r...@ya...> - 2002-05-30 01:19:48
|
On 2002.05.30 01:20 Andres Rand wrote: > ... > My theory goes: > Older software products are better than new ones. > For backing up my theory, take for example Linux. How many bugs it had > in "childhood" and how many it has now?? My OS installing was all about > upgrading from Win98 to Win2k. Not XP as MS and many users suggest. I > think 2-2.5 years of bug-hunt and development is enough for somewhat > stable run on Win system. > With that, I think I will install XP on Christmas 2004 or in 2005 ;) > ... Your theory is full of contradictions, as yourself... Why bother upgrade at all if you don't believe in quality enhancement!? Regarding your "childish" comment regarding the Linux bugs evolution: have you ever considered that many missing features _are_ a bug? Such as "not working on my brand new 4 SMP motherboard"? José Fonseca PS: I really shouldn't answer to trolls but it feels nice to take the bait once in a while... |
From: Earnie B. <ear...@ya...> - 2002-05-29 23:49:21
|
If you don't want exception handling then -fno-exceptions should work wonders. Earnie. |
From: <dan...@ya...> - 2002-05-30 00:19:05
|
--- Earnie Boyd <ear...@ya...> wrote: > If you don't want exception handling then -fno-exceptions should work > wonders. > > Earnie. > Actually, with 3.1 it doesn't remove that extra 6 kb that is being so hotly debated here. To get rid of that, the specs need to have something like this in it: *endfile: %{!fno-exceptions:crtend%O%s} *startfile: %{shared|mdll:dllcrt2%O%s} %{!shared:%{!mdll:crt2%O%s}} %{pg:gcrt2%O%s} %{fno-exceptions:crtbegin%O%s} That works for me with limited testing on C and Fortran code. However, AFAICT, no other target OS makes those magic files conditional. (Poor old pe-coff doesn't have weak symbols, so our options are a bit more limited) When we have a shared libgcc_s.dll, the 6KB would be there. Anyway, I'm not going to lose sleep over 6KB. Danny > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users http://travel.yahoo.com.au - Yahoo! Travel - Plan and book your dream holiday online! |
From: Benjamin R. <Ben...@ep...> - 2002-05-31 20:58:54
|
"Andres Rand" <lo...@ho...> writes: > My old Borland Builder used to make simple application (a window and > a menu) around 140kb, I couldn't get anything less from that. Apples and oranges here, of course. Current BC++ (the freely available command-line version) compiles your code to 6,656 bytes. That is using the DLL version of the RTL similar to Mingw's use of MSCRTL.DLL. I'm sure previous versions didn't do very much worse. |