| + +wxWindows 2 for Windows FAQ + + | +
+ +See also top-level FAQ page. +
+ +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 +work under Windows 3.1, including wxTreeCtrl and wxListCtrl using the generic implementation. +However, don't expect very Windows-95-specific classes to work, such as wxTaskBarIcon. The wxRegConfig +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. +
+16-bit compilation is supported under Visual C++ 1.5, and Borland BC++ 4 to 5. +
+ +wxWindows 2 for Windows will also compile on Unix with gcc using TWIN32 from Willows, +although TWIN32 is still in a preliminary state. The resulting executables are +Unix binaries that work with the TWIN32 Windows API emulator.
+ +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.
+ +
+ +
+ +
+ +There is a linking problem with Symantec C++ which I hope someone can help solve. +
+ +
+ +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.
+ +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).
+ +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.
+ +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.
+ +Watcom C++ is a little slow and the debugger is not really up to today's standards.
+ +
+ +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 +for the port to Windows CE (see above), and will probably be added in time for version 2.1.
+ +
+ +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! +
+ +
+ +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.
+ +If you want to distribute really small executables, you can +use Petite +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.
+ +
+ +
+ +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.
+ +
+ +Here are Vadim's notes:
+ +
+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.+ + + + + ++ +tmake can be found at +www.troll.no/freebies/tmake.html. +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
+ +
tmake -t b32 wxwin.pro -o ../../src/msw/makefile.b32+ +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.
+ +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.
+ +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.
+ +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.
+ + 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
+ +
tmake -t vc6 wxwin.pro -o ../../wxWindows.dsp+ +Then just include this project in any workspace or open it from VC IDE +and it will create a new workspace for you.
+ +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). +