wxWindows 2 for Windows FAQ

See also top-level FAQ page.

Is Windows 3.1 supported?

Yes! 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 Windows 95-specific classes to work, such as wxTaskBar. 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.

What compilers are supported?

Please see the wxWindows 2 for Windows install.txt file for up-to-date information, but currently the following are known to work:

There is a linking problem with Symantec C++ which I hope someone can help solve.

Which is the best compiler to use with wxWindows 2?

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.

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.

Is Unicode supported?

No, although there are other internationalisation features.

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 below).

What about Windows CE?

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.