[ZooLib-dev] ZooLib builds with CygWin/g++ on Windows

[Michael D. C. <cra...@go...>]

But it doesn't run - yet.

I have been tinkering around with getting ZooLib to work on Windows by building
it with CygWin.

If you're not familiar with it, CygWin is a GNU Unix-like shell environment for
Windows.  You can download it from http://sources.redhat.com/cygwin/  Source
code is provided for everything, and most of the components are under the GNU
General Public License.  It's about 100 megabytes and comes with a lot of stuff.

The usual purpose of programming with CygWin is to port some Unix command-line
tool to Windows.  Andy was pretty horrified when I told him I wanted to try
building ZooLib with it.
But it turns out it's not too hard to build a traditional Windows application
with CygWin, the developers have written their own versions of the win32 header
files and linking libraries.

Once I really got a chance to concentrate on it it took about 5 hours to get a
ZooLib application to successfully link with gmake and g++ under CygWin.  There
seem to be only a couple places where I had actual incompatibilities in the
code, as most of ZooLib's code already builds with g++ on Linux.

So far it doesn't run, although I haven't tried much to debug it.  Happily,
CygWin provides a nice GUI version of the GDB debugger and I can see at least
that my crash is consistent.
So I expect I can get it working before long, and then I'll write up some more
detailed notes.

I was working with a fairly recent version of the development sources.  I'll
make sure I have the latest before I finish.  These are later than what is
publicly released on SourceForge.  I think Andy would like to make a new source
drop to the public before too long but his life's been all topsy-turvy lately
with a move to a new home.

There's some other stuff I want to get working in ZooLib myself for the next
release - BeOS PowerPC, FreeBSD, and at some point Solaris Sparc.

I managed to build it with small modifications to the "makefile" in my build
directory and "realmake" in the project's source directory.  The project I'm
using is a tool for testing out some ideas on making ZPaneLocators easier to
use, and I'll be releasing the source to that at least by the next time ZooLib
itself is released.

The problems I had were:

- I needed to specify a few flags on the g++ command line through the makefile,
notably "-DZCONFIG_OS=ZCONFIG_OS_Win32".   CygWin defines _WIN32_ or whatever in
the preprocessor so it probably is possible to have the zconfig headers
automatically tell we're on windows even though gcc is used.

- Andy has defined compiler-specific versions of ZMain() in ZMain.cpp (the newer
code supports visual C++) and I added another to support GCC.  It appears that
GCC knows about __argc and __argv to give the command line parameters to a Win32
application, but the link fails if it's a GUI app.  Or something.  Anyway, I
couldn't use __argc and __argv.

- the Win32 header files provided by CygWin aren't quite compatible with those
provided by Metrowerks and Microsoft, so I had to add some header files to those
included in ZDragClip.h.  This started with trying to get a definition for
CLIPFORMAT, but then I needed to include some others to make the header that had
that in it compile.

- I think gcc is funny about using the function form of typecasting.  That is,
some constructions that contain stuff like:

   short( 42 );

this caused trouble in a line that cast the results of the HIWORD and LOWORD
macros somewhere.  It worked to change the code slighly to something else that
was equivalent.

I mentioned on another mailing list that g++ won't compile the following line,
while Visual C++ and Codewarrior will:

	unsigned long ul;

	ul = unsigned long( 25 );

and someone told me that it was actually g++ that had the correct behaviour. 
I'm not enough of a language lawyer to know.  My understanding is that this form
of a cast is actually a call to the copy constructor, and I guess there aren't
exactly copy constructors for built-in types.  Whatever.

- CygWin doesn't provide #include <limits>, so I had to add another case to
where this is already handled for Posix.

- There was some problem I just couldn't figure out with the use of ::toupper in
some menu code.  I just #ifdefed the code out for now.

- I had to add references to the source files for the windows-specific platform
code to my realmake file.  In general it should work to include all the
platform-specific files in any platform's build, because the whole files are
guarded with #if's - at worst it just makes one's builds a little bit slower. 
So I should be able to build for BeOS, Linux and Win32 with the same realmake
file.

- most of the inline assembler seems to be OK, as it seems to pick up the
GCC-style syntax that was originally written for the Linux build when compiling
the ZAtomic stuff.  But there is some additional inline assembler in
ZDebug_Win.cpp that just uses syntax compatible with CodeWarrior and Visual
C++.  I put in conditionals and wrote down my best guess as to what would work
for gcc, but it didn't work.  I'll see if I can find a tutorial on gcc inline
assembler.  It's not a big deal for now, I used conditional code to make the
check for a debugger always return true, and made the call to
ZDebug_DisplayMessage call abort().

Oh, yeah, and my executable came out being named "panelocators.exe-debug".  I
just renamed it after the build.

Mike
-- 
Michael D. Crawford
GoingWare Inc. - Expert Software Development and Consulting
http://www.goingware.com
cra...@go...

  Tilting at Windmills for a Better Tomorrow.