Help about executable size

[Sebastiano Del Gobbo]

Hi guys!
I need some help compiling an old 32 bit DOS4GW application first
developed using Watcom C/C++ version 11.
I need to update the software but i would like to use Open Watcom 1.9.
I simply opened the "old" project and tried to compile.
After correcting some minor errors i found that the resulting executable
is much bigger than the one created by the old version: 3.5Mb vs 600Kb!
Also compiling takes more time in the newer environment.
Some context:
Forget to mention i'm developing on a Windows XP SP3 32 bit machine and
the compiling target is 32bit DOS4GW.
Thank you so much for your help! :-)

Sebastiano Del Gobbo

[Johann Klammer]

Post by Sebastiano Del Gobbo
Hi guys!
I need some help compiling an old 32 bit DOS4GW application first developed using Watcom C/C++ version 11.
I need to update the software but i would like to use Open Watcom 1.9.
I simply opened the "old" project and tried to compile.
After correcting some minor errors i found that the resulting executable is much bigger than the one created by the old version: 3.5Mb vs 600Kb!
Also compiling takes more time in the newer environment.
Forget to mention i'm developing on a Windows XP SP3 32 bit machine and the compiling target is 32bit DOS4GW.
Thank you so much for your help! :-)
Sebastiano Del Gobbo

In my experience the native windows executables run faster than
the dos4gw ones (binnt instead of binw). Otherwise they're the
same and should compile protected mode executables just fine...

No Idea about the size... perhaps debugging information...
Look which objects get largest, use wdump/dmpobj/wdis/<whatever>
to look inside...

[Sebastiano Del Gobbo]

Post by Johann Klammer

Post by Sebastiano Del Gobbo
Hi guys!
I need some help compiling an old 32 bit DOS4GW application first developed using Watcom C/C++ version 11.
I need to update the software but i would like to use Open Watcom 1.9.
I simply opened the "old" project and tried to compile.
After correcting some minor errors i found that the resulting executable is much bigger than the one created by the old version: 3.5Mb vs 600Kb!
Also compiling takes more time in the newer environment.
Forget to mention i'm developing on a Windows XP SP3 32 bit machine and the compiling target is 32bit DOS4GW.
Thank you so much for your help! :-)
Sebastiano Del Gobbo

In my experience the native windows executables run faster than
the dos4gw ones (binnt instead of binw). Otherwise they're the
same and should compile protected mode executables just fine...
No Idea about the size... perhaps debugging information...
Look which objects get largest, use wdump/dmpobj/wdis/<whatever>
to look inside...

Thanks for your suggestions, Johann
I tried to remove debugging information settings but the executable size
doesn't change a lot.
I've noticed there is a "[sw]" near cpp files names.. What does it means?
Thanks again

S.

[Uwe Schmelich]

Post by Sebastiano Del Gobbo

Post by Johann Klammer

Post by Sebastiano Del Gobbo
Hi guys!
I need some help compiling an old 32 bit DOS4GW application first
developed using Watcom C/C++ version 11. I need to update the software
but i would like to use Open Watcom 1.9. I simply opened the "old"
project and tried to compile. After correcting some minor errors i found
that the resulting executable is much bigger than the one created by the
old version: 3.5Mb vs 600Kb! Also compiling takes more time in the newer
environment. Some context: Forget to mention i'm developing on a Windows
XP SP3 32 bit machine and the compiling target is 32bit DOS4GW. Thank
you so much for your help! :-)
Sebastiano Del Gobbo

In my experience the native windows executables run faster than
the dos4gw ones (binnt instead of binw). Otherwise they're the
same and should compile protected mode executables just fine...
No Idea about the size... perhaps debugging information...
Look which objects get largest, use wdump/dmpobj/wdis/<whatever>
to look inside...

Thanks for your suggestions, Johann
I tried to remove debugging information settings but the executable size
doesn't change a lot.
I've noticed there is a "[sw]" near cpp files names.. What does it means?
Thanks again
S.

Did you try to remove debugging symbols from your executable with wstrip? Or
are you building it with external symbol file already?
We could possibly give you some more hints if you could present the
compiler/linker switches used to us. Is it a C or C++ project? C++ can have
a lot of debugging info with the right switches (like -d3i).

[Paul S. Person]

On Fri, 17 Apr 2015 09:34:57 +0200, Sebastiano Del Gobbo

Post by Sebastiano Del Gobbo

Post by Johann Klammer

Post by Sebastiano Del Gobbo
Hi guys!
I need some help compiling an old 32 bit DOS4GW application first developed using Watcom C/C++ version 11.
I need to update the software but i would like to use Open Watcom 1.9.
I simply opened the "old" project and tried to compile.
After correcting some minor errors i found that the resulting executable is much bigger than the one created by the old version: 3.5Mb vs 600Kb!
Also compiling takes more time in the newer environment.
Forget to mention i'm developing on a Windows XP SP3 32 bit machine and the compiling target is 32bit DOS4GW.
Thank you so much for your help! :-)
Sebastiano Del Gobbo

In my experience the native windows executables run faster than
the dos4gw ones (binnt instead of binw). Otherwise they're the
same and should compile protected mode executables just fine...
No Idea about the size... perhaps debugging information...
Look which objects get largest, use wdump/dmpobj/wdis/<whatever>
to look inside...

Thanks for your suggestions, Johann
I tried to remove debugging information settings but the executable size
doesn't change a lot.
I've noticed there is a "[sw]" near cpp files names.. What does it means?
Thanks again

IIRC, that means that those files have switches set that differ from
those of CPP files in general. Of course, this may be intentional.

Or you may want to investigate further. This may take some time: first
you would have to compile a list of the settings that apply to all cpp
files and then compare that with the settings for each file. Whether
this would solve the size problem is another question.

Also, the problem may not be solvable: OW cpp underwent considerable
development at one point. Pulling out my Watcom 11b CD and opening
file string.hpp, I find a version of class string done /without
templates/. The current version uses templates; "string" itself is
now, IIRC, a mere typedef for a template instantiation. Granted, since
about 1.6 or 1.7, typedefs alone no longer caused the entire set of
nested templates to be fully instantiated (a good thing too, since
there are three of them for string alone), but instead delays
instantiation of each member function until that member function is
invoked, the constructors (whether any particular one is needed or
not) and destructor (IIRC, again) will appear for any template needed
for any member function invoked.

And I don't think string is unique in this regard. This may or may not
explain the size difference, depending on just what you are doing.

Other changes may have happened as well. I really like cpp, but small
executable size does not appear to be one of its benefits. At least,
not when the Standard is being conformed to, at least in part.

[i***@gmail.com]

Dismayed to read that, and skeptical! I've been using Watcom since 10.6 and have been developing IPDOS (tm) since 1992. Watcom has always given me, and appears to continue to give me, very small executables. (I currently use Jiri's OWv2 fork.)

I suspect that you are using features that I do not use. Suggestion: Start with a test program that compiles to a huge object module. Then incrementally remove code, noting when the object file size suddenly gets way smaller.

[Paul S. Person]

Post by i***@gmail.com
Dismayed to read that, and skeptical! I've been using Watcom since 10.6 and have been developing IPDOS (tm) since 1992. Watcom has always given me, and appears to continue to give me, very small executables. (I currently use Jiri's OWv2 fork.)

Is that with C or with C++? I was discussing C++.

At one time (OW 1.5 or so), simply putting

#include <string.hpp>

into a file produced nearly 64K code in the 16-bit targets (ie, nearly
an entire code segment). This is because including the header included
the three typedefs, and simply writing a typedef involving a class
template caused the entire template class to be instantiated right
then and there. This behavior changed by (IIRC) OW 1.7 so that only
member functions actually invoked were instantiated, so that the line
above produced (IIRC) no code at all.

I am currently using C only, in developing our wgml, so I am out of
touch with what has been happening to/with C++.

Post by i***@gmail.com
I suspect that you are using features that I do not use. Suggestion: Start with a test program that compiles to a huge object module. Then incrementally remove code, noting when the object file size suddenly gets way smaller.

Hopefully, the OP will see this, as this is not bad advice at all.

[i***@gmail.com]

I've used OW since the mid 1990's (Version 10.6) as my only programming environment. All of my code is C++, other than a very small amount of inline assembly and a handful of assembly modules. I do not use templates and I do not use the language's structured exception handling. Nor do I use the C library for much. I use my own string handling subsystem.

All of this is for IPDOS (tm), which is a "piggyback operating system" that runs on top of the base O.S. (currently MS Windows) as a daemon (Windows Service). Here are the executable sizes of what you get when you install IPDOS (tm):


Directory of I:\ideafarm.home.101\ephemeral\domains\com\ideafarm\city\park\exedll\1\master

2015-04-21 04:20 <DIR> .
2015-04-21 04:20 <DIR> ..
2015-04-21 04:20 27,136 ideafarm.41000002.ipdos-wm
2015-04-21 04:20 30,720 ideafarm.41000003.ipdos-wm
2015-04-21 04:20 212,753 ideafarm.51000359.ipdos-wm
2015-04-21 04:20 908,075 ideafarm.510004fb.ipdos-wm
2015-04-21 04:20 290,114 ideafarm.5100050e.ipdos-wm
2015-04-21 04:20 210,498 ideafarm.51000511.ipdos-wm
2015-04-21 04:20 243,545 ideafarm.5100057b.ipdos-wm
2015-04-21 04:20 192,981 ideafarm.510005a9.ipdos-wm
2015-04-21 04:20 226,651 ideafarm.510005d2.ipdos-wm
2015-04-21 04:20 250,100 ideafarm.510005ea.ipdos-wm
2015-04-21 04:20 208,131 ideafarm.51000619.ipdos-wm
2015-04-21 04:20 45,056 ideafarm.51000620.ipdos-wm
2015-04-21 04:20 231,068 ideafarm.51000621.ipdos-wm
2015-04-21 04:20 214,806 ideafarm.51000622.ipdos-wm
2015-04-21 04:20 343,568 ideafarm.51000651.ipdos-wm
2015-04-21 04:20 277,303 ideafarm.510006d9.ipdos-wm
2015-04-21 04:20 1,149,440 ideafarm.81000001.ipdos-wl
2015-04-21 04:20 18,560,000 ideafarm.81000001.ipdos-wm
18 File(s) 23,621,945 bytes
2 Dir(s) 182,404,153,344 bytes free


The IPDOS (tm) system consists of the first two files plus the last file. 41000002 is a stub executable that is launched for every IPDOS (tm) process other than a GUI process. 41000003 is the stub executable for GUI processes. (It is currently not used because I am in the middle of rewriting the Graphics Presentation Subsystem.) 81000001 is a DLL that contains all of IPDOS (tm) system functionality. Each of the other files is a DLL that defines a particular IPDOS (tm) application. Every instance of 41000002 (or 41000003) initializes itself and then dynamically loads a single application DLL that is specified on the command line.

IPDOS (tm) updates itself automatically, so I care a lot about file size. At present, my focus is on restoring the robustness of the debugger (WDW.EXE) which currently leaves much to be desired. The next priority is to support and encourage the work that Jiri (and others) (?) are doing to port OW to 64-bit and to Linux. But small executable sizes used to be one of the signature features of this wonderful toolset and I hope to keep that objective on the table.

[Paul S. Person]

Post by i***@gmail.com
I've used OW since the mid 1990's (Version 10.6) as my only programming environment. All of my code is C++, other than a very small amount of inline assembly and a handful of assembly modules. I do not use templates and I do not use the language's structured exception handling. Nor do I use the C library for much. I use my own string handling subsystem.

Which shows, at best, that /not/ keeping up with C++'s
ever-more-intricate features (IIRC, templates were added with Watcom
11 -- 10.6 was Watcom, not Open Watcom, BTW) you have avoided the
bloat.

The OP was clearly less fortunate.

And while you may not use the C Library directly, C++ and the C++
library are based on it. You may write "new" but, ultimately, you are
invoking some form of "malloc()". Well, unless you define a global
operator new() that builds its own heap from scratch.

<snippo advertising>

[i***@gmail.com]

Actually, that's what I do. I really don't use clib for much other than strcpy, strcat, and memcpy, and I don't think that I use any C++ library functions at all. IPDOS (tm) constructs its own heaps, rolls its own serialization support, provides its own database subsystem and presentation subsystem. The latter is disabled because I was half way into a rewrite when I started having serious problems with the police and local government here in Mountain View, CA (Googleville).

IMO, templates are brain-dead, and C++ has been utterly ruined by design-by-committee. Not trying to flame, here, but that's my take on it.

[Paul S. Person]

Post by i***@gmail.com
Actually, that's what I do. I really don't use clib for much other than strcpy, strcat, and memcpy, and I don't think that I use any C++ library functions at all. IPDOS (tm) constructs its own heaps, rolls its own serialization support, provides its own database subsystem and presentation subsystem. The latter is disabled because I was half way into a rewrite when I started having serious problems with the police and local government here in Mountain View, CA (Googleville).

That's a lot of work, but since you are rolling your own OS, I suppose
it comes with the territory.

Sorry to hear of your difficulties. Hopefully they were resolved
satisfactorily.

Post by i***@gmail.com
IMO, templates are brain-dead, and C++ has been utterly ruined by design-by-committee. Not trying to flame, here, but that's my take on it.

I wouldn't go quite that far, but some of the requirements in the
recent Standards (to the extent that I remember them correctly, which
also depends on my having understood them correctly in the past)
certainly seem ... ill-advised.

Back when I was buying computer books and reading them, I got one on
what turned out to be using templates as a language of their own -- an
interpretive language, with the compiler's template processing code as
interpreter.

So, yes, C++ has become your basic camel.

[Wilton Helm]

The map file is a good tool to use here. You can compare old and new map
files and see exactly what grew. One possibility is that the library
functions are more or longer. That is alway a trend in libraries. More
features take more code.

Since this is C++ that opens a whole can of worms. There are so many ways
that C++ can do things, particularly when templates are involved. It takes
more of the details out of the developers hands. Because I work on embedded
systems with limited memory and real-time execution requirements, I don't
use C++, although if a person knows what features result in code bloat or
excessive execution times, much of the benefit of the language can be
obtained (such as stronger type checking) without incurring the
disadvantage, but restricting oneself to a subset of the language.
Unfortnately some of the capabilites that make development easier tend to be
the ones that make execution less efficient.

Bottom line is 1) analyze, by looking at the map file and possibly timing
profiling, and 2) re-code, using more efficient techniques for things that
bloated or slowed down.

Wilton