General
What I can do to reduce executable size?
What are ItsyBits, FAFA etc.? Which libraries do I really need to compile?
Is CTL3D required?
I need a drink. Why is compilation so difficult on some platforms?
What I can do to reduce executable size?
wxWindows does produce large executables, but there's quite a lot
one can do to mitigate the problems.
- Eliminate debug info, either at link time or compile time. The latter usually
has a slight size advantage over the former, but you may consider it not
worth the hassle of completely recompiling for delivery.
- Optimise for space. Depending on the compiler, this can be quite significant.
With some compilers you can't optimise because of compiler bugs. However,
when I started using Watcom C++ to produce WIN32 executables, I got
a reduction from 3MB for my main tool (Hardy) compiled under VC++ 1.5,
to 2MB under Watcom, with optimisation. This is actually not a bad size for
a piece of software that has been growing for several years, and does
quite a lot.
- Eliminate unnecessary modules in wxWindows through wx_setup.h
and makefile settings, e.g. wxXPM, doc/view, wxPostScriptDC.
Through doing this, my WIN32 Tex2RTF LaTeX to HTML, WinHelp/RTF and wxHelp
converter is 633 KB (compiled with Watcom). Quite a reasonable
size these days.
- Compress the executable with a suitable compressor (that can
make a self-extracting .exe, transparent to the user), or other
method for distribution. I don't do this myself, but it would be a neat way of
saving disk space.
- On UNIX, create a shared version of the wxWindows library; see
contrib/wxshlib for GNU autoconf files for building shared and
static libraries.
- Under Windows, make a DLL out of wxWindows: not yet possible, but will probably
be done in the next few months because WIN32 DLLs are apparently
easier to make than WIN16 ones. This will spectacularly reduce the
size of executables, at the cost of confusion with DLL versions.
But for saving disk space during development this would be a good option,
and will probably reduce link times too. See Making a Windows DLL for notes on
a not-quite-successful attempt to make a DLL under VC++ 4.0.
- Get a better optimising linker. Part of the size problem is that the
compilers don't throw away sufficient bits of unused code. They may
get better at doing this as time goes on and everyone's executables
get larger.
The Windows hello demo executable is around 700KB for VC++ 1.5, less for
Watcom. This demo differs from traditional hello demos in using quite a
lot of GUI functionality, and therefore pulling in a lot of code.
And most options are enabled in wx_setup.h.
Obviously, the larger your application, the less you notice the overhead
of wxWindows.
What are ItsyBits, FAFA etc.? Which libraries do I really need to compile?
From wxWindows 1.61, the makefiles have been altered so that several
'subordinate' libraries are compiled into wx.lib (or wx_motif.a or
whatever). This means that configuration of wxWindows is much more
centralized, and it's not necessary to fiddle with many makefiles if you
decide to compile in a specific wxWindows feature.
These little libraries add optional functionality to wxWindows,
supported in the wxWindows class library but the bulk of the
functionality being implemented separately for modularity (and potential
copyright) reasons.
Unfortunately, you do have to edit both wx_setup.h and the makefile
in src/x or src/msw in order to configure wxWindows. So it
may be easier to compile all libraries rather than try to configure
wxWindows, unless you're really having trouble compiling one of
the libraries.
Here's a list of the optional libraries (found in wx/contrib or wx/utils).
The relevant wx_setup.h identifier is given in brackets.
- CTL3D
- Windows only: allows use of 3D style controls (CTL3D).
- FAFA
- Windows only: allows use of bitmap buttons, messages and radiobuttons (FAFA_LIB).
- ItsyBitsy
- Windows only: supports tiny titlebars (USE_ITSY_BITSY).
- Gauge
- Windows only: necessary for implementation of wxGauge class (USE_GAUGE).
- xmGauge
- Motif only: necessary for implementation of wxGauge class (USE_GAUGE).
- wxXPM
- All platforms: necessary for implementation of XPM pixmap functionality (USE_XPM_IN_X, USE_XPM_IN_MSW).
- DIB
- Windows only: necessary for implementation of BMP loading/saving functionality (USE_IMAGE_LOADING_IN_MSW).
- wxImage
- X only: necessary for implementation of BMP, GIF loading functionality (USE_IMAGE_LOADING_IN_X).
- PROLOGIO
- All platforms: necessary for .WXR wxWindows resource-loading functionality (USE_MSW_RESOURCES).
- RCPARSER
- Windows only: necessary for dynamic icon loading (USE_RESOURCE_LOADING_IN_MSW).
Note that if you don't compile in DIB, you could still use wxLoadBitmap in an application
and link with dib.lib separately in your application makefile. Similarly, you can use PROLOGIO and RCPARSER
independently without them being compiled into wx.lib.
Is CTL3D required?
Here's an excerpt from the wxWindows manual.
It is recommended that CTL3D is used under Windows, since the 3D effects
are good-looking and will be standard with Windows 4.0. If you want to
use it and don't already have CTL3D installed, copy the files in
contrib/ctl3d to appropriate places (ctl3dv2.lib/ctl3d32.lib into your compiler lib
directory, ctl3d.h into an include directory, and ctl3dv2.dll into
windows/system). You may need to find a compiler-specific version of ctl3dv2.lib
or ctl3d32.lib. Define CTL3D to be 1 in wx_setup.h and link your executables with ctl3dv2.lib
or ctl3d32.lib.
If both CTL3D and FAFA are set to 1, then all controls except wxButton
will use CTL3D and have 3D appearances. wxButton will have the ability
to use bitmaps. This is the recommended configuration.
Windows 95 update: dialogs can be marked with the Win95 3D look
by specifying the DS_3DLOOK. But this doesn't apply to panels.
The WIN32 SDK documentation says that the style WS_EX_CLIENTEDGE can be
used for controls, to give them all 3D looks. However, this doesn't appear to
work (and causes strange 2-column behaviour in wxListBox). Even marking the
executable as Windows 4.0 only gives a wxChoice items a 3D look.
So it seems that for now, CTL3D is still required for Windows 95 applications.
I need a drink. Why is compilation so difficult on some platforms?
It's a good question; you may be lucky enough to sail through wxWindows
installation without a hitch, or you may exhaust your vocabulary of
expletives before you're done compiling the first sample application.
There are a number of possible reasons for things to go wrong:
- Makefiles need to be adjusted (especially make.env) to add include and
library paths, and library flags, specific to that OS or compiler.
- I've messed up the distribution. Occasionally I edit a file at the last
minute without testing it properly... Normally these problems become apparent
quite quickly.
- There's an honest-to-goodness bug in wxWindows. Sorry! but wxWindows is
quite complex, and bugs happen. Whether you can classify not coping with
a particular setup a bug, I don't know, but there will be occasions when
installation reveals a bug. Mostly, though, real bugs are only identified
when applications get complex.
- Your compiler has not been installed properly. This is often signalled
by missing libraries such as iostream.
- There's a compiler incompatibility. This is extremely rare, since
wxWindows uses a very limited subset of C++ syntax, and steers
clear of unportable constructs such as templates.
- There's a bug in the compiler. This happens surprisingly often, particularly
with GNU C++ where the latest release might have a brand new bug. This can manifest
itself as a bizarre link error, or run-time problem such as the message "You must define an instance
of wxApp!" (globals haven't been initialized properly by the compiler).
- There's a bug in the OS, such as a lack of certain include files (it happened
with some versions of SunOS).
- You're using a compiler and/or OS that no-one's tested wxWindows out on before.
If you're really unlucky (and intrepid) you could find yourself doing a 'port'
to an environment never before encountered. In fact, the changes involved are
usually quite small, and are nearly always centred around wx_utils.cpp and wx_ipc.cpp
which make heavy demands on operating system-sensitive areas.
In general, the reason why compiling wxWindows can be more troublesome than other packages
is that with conventional application building, you gradually use more and more
parts of the operating system or GUI toolkit. With wxWindows, because it covers
a large 'surface area', you're encountering these possible troublespots all at once
when you compile the library.
The good side of all this is that once you have ironed out the initial compilation
and run-time problems, these particular headaches ought to be minimal from then on.
So don't be too discouraged if installation is initially difficult!
Borland C++ seems to generate the most traffic for installation problems. I'm
not exactly sure why this is, since although I don't have Borland C++, various
people have contributed tips and makefiles. I suspect that something about
the design of Borland C++ makes it difficult to compile a large project without a lot
of in-depth knowledge about the compiler options.