[Yes I don't expect anyone will read this. I'm leaving it for the record.] No surprise that compiling WinHugs wasn't plain sailing. What's more remarkable is that it did eventually compile (with Microsoft Visual C/C++ under Visual Studio); and that most of the difficulties in getting a working system were with the Unix side, compiling Libraries. (If you want a working system quickly and aren't interested in changing the libraries/packages, I suggest stealing the packages from a WinHugs object distro.) Most of the Unix difficulties/needed changes have been worked through by Franklin Chen, to whom much thanks. See his repo https://github.com/FranklinChen/hugs98-plus-Sep2006 He compiled on Mac, so this is to record difficulties specific to Windows/WinHugs. Firstly, though, there's stuff that must have been just plain wrong in 2006. That's why I'm filing as a bug. The instructions in /docs/building/win32.txt for 'Driving Microsoft Visual C++ from the Command Line (out-of-date)' are not just out of date but downright wrong. Perhaps this was still possible immediately after moving to MSVC, but by Sep 2006 the Makefile was unusable: it refers to all sorts of components that no longer exist/at a guess disappeared after early 2005. However there's one bit that's needed but not mentioned in the MSVC instructions: the three .h files in /src/winhugs and (different files same names) in /src/msc: must be copied in to the parent /src/ directory, and the ones in /src/ (created by ./configure) must first be moved aside. Indeed if you're modifying (Win)Hugs shared artefacts (like parser.y) and recompiling both WinHugs and command-line hugs/runhugs/ffihugs; moving those .h files about is a pain. The `make` does do one useful thing: compile echodate.c and run it to create echodate.h. That's #include'd in /src/version.c to version-stamp your .exe's -- except on Windows the compile demands the #include then ignores it. I'll come back to that. For Windows, the instructions i Win32.txt say " Open the project files located in msc (for the plain interpreter) and winhugs (for the GUI interface). ". That'll lead you wrong. Open the .sln file: Visual Studio will then tell you you have an out-of-date project structure; and will then take a long time upgrading the whole thing to current level. (Comes up to VS 2019 ok -- eventually.) Whereas opening the 'project file' -- i.e. the .vcproj will also tell you you have an out-of-date project structure; then take a much shorter time allegedly upgrading but actually stamping all over the place leaving an unusable mess. (Restore the whole directory from repo and start again; there's no hope of repairing it.) Attempting to build from VS will fail to find echodate.h (see above). Don't stuff about trying to build that, just comment out the #include in /src/version.c -- in fact while you're at it, edit that to take a version of May 2020 rather than Sep 2006. There's a few other bits of .c code that won't compile; including in filecode.cpp an out-of-scope use of a for-loop variable that's not compliant with the 1999 C standard. There are a lot -- I mean a really big lot -- of Microsoft warnings about deprecated functions. I started to investigate these, but got overwhelmed; and eventually concluded this is Microsoft being paranoid about functions that are standard C but Ms don't like -- because they never really believed in a public-standards-based language anyway. You can put #pragmas if you want to suppress the warnings; but don't change the code to comply, because then the build on Unix will fall in a heap wanting non-existent functions. And ... I now have WinHugs built from source by Visual Studio. Indeed I'm modifying `parser.y` and recompiling (needs a Unix bison step) happily. Then all credit to the original Win/Hugs development team in producing robust software. I have to say a 14-year-old system is still more friendly and Windowsy to use than anything from that Glasgow lot. AntC