]>
Commit | Line | Data |
---|---|---|
ce3ed50d JS |
1 | <HTML> |
2 | ||
3 | <HEAD> | |
4 | <TITLE>wxWindows 2 for Windows FAQ</TITLE> | |
5 | </HEAD> | |
6 | ||
7 | <BODY BGCOLOR=#FFFFFF TEXT=#000000 LINK=#FF0000 VLINK=#000000> | |
8 | ||
9 | <font face="Arial, Lucida Sans, Helvetica"> | |
10 | ||
11 | <table width=100% border=4 cellpadding=5 cellspacing=0> | |
12 | <tr> | |
13 | <td bgcolor="#660000"> | |
14 | <font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF"> | |
15 | wxWindows 2 for Windows FAQ | |
16 | </font> | |
17 | </td> | |
18 | </tr> | |
19 | </table> | |
20 | ||
21 | <P> | |
22 | ||
23 | See also <a href="faq.htm">top-level FAQ page</a>. | |
24 | <hr> | |
25 | ||
b953bdc2 | 26 | <h3>Which Windows platforms are supported?</h3> |
ce3ed50d | 27 | |
0bc9b25e | 28 | wxWindows 2 can be used to develop and deliver applications on Windows 3.1, Win32s, |
b953bdc2 JS |
29 | Windows 95, Windows 98, and Windows NT. A Windows CE version is being looked into (see below).<P> |
30 | ||
31 | wxWindows 2 is designed to make use of WIN32 features and controls. However, unlike Microsoft, | |
32 | we have not forgotten users of 16-bit Windows. Most features | |
ce3ed50d | 33 | work under Windows 3.1, including wxTreeCtrl and wxListCtrl using the generic implementation. |
0bc9b25e | 34 | However, don't expect very Windows-95-specific classes to work, such as wxTaskBarIcon. The wxRegConfig |
ce3ed50d JS |
35 | class doesn't work either because the Windows 3.1 registry is very simplistic. Check out the 16-bit |
36 | makefiles to see what other files have been left out. | |
37 | <P> | |
38 | 16-bit compilation is supported under Visual C++ 1.5, and Borland BC++ 4 to 5. | |
39 | <P> | |
40 | ||
b953bdc2 JS |
41 | wxWindows 2 for Windows will also compile on Unix with gcc using TWIN32 from <a href="http://www.willows.com" target=_top>Willows</a>, |
42 | although TWIN32 is still in a preliminary state. The resulting executables are | |
43 | Unix binaries that work with the TWIN32 Windows API emulator.<P> | |
44 | ||
45 | You can also compile wxWindows 2 for Windows on Unix with Cygwin or Mingw32, resulting | |
46 | in executables that will run on Windows. So in theory you could write your applications | |
47 | using wxGTK or wxMotif, then check/debug your wxWindows for Windows | |
48 | programs with TWIN32, and finally produce an ix86 Windows executable using Cygwin/Mingw32, | |
49 | without ever needing a copy of Microsoft Windows. See the Technical Note on the Web site detailing cross-compilation.<P> | |
50 | ||
51 | <h3>What about Windows CE?</h3> | |
52 | ||
53 | This is under consideration, though we need to get wxWindows Unicode-aware first. | |
54 | There are other interesting issues, such as how to combine the menubar and toolbar APIs | |
55 | as Windows CE requires. But there's no doubt that it will be possible, albeit | |
56 | by mostly cutting down wxWindows 2 API functionality, and adding a few classes here | |
57 | and there. Since wxWindows for 2 produces small binaries (less than 300K for | |
58 | the statically-linked 'minimal' sample), shoehorning wxWindows 2 into a Windows CE device's limited | |
59 | storage should not be a problem.<P> | |
60 | ||
ce3ed50d JS |
61 | <h3>What compilers are supported?</h3> |
62 | ||
63 | Please see the wxWindows 2 for Windows install.txt file for up-to-date information, but | |
64 | currently the following are known to work:<P> | |
65 | ||
66 | <ul> | |
67 | <li>Visual C++ 1.5, 4.0, 5.0, 6.0 | |
68 | <li>Borland C++ 4.5, 5.0 | |
69 | <li>Borland C++Builder 1.0, 3.0 | |
70 | <li>Watcom C++ 10.6 (WIN32) | |
71 | <li>Cygwin b20 | |
72 | <li>Mingw32 | |
73 | <li>MetroWerks CodeWarrior 4 | |
74 | </ul> | |
75 | <P> | |
76 | ||
77 | There is a linking problem with Symantec C++ which I hope someone can help solve. | |
78 | <P> | |
79 | ||
80 | <h3>Which is the best compiler to use with wxWindows 2?</h3> | |
81 | ||
82 | It's partly a matter of taste, but I (JACS) prefer Visual C++ since the debugger is very | |
83 | good, it's very stable, the documentation is extensive, and it generates small executables. | |
84 | Since project files are plain text, it's easy for me to generate appropriate project files | |
85 | for wxWindows samples.<P> | |
86 | ||
87 | Borland C++ is fine - and very fast - but it's hard (impossible?) to use the debugger without using project files, and | |
88 | the debugger is nowhere near up to VC++'s quality. The IDE isn't great.<P> | |
89 | ||
90 | C++Builder's power isn't really used with wxWindows since it needs integration with its | |
91 | own class library (VCL). For wxWindows, I've only used it with makefiles, in which case | |
92 | it's almost identical to BC++ 5.0 (the same makefiles can be used).<P> | |
93 | ||
94 | You can't beat Cygwin's price (free), and you can debug adequately using gdb. However, it's | |
95 | quite slow to compile since it does not use precompiled headers.<P> | |
96 | ||
97 | CodeWarrior is cross-platform - you can debug and generate Windows executables from a Mac, but not | |
98 | the other way around I think - but the IDE is, to my mind, a bit primitive.<P> | |
99 | ||
100 | Watcom C++ is a little slow and the debugger is not really up to today's standards.<P> | |
101 | ||
102 | <h3>Is Unicode supported?</h3> | |
103 | ||
0bc9b25e | 104 | Not yet, although there are other internationalisation features.<P> |
ce3ed50d JS |
105 | |
106 | However, the issues surrounding Unicode support have been looked into so we know | |
107 | what we need to do, and have some header files ready to use containing appropriate | |
108 | type definitions. Just about every file in wxWindows will need changes, due to the | |
109 | pervasive nature of characters and character arrays. Unicode support is needed | |
0bc9b25e | 110 | for the port to Windows CE (see above), and will probably be added in time for version 2.1.<P> |
ce3ed50d | 111 | |
b953bdc2 | 112 | <h3>Can you compile wxWindows 2 as a DLL?</h3> |
ce3ed50d | 113 | |
9838df2c | 114 | Yes (using the Visual C++ or Borland C++ makefile), but be aware that distributing DLLs is a thorny issue |
b953bdc2 JS |
115 | and you may be better off compiling statically-linked applications, unless you're |
116 | delivering a suite of separate programs, or you're compiling a lot of wxWindows applications | |
117 | and have limited hard disk space.<P> | |
118 | ||
119 | With a DLL approach, and with different versions and configurations of wxWindows | |
120 | needing to be catered for, the end user may end up with a host of large DLLs in his or her Windows system directory, | |
121 | negating the point of using DLLs. Of course, this is not a problem just associated with | |
122 | wxWindows! | |
123 | <P> | |
124 | ||
9838df2c JS |
125 | <H3>How can I reduce executable size?</H3> |
126 | ||
127 | You can compile wxWindows as a DLL (see above, VC++/BC++ only at present). You should also | |
0bc9b25e JS |
128 | compile your programs for release using non-debugging and space-optimisation options, but |
129 | take with VC++ 5/6 space optimisation: it can sometimes cause problems.<P> | |
9838df2c JS |
130 | |
131 | Statically-linked wxWindows 2 programs are smaller than wxWindows 1.xx programs, because of the way | |
132 | wxWindows 2 has been designed to reduce dependencies between classes, and other | |
133 | techniques. The linker will not include code from the library that is not (directly or | |
134 | indirectly) referenced | |
135 | by your application. So for example, the 'minimal' sample is less than 300KB using VC++ 6.<P> | |
136 | ||
137 | If you want to distribute really small executables, you can | |
138 | use <a href="http://www.icl.ndirect.co.uk/petite/" target=_top>Petite</a> | |
139 | by Ian Luck. This nifty utility compresses Windows executables by around 50%, so your 500KB executable | |
140 | will shrink to a mere 250KB. With this sort of size, there is reduced incentive to | |
141 | use DLLs.<P> | |
142 | ||
0bc9b25e | 143 | <H3>Is wxWindows compatible with MFC?</H3> |
b953bdc2 JS |
144 | |
145 | There is a sample which demonstrates MFC and wxWindows code co-existing in the same | |
146 | application. However, don't expect to be able to enable wxWindows windows with OLE-2 | |
147 | functionality using MFC.<P> | |
ce3ed50d | 148 | |
ad813b00 JS |
149 | <H3>Why do I sometimes get bizarre crash problems using VC++ 5/6?</H3> |
150 | ||
151 | Some crash problems can be due to inconsistent compiler | |
152 | options (and of course this isn't limited to wxWindows). | |
153 | If strange/weird/impossible things start to happen please | |
154 | check (dumping IDE project file as makefile and doing text comparison | |
155 | if necessary) that the project settings, especially the list of defined | |
156 | symbols, struct packing, etc. are exactly the same for all items in | |
157 | the project. After this, delete everything (including PCH) and recompile.<P> | |
158 | ||
159 | VC++ 5's optimization code seems to be broken and can | |
160 | cause problems: this can be seen when deleting an object Dialog | |
161 | Editor, in Release mode with optimizations on. If in doubt, | |
162 | switch off optimisations, although this will result in much | |
163 | larger executables. It seems possible that the library can be created with | |
164 | strong optimization, so long as the application is not strongly | |
165 | optimized. For example, in wxWindows project, set to 'Minimum | |
166 | Size'. In Dialog Editor project, set to 'Customize: Favor Small | |
167 | Code' (and no others). This will then work.<P> | |
168 | ||
ce3ed50d JS |
169 | |
170 | </font> | |
171 | ||
172 | </BODY> | |
173 | ||
174 | </HTML> |