HGL with GHC in Win32

[Claus Reinke]

> A long-term goal is to refactor the code into a portable layer, a
> layer which can be ported (i.e., a maze of ifdefs) and a
> machine-dependent layer.  I'm not sure when I'll get to that - work,
> my current ffi hacking and some personal stuff are consuming all my
> time.

sounds familiar, and I've got to admit that the ffi part sounds more
interesting;-)

> > and <dream>HOpenGL works with all Haskell implementations</dream>,
> > perhaps HGL could be ported to HOpenGL - to eliminate all further
> > portability issues (missing features under X, etc.)..
>
> I think the basic HGL API would work on a lot of platforms.  I don't
> know enough about HOpenGL to be sure but I think it's easier to
> implement HGL on than X11 or Win32 were.

I'm not sure how to parse this, but the idea was that OpenGL is already
available (and hardware-supported) on many platforms (www.opengl.org),
and that it is the most likely route for more advanced graphics hackers.
So an HGL as a learner's 2d interface to the full thing might be interesting
in itself, but it should also permit to merge the x11/win32/whatever branches
into a single one.. (modulo some minor infelicities, of course)

> That sounds like my experience of the hslibs tree - once it has been
> assimilated it is really hard to use it in isolation.
>
> The file Win32Dialogue.gc does genuinely seem to be missing something
> - but it sounds like you had more problems than just that.

Yep indeed. One was easy to fix - my win98 laptop had an old version of
ghc-5.02.. after upgrading to 5.02.3, the effects here are now similar to
what happens on the win2k system (only that instead of a full-screen titlebar,
I get more-than-full-screen windows), so I had another look.

The size problem is traceable to window creation (GraphicsWND.hs:
createWND), where there is a call to adjustWindowRect in calcSize -
adding a print there gives sensible values from within hugs, and large-valued
nonsense from within ghc-compiled executables. So there is something fishy
going on with ghc's win32 binding (which is where adjustWindowRect seems
to reside, even though simple "hello world"-style programs still work fine.

Which seemed to remind me of an earlier thread, and sure enough, in March,
Hal Daume complained about just the same problem with HGL, GHC, Windows,
and the outcome was that there is a bug in greencard's ffi target, which you
set out to fix, recommending the use of the ghc target in the meantime:

http://haskell.org/pipermail/glasgow-haskell-bugs/2002-March/002269.html

In light of this, ghc's win32 ought to be re-greencarded anyway (once
greencard's ffi target is fixed for ghc, which seems to be in progress:),
before the next release, no?

By fiddling with your makefile a bit, I managed to re-greencard, but now the
cvs-makefile (which I managed to convince that I don't want a separate
GHC_INPLACE/GHC_PKG_INPLACE, and that I don't want to update
my package config, even if my ghc-pkg had such an option..) tries to split
objects into a non-existing directory, and sure enough, if I create that
directory,
that step works fine, but the next one looks for the split objects in another
directory.. and with fptools makefiles, it is not at all straightforward for me
to
tell where the problem is, let alone what it is:-( the effect is that the
assembler
complains that it can't generate .o files in StdDIS/, say, whereas the files
should really go into StdDIS_split/ instead, methinks..

Could someone with more fptools-experience than myself please have a look
at hslibs/win32 and its Makefiles, and preferably re-generate the Haskell
sources in there from the .{gc,pgc} files in win32/gc-src, using a debugged
greencard (changing to the ghc target is probably not a good idea for a cvs
depot used by non-ghc folks as well;-).

> This will gain momentum once Hugs switches over to using the new
> hierarchial libraries.
>
> And that will gain momentum once Hugs switches over to the new FFI.

As an old fan of hugs, I'm glad that it keeps up with developments!-)

Claus