<div dir="ltr">[Yes I don't expect anyone will read this. I'm leaving it for the record.]<div><br></div><div>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.</div><div><br></div><div>(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.)</div><div><br></div><div>Most of the Unix difficulties/needed changes have been worked through by Franklin Chen, to whom much thanks. See his repo <a href="https://github.com/FranklinChen/hugs98-plus-Sep2006">https://github.com/FranklinChen/hugs98-plus-Sep2006</a></div><div><br></div><div>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.</div><div><br></div><div>The instructions in /docs/building/win32.txt for '<span style="color:rgb(36,41,46);font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,monospace;font-size:12px;white-space:pre">Driving Microsoft Visual C++ from the Command Line (out-of-date)</span>' 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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>For Windows, the instructions i Win32.txt say "</div><table class="gmail-highlight gmail-tab-size gmail-js-file-line-container" style="color:rgb(36,41,46);font-size:14px"><tbody style="box-sizing:border-box"><tr style="box-sizing:border-box"><td id="gmail-LC100" class="gmail-blob-code gmail-blob-code-inner gmail-js-file-line" style="box-sizing:border-box;padding-right:10px;padding-left:10px;line-height:20px;vertical-align:top;overflow:visible;font-size:12px;white-space:pre"><font face="garamond, times new roman, serif">Open the project files located in msc (for the plain interpreter) </font></td></tr><tr style="box-sizing:border-box"><td id="gmail-L101" class="gmail-blob-num gmail-js-line-number" style="box-sizing:border-box;padding-right:10px;padding-left:10px;width:50px;min-width:50px;font-size:12px;line-height:20px;color:rgba(27,31,35,0.3);text-align:right;white-space:nowrap;vertical-align:top"></td><td id="gmail-LC101" class="gmail-blob-code gmail-blob-code-inner gmail-js-file-line" style="box-sizing:border-box;padding-right:10px;padding-left:10px;line-height:20px;vertical-align:top;overflow:visible;font-size:12px;white-space:pre"><font face="garamond, times new roman, serif">and winhugs (for the GUI interface). </font></td></tr></tbody></table><div>". That'll lead you wrong.</div><div><br></div><div>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.)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>AntC</div></div>