Greetings from another SIMH fork

[promovicz]

Sorry for the issue clutter, but I would like to point out my own fork of SIMH at https://github.com/retroprom/simh/branches.

I do not maintain it very actively, but it contains a reasonably well-working CMake build system (that is missing tests).

Another thing I tried to do was to fix all compiler warnings, but upstream did not want the patches for "cultural reasons".

Should I try to revive those branches and submit them with you?

I might also be interested in better abstractions for external devices resources (serial and network links, disk images, MSCP SAN).

My 2.11BSD project could also use some improvements in simtools, or a more structured successor to it.

See https://github.com/retroprom/ for some of my work.

[promovicz]

One issue that sparks my interest is if SIMH should be modernized to enable better integration into automation, multi-machine setups, generic scripted simulation and other such things that interest retrocomputing hackers today. This is something that I would consider contributing to, and I know others who might join a continuous coordinated effort to such a goal.

Maintaining VMS support with such changes may be a challenge, but there may as well be solutions to this problem.

[pkoning2]

Hi, thanks for the comment. Since this is a discussion about future direction rather than a problem report it might work better in the simh mailing list.
On CMake, interesting -- I just started looking at that and it does feel like a potentially useful direction. I don't know CMake well at all, but I recently noticed that Wireshark uses it extensively, and includes the ability to build on Windows that way. Did you include that in your work? It feels like a better answer than the usual approach of trying to maintain an unrelated and ever-changing set of MSVC build files.

[promovicz]

Thank you for pointing out the mailing list. I will ask my questions there.

Just to answer your question: I did not try building on Windows yet, but I expect it to work more or less right away because it did for me previously. Some things like SDL probably won't work yet, but I am willing to finish this up. Support for Make, Ninja, Visual Studio, Eclipse and some others should be automatic. No source code changes were required.

[Alhadis]

it might work better in the simh mailing list.

Any reason why GitHub discussions aren't considered? If permanence is a requirement (i.e., maintaining an archive of historic discussions), discussions can be forwarded to the mailing list (and new posts to the mailing list could, in theory, be configured to create a "mirrored" discussion on GitHub).

Heck, this functionality may even be implemented already somewhere. I'm sure the need to maintain a mailing list and an active GitHub community isn't an isolated case…)

[wfjm]

Currently we have open-simh/simh and classical simh which is maintained separately. The last classical simh release isn't included in open-simh. The simh mailing list on groups.io is the only common thing as long the relation between open-simh, essentially V4.* and classical simh, that's V3.* isn't resolved.

There are lots of things to address for the open-simh maintainers, and switching from a well established discussion platform, and that is simh@groups.io to a different one is, I'd assume, most likely not the highest priority.

[Alhadis]

Ah, of course. 🤦‍♂️ I didn't even consider that the old SIMH project was still using the mailing list.

Never mind about GitHub discussions then. 👍

[wfjm]

The current transition phase is a bit sensitive, to get all lined up a big task for the new maintainer team.
To have strategy discussions in one place probably helps.
In this spirit a re-post of #6 on simh@groups.io might be helpful.

[Alhadis]

@wfjm Done, and done! Thanks for the advice. 😀

[promovicz]

@wfjm Discussion notwithstanding I've have begun updating my CMake build system to submit in a more up-to-date state.

[LegalizeAdulthood]

@promovicz I am willing to collaborate on the CMake implementation; in particular I can help create a CPack packaging setup to create redistributable packages (e.g. tarballs, Windows Installer MSI packages, whatevs). If you want help with your existing CMake implementation before you issue a pull request here, let me know. I can fork your repo and issue pull requests back to your repo.

For CPack, it's probably best to get your existing stull merged first and then work on that as an additional pull request into this repo.