12 Jan, 2012, arholly wrote in the 1st comment:
Votes: 0
Hi:
I have a question. How much of the system specific stuff in ROM is really necessary anymore? I mean, no one runs MSDOS, as just one example, anymore. But what about the other stuff. Is it even necessary anymore?

Arholly
12 Jan, 2012, Rarva.Riendf wrote in the 2nd comment:
Votes: 0
IMHO, nope. I removed everything and only kept linux and windows/cygwin compatibility. Mostly cause I code in both so I can test it in both easily. I actually do not know if it would run in BSD and dont care that much as most host are either linux or windows anyway.
13 Jan, 2012, David Haley wrote in the 3rd comment:
Votes: 0
Keep in mind that these codebases were meant for distribution to several platforms. As such they require the extra stuff for cross-platform, cross-compiler compatibility. Yes, obviously, that's not relevant to you if you have one platform and one compiler and aren't going to change. At the same time, it doesn't really hurt to leave it, and if you ever do change platforms, you'll be happy.
13 Jan, 2012, arholly wrote in the 4th comment:
Votes: 0
But that goes back to my question, does anyone run DOS anymore? Is the macintosh portions even valid anymore?
13 Jan, 2012, JohnnyStarr wrote in the 5th comment:
Votes: 0
arholly said:
But that goes back to my question, does anyone run DOS anymore? Is the macintosh portions even valid anymore?


Do what makes sense for your OS if you aren't planning on distributing your work for others.
I'm sure there are some enthusiasts out there who run DOS, but I don't think they are planning on
running a MUD on it.

Like David pointed out, it won't do any harm leaving it. If you want to "trim the fat" of ROM then go for it.
13 Jan, 2012, Vigud wrote in the 6th comment:
Votes: 0
I agree with JohnnyStar, and I'm saying this from a perspective of an admin whose mud can work on 15 different operating systems. It's not worth it, unless porting C applications across operating systems is your hobby (as it is in my case).

Now, it is sensible to at least keep in mind that CPU architectures change over decades. It's not unlikely that you'll end up on an ARM version of Linux.
14 Jan, 2012, David Haley wrote in the 7th comment:
Votes: 0
Are the Mac portions valid? Well, that's a good question, isn't it? Is there any possibility whatsoever that you will, at some point, maybe buy a Mac for yourself? If so, then leaving that stuff in will mean you can use your Mac's Unix environment to develop and run your game for testing. If you take it out, you'll have spent effort taking it out, and then not be able to use your code on your Mac. Perhaps your job will give you a Mac laptop and you'll want to develop on it, without having access to ssh into your Linux server.

I agree that it's pretty unlikely that you'll see DOS again. That's not really the bigger point here though.

Good code will be careful to at least sufficiently abstract away platform-dependent functions so that it's easy to make it cross-platform later. It's sort of short-sighted (and it takes effort!) to deliberately remove that abstraction, and you run the risk of breaking things, too.

How much complexity is all of this adding to your codebase? Just a hundred or so lines in thousands upon thousands, perhaps?
14 Jan, 2012, Rarva.Riendf wrote in the 8th comment:
Votes: 0
Why caring…you can run a virtual machine with the os you want to run it.
14 Jan, 2012, Runter wrote in the 9th comment:
Votes: 0
The mac portions are ineffectual except for on ancient macs (perhaps). So remove them or not… no different for you probably. I might try for kicks, but I think it'll compile as well as linux without needing special directives in OSX.

Rarva.Riendf said:
Why caring…you can run a virtual machine with the os you want to run it.


Not OSX.
14 Jan, 2012, plamzi wrote in the 10th comment:
Votes: 0
Runter said:
The mac portions are ineffectual except for on ancient macs (perhaps). So remove them or not… no different for you probably. I might try for kicks, but I think it'll compile as well as linux without needing special directives in OSX.

Rarva.Riendf said:
Why caring…you can run a virtual machine with the os you want to run it.


Not OSX.


My CircleMUD codebase compiled just as easily on OSX as on Linux, and ran without issues. The PowerPC architecture is dead.
14 Jan, 2012, Vigud wrote in the 11th comment:
Votes: 0
David Haley said:
Are the Mac portions valid? Well, that's a good question, isn't it? Is there any possibility whatsoever that you will, at some point, maybe buy a Mac for yourself? If so, then leaving that stuff in will mean you can use your Mac's Unix environment to develop and run your game for testing. If you take it out, you'll have spent effort taking it out, and then not be able to use your code on your Mac. Perhaps your job will give you a Mac laptop and you'll want to develop on it, without having access to ssh into your Linux server.
Quote
It's sort of short-sighted (and it takes effort!) to deliberately remove that abstraction, and you run the risk of breaking things, too.
I bet when he said Macintosh, it really was Macintosh-specific code, and not Mac OS X. My guess is that that code makes the mud single-player for DOS and Macintosh. If I'm right, then removing that code wouldn't be harmful to abstraction, just functionality (perhaps needless functionality).

Quote
Good code will be careful to at least sufficiently abstract away platform-dependent functions so that it's easy to make it cross-platform later.
Sounds right, but it wasn't easy to figure out that on Linux I must define _BSD_SOURCE and _XOPEN_SOURCE 500 - and on FreeBSD/DragonflyBSD I MUSTN'T. And it was unpleasant to see that Solaris 10 forces you to use compiler in C99 mode if you directly or indirectly set _POSIX_C_SOURCE to something modern.

Porting code also takes some work on compiler-specific shit. For example, Pelles C chokes on the ESC character, which you have to replace with '\033'. Intel C compiler defines __attribute__ macro, unless you tell it to not act like gcc (-no-gcc switch). Tiny C Compiler somehow doesn't define linux macro. There's more of that, a lot more.

Having said all of the above, I dare to say this: if you stick to gcc, you won't have too many problems if you ever need to port your code to another platform.
14 Jan, 2012, Rarva.Riendf wrote in the 12th comment:
Votes: 0
What is problematic leaving code that you do not use is that you leave code that you do not test as well. Moreover if you need to modify those part, and cannot test it, you are in the blind when you need to port it over.
A mud is a quite small project and dont need that much specific architecture code, I prefer to have it compiled in straight GCC, so if I actually need to move of platform (and then again there are very few real life situations where you wont be able to use a linux/windows host) I just have to test a few specific functionalities. hell you would be better off coding test unit for those case than to keep code you do not even know if it is still working.
Leaving unecessay code is harmful most of the time, if only for maintenance.
31 Aug, 2012, dracmas wrote in the 13th comment:
Votes: 0
Have a debian linux install on my Evo phone that I use to test scripts on a Rom mud. Not unlikely indeed lol

edit: know this is months off, but it is interesting knowing a mud can be run from a cellphone these days. If I was on windows, I might be tempted to use dos to run a mud to build areas, if it weren't for the fact that I couldn't edit with the source code.
Vigud said:
I agree with JohnnyStar, and I'm saying this from a perspective of an admin whose mud can work on 15 different operating systems. It's not worth it, unless porting C applications across operating systems is your hobby (as it is in my case).

Now, it is sensible to at least keep in mind that CPU architectures change over decades. It's not unlikely that you'll end up on an ARM version of Linux.
31 Aug, 2012, quixadhal wrote in the 14th comment:
Votes: 0
I see no value in keeping legacy code for architectures that are extremely unlikely to ever come into your possession, let alone be something you'd want to USE for development. Yeah, it's nice that FooMUD can compile on a Mac from 1988, or on a VAX/VMS system, but what are the odds that you will want to run it on such a thing?

If it were just a header file or two, no big deal… but usually it's an expanse of cluttered #ifdef's over quite a bit of the code, and things will be cleaner and easier to work with if you remove them.

For a game being built today, I'd probably only put special-case code in for Windows, since the unix variants are close enough that most people can shoehorn them into working by changing a few include files or typecasts.
0.0/14