1999-01-19 06:00:22 -05:00
|
|
|
<HTML>
|
|
|
|
|
|
|
|
|
|
<HEAD>
|
|
|
|
|
<TITLE>wxWindows 2 for Windows FAQ</TITLE>
|
|
|
|
|
</HEAD>
|
|
|
|
|
|
|
|
|
|
<BODY BGCOLOR=#FFFFFF TEXT=#000000 LINK=#FF0000 VLINK=#000000>
|
|
|
|
|
|
|
|
|
|
<font face="Arial, Lucida Sans, Helvetica">
|
|
|
|
|
|
|
|
|
|
<table width=100% border=4 cellpadding=5 cellspacing=0>
|
|
|
|
|
<tr>
|
|
|
|
|
<td bgcolor="#660000">
|
|
|
|
|
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
|
|
|
|
|
wxWindows 2 for Windows FAQ
|
|
|
|
|
</font>
|
|
|
|
|
</td>
|
|
|
|
|
</tr>
|
|
|
|
|
</table>
|
|
|
|
|
|
|
|
|
|
<P>
|
|
|
|
|
|
|
|
|
|
See also <a href="faq.htm">top-level FAQ page</a>.
|
|
|
|
|
<hr>
|
|
|
|
|
|
1999-01-19 17:14:23 -05:00
|
|
|
<h3>Which Windows platforms are supported?</h3>
|
1999-01-19 06:00:22 -05:00
|
|
|
|
1999-02-19 16:54:37 -05:00
|
|
|
wxWindows 2 can be used to develop and deliver applications on Windows 3.1, Win32s,
|
1999-01-19 17:14:23 -05:00
|
|
|
Windows 95, Windows 98, and Windows NT. A Windows CE version is being looked into (see below).<P>
|
|
|
|
|
|
|
|
|
|
wxWindows 2 is designed to make use of WIN32 features and controls. However, unlike Microsoft,
|
|
|
|
|
we have not forgotten users of 16-bit Windows. Most features
|
1999-01-19 06:00:22 -05:00
|
|
|
work under Windows 3.1, including wxTreeCtrl and wxListCtrl using the generic implementation.
|
1999-02-19 16:54:37 -05:00
|
|
|
However, don't expect very Windows-95-specific classes to work, such as wxTaskBarIcon. The wxRegConfig
|
1999-01-19 06:00:22 -05:00
|
|
|
class doesn't work either because the Windows 3.1 registry is very simplistic. Check out the 16-bit
|
|
|
|
|
makefiles to see what other files have been left out.
|
|
|
|
|
<P>
|
|
|
|
|
16-bit compilation is supported under Visual C++ 1.5, and Borland BC++ 4 to 5.
|
|
|
|
|
<P>
|
|
|
|
|
|
1999-01-19 17:14:23 -05:00
|
|
|
wxWindows 2 for Windows will also compile on Unix with gcc using TWIN32 from <a href="http://www.willows.com" target=_top>Willows</a>,
|
|
|
|
|
although TWIN32 is still in a preliminary state. The resulting executables are
|
|
|
|
|
Unix binaries that work with the TWIN32 Windows API emulator.<P>
|
|
|
|
|
|
|
|
|
|
You can also compile wxWindows 2 for Windows on Unix with Cygwin or Mingw32, resulting
|
|
|
|
|
in executables that will run on Windows. So in theory you could write your applications
|
|
|
|
|
using wxGTK or wxMotif, then check/debug your wxWindows for Windows
|
|
|
|
|
programs with TWIN32, and finally produce an ix86 Windows executable using Cygwin/Mingw32,
|
|
|
|
|
without ever needing a copy of Microsoft Windows. See the Technical Note on the Web site detailing cross-compilation.<P>
|
|
|
|
|
|
|
|
|
|
<h3>What about Windows CE?</h3>
|
|
|
|
|
|
|
|
|
|
This is under consideration, though we need to get wxWindows Unicode-aware first.
|
|
|
|
|
There are other interesting issues, such as how to combine the menubar and toolbar APIs
|
|
|
|
|
as Windows CE requires. But there's no doubt that it will be possible, albeit
|
|
|
|
|
by mostly cutting down wxWindows 2 API functionality, and adding a few classes here
|
|
|
|
|
and there. Since wxWindows for 2 produces small binaries (less than 300K for
|
|
|
|
|
the statically-linked 'minimal' sample), shoehorning wxWindows 2 into a Windows CE device's limited
|
|
|
|
|
storage should not be a problem.<P>
|
|
|
|
|
|
1999-01-19 06:00:22 -05:00
|
|
|
<h3>What compilers are supported?</h3>
|
|
|
|
|
|
|
|
|
|
Please see the wxWindows 2 for Windows install.txt file for up-to-date information, but
|
|
|
|
|
currently the following are known to work:<P>
|
|
|
|
|
|
|
|
|
|
<ul>
|
|
|
|
|
<li>Visual C++ 1.5, 4.0, 5.0, 6.0
|
|
|
|
|
<li>Borland C++ 4.5, 5.0
|
|
|
|
|
<li>Borland C++Builder 1.0, 3.0
|
|
|
|
|
<li>Watcom C++ 10.6 (WIN32)
|
|
|
|
|
<li>Cygwin b20
|
|
|
|
|
<li>Mingw32
|
|
|
|
|
<li>MetroWerks CodeWarrior 4
|
|
|
|
|
</ul>
|
|
|
|
|
<P>
|
|
|
|
|
|
|
|
|
|
There is a linking problem with Symantec C++ which I hope someone can help solve.
|
|
|
|
|
<P>
|
|
|
|
|
|
|
|
|
|
<h3>Which is the best compiler to use with wxWindows 2?</h3>
|
|
|
|
|
|
|
|
|
|
It's partly a matter of taste, but I (JACS) prefer Visual C++ since the debugger is very
|
|
|
|
|
good, it's very stable, the documentation is extensive, and it generates small executables.
|
|
|
|
|
Since project files are plain text, it's easy for me to generate appropriate project files
|
|
|
|
|
for wxWindows samples.<P>
|
|
|
|
|
|
|
|
|
|
Borland C++ is fine - and very fast - but it's hard (impossible?) to use the debugger without using project files, and
|
|
|
|
|
the debugger is nowhere near up to VC++'s quality. The IDE isn't great.<P>
|
|
|
|
|
|
|
|
|
|
C++Builder's power isn't really used with wxWindows since it needs integration with its
|
|
|
|
|
own class library (VCL). For wxWindows, I've only used it with makefiles, in which case
|
|
|
|
|
it's almost identical to BC++ 5.0 (the same makefiles can be used).<P>
|
|
|
|
|
|
|
|
|
|
You can't beat Cygwin's price (free), and you can debug adequately using gdb. However, it's
|
|
|
|
|
quite slow to compile since it does not use precompiled headers.<P>
|
|
|
|
|
|
|
|
|
|
CodeWarrior is cross-platform - you can debug and generate Windows executables from a Mac, but not
|
|
|
|
|
the other way around I think - but the IDE is, to my mind, a bit primitive.<P>
|
|
|
|
|
|
|
|
|
|
Watcom C++ is a little slow and the debugger is not really up to today's standards.<P>
|
|
|
|
|
|
|
|
|
|
<h3>Is Unicode supported?</h3>
|
|
|
|
|
|
1999-02-19 16:54:37 -05:00
|
|
|
Not yet, although there are other internationalisation features.<P>
|
1999-01-19 06:00:22 -05:00
|
|
|
|
|
|
|
|
However, the issues surrounding Unicode support have been looked into so we know
|
|
|
|
|
what we need to do, and have some header files ready to use containing appropriate
|
|
|
|
|
type definitions. Just about every file in wxWindows will need changes, due to the
|
|
|
|
|
pervasive nature of characters and character arrays. Unicode support is needed
|
1999-02-19 16:54:37 -05:00
|
|
|
for the port to Windows CE (see above), and will probably be added in time for version 2.1.<P>
|
1999-01-19 06:00:22 -05:00
|
|
|
|
1999-01-19 17:14:23 -05:00
|
|
|
<h3>Can you compile wxWindows 2 as a DLL?</h3>
|
1999-01-19 06:00:22 -05:00
|
|
|
|
1999-01-24 09:57:09 -05:00
|
|
|
Yes (using the Visual C++ or Borland C++ makefile), but be aware that distributing DLLs is a thorny issue
|
1999-01-19 17:14:23 -05:00
|
|
|
and you may be better off compiling statically-linked applications, unless you're
|
|
|
|
|
delivering a suite of separate programs, or you're compiling a lot of wxWindows applications
|
|
|
|
|
and have limited hard disk space.<P>
|
|
|
|
|
|
|
|
|
|
With a DLL approach, and with different versions and configurations of wxWindows
|
|
|
|
|
needing to be catered for, the end user may end up with a host of large DLLs in his or her Windows system directory,
|
|
|
|
|
negating the point of using DLLs. Of course, this is not a problem just associated with
|
|
|
|
|
wxWindows!
|
|
|
|
|
<P>
|
|
|
|
|
|
1999-01-24 09:57:09 -05:00
|
|
|
<H3>How can I reduce executable size?</H3>
|
|
|
|
|
|
|
|
|
|
You can compile wxWindows as a DLL (see above, VC++/BC++ only at present). You should also
|
1999-02-19 16:54:37 -05:00
|
|
|
compile your programs for release using non-debugging and space-optimisation options, but
|
|
|
|
|
take with VC++ 5/6 space optimisation: it can sometimes cause problems.<P>
|
1999-01-24 09:57:09 -05:00
|
|
|
|
|
|
|
|
Statically-linked wxWindows 2 programs are smaller than wxWindows 1.xx programs, because of the way
|
|
|
|
|
wxWindows 2 has been designed to reduce dependencies between classes, and other
|
|
|
|
|
techniques. The linker will not include code from the library that is not (directly or
|
|
|
|
|
indirectly) referenced
|
|
|
|
|
by your application. So for example, the 'minimal' sample is less than 300KB using VC++ 6.<P>
|
|
|
|
|
|
|
|
|
|
If you want to distribute really small executables, you can
|
|
|
|
|
use <a href="http://www.icl.ndirect.co.uk/petite/" target=_top>Petite</a>
|
|
|
|
|
by Ian Luck. This nifty utility compresses Windows executables by around 50%, so your 500KB executable
|
|
|
|
|
will shrink to a mere 250KB. With this sort of size, there is reduced incentive to
|
|
|
|
|
use DLLs.<P>
|
|
|
|
|
|
1999-02-19 16:54:37 -05:00
|
|
|
<H3>Is wxWindows compatible with MFC?</H3>
|
1999-01-19 17:14:23 -05:00
|
|
|
|
|
|
|
|
There is a sample which demonstrates MFC and wxWindows code co-existing in the same
|
|
|
|
|
application. However, don't expect to be able to enable wxWindows windows with OLE-2
|
|
|
|
|
functionality using MFC.<P>
|
1999-01-19 06:00:22 -05:00
|
|
|
|
1999-02-24 03:02:28 -05:00
|
|
|
<H3>Why do I sometimes get bizarre crash problems using VC++ 5/6?</H3>
|
|
|
|
|
|
|
|
|
|
Some crash problems can be due to inconsistent compiler
|
|
|
|
|
options (and of course this isn't limited to wxWindows).
|
|
|
|
|
If strange/weird/impossible things start to happen please
|
|
|
|
|
check (dumping IDE project file as makefile and doing text comparison
|
|
|
|
|
if necessary) that the project settings, especially the list of defined
|
|
|
|
|
symbols, struct packing, etc. are exactly the same for all items in
|
|
|
|
|
the project. After this, delete everything (including PCH) and recompile.<P>
|
|
|
|
|
|
|
|
|
|
VC++ 5's optimization code seems to be broken and can
|
|
|
|
|
cause problems: this can be seen when deleting an object Dialog
|
|
|
|
|
Editor, in Release mode with optimizations on. If in doubt,
|
|
|
|
|
switch off optimisations, although this will result in much
|
|
|
|
|
larger executables. It seems possible that the library can be created with
|
|
|
|
|
strong optimization, so long as the application is not strongly
|
|
|
|
|
optimized. For example, in wxWindows project, set to 'Minimum
|
|
|
|
|
Size'. In Dialog Editor project, set to 'Customize: Favor Small
|
|
|
|
|
Code' (and no others). This will then work.<P>
|
|
|
|
|
|
1999-08-06 11:59:31 -04:00
|
|
|
<H3>How are the wxWindows makefiles edited under Windows?</H3>
|
|
|
|
|
|
|
|
|
|
As of wxWindows 2.1, there is a new system written by Vadim Zeitlin, that
|
|
|
|
|
generates the makefiles from templates using tmake.<P>
|
|
|
|
|
|
|
|
|
|
Here are Vadim's notes:<P>
|
|
|
|
|
|
|
|
|
|
<blockquote>
|
|
|
|
|
To use these new makefiles, you don't need anything (but see below).
|
|
|
|
|
However, you should NOT modify them because these files will be
|
|
|
|
|
rewritten when I regenerate them using tmake the next time. So, if
|
|
|
|
|
you find a problem with any of these makefiles (say, makefile.b32)
|
|
|
|
|
you'll need to modify the corresponding template (b32.t in this
|
|
|
|
|
example) and regenerate the makefile using tmake.<P>
|
|
|
|
|
|
|
|
|
|
tmake can be found at
|
|
|
|
|
<a href="http://www.troll.no/freebies/tmake.html" target=_new>www.troll.no/freebies/tmake.html</a>.
|
|
|
|
|
It's a Perl5 program and so it needs Perl (doh). There is a binary for
|
|
|
|
|
Windows (available from the same page), but I haven't used it, so
|
|
|
|
|
I don't know if it works as flawlessly as "perl tmake" does (note
|
|
|
|
|
for people knowing Perl: don't try to run tmake with -w, it won't
|
|
|
|
|
do you any good). Using it extremely simple: to regenerate makefile.b32
|
|
|
|
|
just go to distrib/msw/tmake and type<P>
|
|
|
|
|
|
|
|
|
|
<pre>tmake -t b32 wxwin.pro -o ../../src/msw/makefile.b32</pre><P>
|
|
|
|
|
|
|
|
|
|
The makefiles are untested - I don't have any of Borland, Watcom or
|
|
|
|
|
Symantec and I don't have enough diskspace to recompile even with
|
|
|
|
|
VC6 using makefiles. The new makefiles are as close as possible to the
|
|
|
|
|
old ones, but not closer: in fact, there has been many strange things
|
|
|
|
|
(should I say bugs?) in some of makefiles, some files were not compiled
|
|
|
|
|
without any reason etc. Please test them and notify me about any problems.
|
|
|
|
|
Better yet, modify the template files to generate the correct makefiles
|
|
|
|
|
and check them in.<P>
|
|
|
|
|
|
|
|
|
|
The templates are described in tmake ref manual (1-2 pages of text)
|
|
|
|
|
and are quite simple. They do contain some Perl code, but my Perl is
|
|
|
|
|
primitive (very C like) so it should be possible for anybody to make
|
|
|
|
|
trivial modifications to it (I hope that only trivial modifications
|
|
|
|
|
will be needed). I've tagged the ol makefiles as MAKEFILES_WITHOUT_TMAKE
|
|
|
|
|
in the cvs, so you can always retrieve them and compare the new ones,
|
|
|
|
|
this will make it easier to solve the problems you might have.<P>
|
|
|
|
|
|
|
|
|
|
Another important file is filelist.txt: it contains the list of all
|
|
|
|
|
files to be compiled. Some of them are only compiled in 16/32 bit mode.
|
|
|
|
|
Some other are only compiled with some compilers (others can't compile
|
|
|
|
|
them) - all this info is contained in this file.<P>
|
|
|
|
|
|
|
|
|
|
So now adding a new file to wxWindows is as easy as modifying filelist.txt
|
|
|
|
|
(and Makefile.ams for Unix ports) and regenerating the makefiles - no
|
|
|
|
|
need to modify all files manually any more.<P>
|
|
|
|
|
|
|
|
|
|
Finally, there is also a file vc6.t which I use myself: this one
|
|
|
|
|
generates a project file for VC++ 6.0 (I didn't create vc5.t because
|
|
|
|
|
I don't need it and can't test it, but it should be trivial to create
|
|
|
|
|
one from vc6.t - probably the only things to change would be the
|
|
|
|
|
version number in the very beginning and the /Z option - VC5 doesn't
|
|
|
|
|
support edit-and=continue). This is not an officially supported way
|
|
|
|
|
of building wxWindows (that is, nobody guarantees that it will work),
|
|
|
|
|
but it has been very useful to me and I hope it will be also for
|
|
|
|
|
others. To generate wxWindows.dsp run<P>
|
|
|
|
|
|
|
|
|
|
<pre>tmake -t vc6 wxwin.pro -o ../../wxWindows.dsp</pre><P>
|
|
|
|
|
|
|
|
|
|
Then just include this project in any workspace or open it from VC IDE
|
|
|
|
|
and it will create a new workspace for you.<P>
|
|
|
|
|
|
|
|
|
|
If all goes well, I'm planning to create a template file for Makefile.ams
|
|
|
|
|
under src/gtk and src/motif and also replace all makefiles in the samples
|
|
|
|
|
subdirectories with the project files from which all the others will be
|
|
|
|
|
generated. At least it will divide the number of files in samples
|
|
|
|
|
directory by 10 (and the number of files to be maintained too).
|
|
|
|
|
</blockquote>
|
1999-01-19 06:00:22 -05:00
|
|
|
|
2000-01-30 08:43:37 -05:00
|
|
|
<P>
|
|
|
|
|
|
|
|
|
|
<H3>How do you use VC++'s memory leak checking instead of that in wxWindows?</H3>
|
|
|
|
|
|
|
|
|
|
Vadim Zeitlin:
|
|
|
|
|
|
|
|
|
|
<pre>
|
|
|
|
|
On the VC++ level, it's just the matter of calling _CrtSetDbgFlag() in the very
|
|
|
|
|
beginning of the program. In wxWindows, this is done automatically when
|
|
|
|
|
compiling with VC++ in debug mode unless wxUSE_GLOBAL_MEMORY_OPERATORS or
|
|
|
|
|
__NO_VC_CRTDBG__ are defined - this check is done in wx/msw/msvcrt.h which
|
|
|
|
|
is included from app.cpp which then calls wxCrtSetDbgFlag() without any
|
|
|
|
|
#ifdefs.
|
|
|
|
|
|
|
|
|
|
This works quite well: at the end of the program, all leaked blocks with their
|
|
|
|
|
malloc count are shown. This number (malloc count) can be used to determine
|
|
|
|
|
where exactly the object was allocated: for this it's enough to set the variable
|
|
|
|
|
_crtBreakAlloc (look in VC98\crt\srs\dbgheap.c line 326) to this number and
|
|
|
|
|
a breakpoint will be triggered when the block with this number is allocated.
|
|
|
|
|
|
|
|
|
|
For simple situations it works like a charm. For something more complicated
|
|
|
|
|
like reading uninitialized memory a specialized tool is probably better...
|
|
|
|
|
|
|
|
|
|
Regards,
|
|
|
|
|
VZ
|
|
|
|
|
</pre>
|
|
|
|
|
|
|
|
|
|
|
1999-01-19 06:00:22 -05:00
|
|
|
</font>
|
|
|
|
|
|
|
|
|
|
</BODY>
|
|
|
|
|
|
|
|
|
|
</HTML>
|
