X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/7921cf2badfac0c44cd53644bfc6a483a09ec299..a70ab3b804b6c363f8bcbed0b4fce94b7fb03612:/docs/html/faqmsw.htm

diff --git a/docs/html/faqmsw.htm b/docs/html/faqmsw.htm
deleted file mode 100644
index 2f600a7cf6..0000000000
--- a/docs/html/faqmsw.htm
+++ /dev/null
@@ -1,154 +0,0 @@
-<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>
-
-<h3>Which Windows platforms are supported?</h3>
-
-wxWindows can be used to develop and deliver applications on Windows 3.1, Win32s,
-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
-work under Windows 3.1, including wxTreeCtrl and wxListCtrl using the generic implementation.
-However, don't expect very Windows-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.
-<P>
-16-bit compilation is supported under Visual C++ 1.5, and Borland BC++ 4 to 5.
-<P>
-
-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>
-
-<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>
-
-No, although there are other internationalisation features.<P>
-
-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).<P>
-
-<h3>Can you compile wxWindows 2 as a DLL?</h3>
-
-Yes (using the Visual C++ or Borland C++ makefile), but be aware that distributing DLLs is a thorny issue
-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>
-
-<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
-compile your programs for release using non-debugging and space-optimisation options.<P>
-
-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>
-
-
-<H3>Will wxWindows be compatible with MFC?</H3>
-
-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>
-
-
-</font>
-
-</BODY>
-
-</HTML>