HGL ang GHC on Win32

Alastair David Reid reid@cs.utah.edu
13 Mar 2002 03:09:48 +0000


> When I compile a program using GHC 5.02.2 on Windows 200 using HGL,

I don't have GHC installed on my Windows partition (nor space for it,
I suspect) so I'll ask some questions and hope they suggest an answer.

Does it work ok using Hugs and HGL?

   Sigbjorn Finne did a great job of packaging both Hugs and HGL as
   .msi files so it should be quick to check.

   Be sure to use December 2002 Hugs and version 2.0.4 HGL (i.e., the
   versions currently on the web pages.

Any luck using ghci?  (Unlikely to be any better)

Does rebooting your machine help?  (This is one of the larger straws
 I'm going to grasp at.)

> when I run the exe, the window starts out initially as wide as my
> screen and only as tall as the title bar, regardless of what is
> passed as the dimensions to openWindow.  What gives?

I haven't heard of this before.

A quick glance at the code doesn't suggest anything.

Grasping at straws, here's an implausible story for what is going
wrong (doesn't suggest how it would work for other people but not for
you):

  If you use openWindow, the position on the screen is not specified
  (just the size).  In Haskell, this is expressed as Nothing but in
  (this corner of) the Win32 API, it is expressed by specifying
  -1 for the X and Y position.

  It is just possible that something has gone wrong in how that -1 is
  passed over from Haskell to C and that this has somehow gotten
  confused with the window size.

  You could test this implausible theory by changing the openWindow
  call in HelloWorld to read

    w <- openWindowEx "Hello World Window" 
                      (Just (100,100)) (300, 300) 
                      Unbuffered Nothing
  
> If I resize the window everything works fine, but in my own
> application resizing the window causes it to report some error about
> arithmetic being bigger than 32 bits...

This might agree with my theory about -1's being passed around.
The -1 might somehow come back as the maximum unsigned int 0xffffffff
and almost any arithmetic operation on that would lead to overflow.
Except that GHC doesn't detect overflow...

> Any ideas?

No good ones.

I'm hoping that a GHC honcho will say 

  "Well of course that happens with 5.02.2 - you should upgrade to 5.03
  right away."

or some such.

Sorry I can't be more help,

Alastair Reid