Folks,
Last night I managed to compile, link, and successfully run
all(1) samples that come with wxWindows.
In all honesty I am overjoyed! Let me explain why:
-- wxWindows is a large piece of software that touches on
most (if not all) Wine aspects. It does put our headers
through their paces.
-- The porting effort has been simple, and it took me
a just a few days to do it.
-- I have not used _any_ of the previous efforts to port
wxWindows to Wine. I rather started with their MinGW port.
-- Most of the changes have been trivial fixes for Wine
which I have sent to wine-patches in the last few days.
-- The hacks to wxWindows have been trivial and few in
number. I have touched only a few files, and the
changes are real simple. They'll need some cleaning up,
and I'll submit them to the wxWindows folks for inclusion.
-- The wine{gcc,wrap} combo is a great success. All I had
to do was to touch only *one* file (makeg95.env), and
modify only a few lines to get *everything* to compile
and link.
What does Wine get out of it:
-- A good test for our headers
-- Proof that wine{gcc,wrap} are a good idea (at least for me)
-- A large number of sample that show quite a few problems in Wine.
If anyone is interested in more details please let me know, and I'll
be glad to provide them. Once we decide on the __WINE__ vs. __WINESRC__
thing, I'll cleanup the wxWindows changes and submit them for inclusion
in their tree, so hopefully you'll be able to play with it using the
official version not before long.
Notes
1. All but a few:
- 'dialup' did not compile because I had to disable dialup
support in wxWindows since wine does not have a wininet.h
- 'proplist' did not compile because I forgot to enable property
lists in the configuration when I compiled wxWindows
- 'tab' sample did not compile because it's recommended
to not enable this deprecated option, so I did not.
- the samples 'listbox', 'memcheck', and 'opengl/*' are not
supported by wxWindows under MinGW, so I did not bother.
--
Dimi.