Hi, Attached is a patch which gets WinHugs back to life. The Winframe.c change is just to remove an obsolete header file - it turns on 3d look and feel on Win3.1, but its so old now that new compilers don't ship with it, and it has no effect anyway. The changes to Char.h and WinText.h fix up the output. Since WinHugs last worked the program has moved to using unicode output functions, which were not trapped. This traps them and redirects them towards the WinHugs GUI. With these changes, I can build WinHugs using Visual Studio.NET. The haskell libraries I am using were hacked and mangled from the RPM's released in 2005, with small changes. My next task will be to get them building in a "better" way. Thanks Neil On 5/19/05, Ross Paterson wrote:

On Thu, May 19, 2005 at 02:14:57PM +0100, Neil Mitchell wrote:

...

I've been using WinHugs for a few years now. I notice that the 2005 release does not contain Windows binaries, which I think is a shame, because its a very nice environment for developing in (particularly WinHugs). I am volunteering to get WinHugs building, compiled, and to create an installer for it (as much as I can). I have years of experience in Haskell and C++.

Your help will be very welcome.

...

I have already checked out the CVS source for Hugs, and have the GUI popping up (before failing to load the prelude, but I'm sure thats minor).

To make this work, you need to build the libraries (including the Prelude). Currently the only way to do this is with one of the Unix-like environments for Windows. I'd recommend MSYS + MinGW (http://www.mingw.org/). You also need to check out fptools/libraries and fptools/hslibs under your hugs source directory. Then 'make' in the top-level directory should build the interpreter and libraries. There may well be glitches with that step, but hopefully easily fixed. Then you'll have libraries that can be used with your WinHugs build.

Hugs has recently switched to using Cabal to build its libraries. If Cabal worked properly on Windows, it might be possible to build them without the Unix-like environment, but that's another task.

On Fri, May 20, 2005 at 03:42:05PM +0100, Neil Mitchell wrote:

An additional patch to the Windows version to change from using a customised status line implementation, to using the standard windows one. After this patch is merged, Winstln.{c,h} can be removed as they are no long required.

Thanks, I've committed this.

I would like to do this to some of the other parts of WinHugs, particularly the toolbar and tooltip/hint windows. By using the standard Windows versions, it makes WinHugs smaller, less code, and it can use the standard versions which are styled differently on different platforms - i.e. to take advantage of the new XP style interface.

Sounds good to me.

Hi,

...

The changes to Char.h and WinText.h fix up the output. Since WinHugs last worked the program has moved to using unicode output functions, which were not trapped. This traps them and redirects them towards the WinHugs GUI.

Is that the right place to intercept it, i.e. couldn't we just intercept fputc and fgetc? And (how) does the console work with non Latin-1 encodings?

I debated over this with a friend, and we couldn't find a cleaner place to put the console intercepts. Before unicode happened intercepting fgetc worked. Now, with unicode defined, fgetc_mb is used - which is a defined function, not a library call. Since Wintext.h is imported *before* char.h, its then impossible to redefine fgetc_mb as something else (because the prototype and the declaration both use fgetc_mb, so would be redefined anyway, and defeat the purpose). Because of this the redefine's must occur after char.h is imported - and the cleanest place to ensure this is at the bottom of char.h. I personally think this is the wrong solution entirely - WinHugs should spawn a windows version of the console hugs, and just do stderr and stdout trapping in a separate process. This way winhugs would be entirely different from the hugs runtime, and no redefines (or any interaction between them) would be required. If this happened WinHugs would not have *any* impact on hugs at all, not even any #ifdef's. This isn't the way it was done in the past though, so its probably best to stick with the current mechanism until I have cleaned up WinHugs significantly, then I would like to give increased separation a try. As to how the WinHugs console emulator works with unicode, I have no idea. I wouldn't even like to take a guess. My first task is going to be to simplify, reduce and refactor the WinHugs code. After that, I'll take a look at the console and see if a replacement using Windows Rich Text control would work (which gives Unicode and lots of other nice features for free), or if the console can be extended to unicode (should be relatively easy). Thanks Neil

So should it be enough to just turn off CHAR_ENCODING for WinHugs until you're ready to do Unicode handling properly? Hmm, I don't see how it got turned on: winhugs/options.h doesn't mention it.

It seems to have turned itself off now, I'm not sure how it was ever turned on, but the windows build works now - without any patches. I am very confused as to what happened, but at least it seems happy enough. Thanks Neil