[Simh] A new version...

[Mark Abene]

On the contrary.  I couldn't allow myself to lurk any longer, since the
situation is now bordering on the absurd.  What I meant was that
DEVELOPERS (contributors to and maintainers of the code that makes up
the application at hand, INCLUDING the process by which it is maintained
and built) should be free to suggest and improve any and all aspects of
said application without the impediment of knee-jerk reactions and
counter-productive "it just isn't meant to work" comments from USERS who
apparently have only a scarce appreciation for modern software
development.  It is often beneficial that this development cycle not be
visible to users, and it is for this reason that software projects
commonly have separate -user and -dev mailing lists so that if and when
a developer's improvement reaches a state of maturity, feedback can then
be solicited from users.

Owing to the fact that I've been a software developer for nearly 30
years, I happen to be on your side in this argument.  For as excellent
an application SIMH is, its build environment has stagnated from a "it's
good enough" indifference.  If it isn't obvious enough, the most common
use of SIMH is for those of us who used or remember antiquated hardware
and operating systems to simulate this hardware on MODERN machines which
we use on a daily basis.  Yes, the larger majority of people I've met
run SIMH on some version or another of Unix (that includes linux).
Being that this is the majority, it is not unrealistic to REQUIRE a
modern toolchain in order to build this application.  That holds true
for Unix (which includes OS X and embedded platforms), Windows, and to a
lesser extent, OpenVMS.  I happen to know for fact that GNU make is
available for all three of these platforms.  The build process should be
made "modern", and it's obvious that this is your goal.  Of course this
process should be thoroughly tested to work smoothly on the most
important platforms first, then later you can worry about user
feedback/problem reports from the half-dozen people who might run SIMH
on a platform no one else has.

The fact that you're encountering such fear and uncertainty in trying to
do something which is to me so logically beneficial, is comical.
Perhaps we should all go back to writing programs on graph paper and
submitting stacks of hollerith cards to pencil-necks in white lab coats.
 Then none of this would matter.  :)

I will now return to my lurking.

-Mark

P.S.: I've been running RSTS/E and 2.11BSD on SIMH for years on FreeBSD.
 I've also set it up on various other OS's, including Windows with
cygwin.  I could certainly help test the proposed Makefile, and I speak
"make", so errors like "Missing separator on line 47: Stop." won't send
me screaming from the room.


Philipp Hachtmann wrote:
> Hi Mark,
> 
> Mark Abene wrote:
>> This is why major software projects should have separate -user and -dev
>> mailing lists.  'Nuff said.
> 
> What do you mean with this? Have I done something wrong?
> I *thought* that SIMH is a developer-only project *g*
> 
> Best wishes,
> Philipp
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>>
>>
>> Terry Newton wrote:
>>> --- On Sat, 9/20/08, Toby Thain <toby at telegraphics.com.au> wrote:
>>>>> I see a pattern... complex stuff breaks under Windows.
>>>> What's complex about it? This seems all very
>>>> straightforward...
>>> To a makefile expert... just because I'm not doesn't
>>> make me stupid. If it's straightforward then please
>>> test it, figure out why the errors occur under Windows
>>> and fix them, or make the decision that it'd be for
>>> *nix use only. It may be the same version of make
>>> but obviously there are environmental differences
>>> that cause the more complex contructs to fail, or
>>> there's a problem in the Windows-specific part.
>>>
>>> Other than this I like the new makefile, it works
>>> fine and is much faster under Linux, Philipp did a
>>> good job but doesn't have Windows to test with, so
>>> others need to do that but how can that proceed if
>>> the one reporting bugs (like me) is dismissed.
>>> It's just plain rude to suggest that I don't need
>>> to do it - I'm a Linux user but I need to be able
>>> to generate a modified hp2100.exe binary for my
>>> public projects. But it doesn't matter why I need
>>> it to work, it just needs to work.
>>>
>>> The present SimH archive compiles just fine on
>>> Windows 95 with only 64MB of ram, and my virtual XP
>>> with 192MB can compile 4 copies of simh *at once*.
>>> I know for a fact because I just did both of these
>>> tests to dispell the stupid notion that gobs of
>>> memory is required to compile SimH. Besides I
>>> retested in a real XP install and got exactly the
>>> same results, it has NOTHING to do with my dev
>>> system and to suggest that it does when the
>>> old system works just fine is an excuse.
>>>
>>> The suggestion to use a cygwin shell is helpful,
>>> but unfortunately the cygwin compiler requires
>>> a runtime DLL which is much less desirable than
>>> a standalone exe. I'd much prefer that the way
>>> I've been doing it for years continue to work,
>>> at least for the Windows side. Under Linux the
>>> new makefile is a welcome improvement.
>>>
>>> If the old makefile remains in the archive then
>>> fine, it that case it doesn't matter if the new
>>> one doesn't work under Windows and I can still
>>> do what I need to do.. if the problem in the new
>>> makefile can be fixed then that'd be great. But
>>> since my results don't seem to count and only
>>> result in flames, I'm passing it on to others
>>> (I'm tired:-) once again, out of the makefile
>>> business (just please don't break it...).
>>>
>>> Terry
>>>
>>>
>>>
>>>       _______________________________________________
>>> Simh mailing list
>>> Simh at trailing-edge.com
>>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>> _______________________________________________
>> Simh mailing list
>> Simh at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh