I learned C by running a MUD — a DikuMUD derivative. I was in high school, in the 90s, and I didn't know any programmers in my town who could teach me how to really code. My high school computer science teacher didn't know.
What I loved about the MUD as a learning environment was the players. On a busy night we'd have over a hundred people playing. So, I got to cut my teeth on a real, live production system with actual users. That motivated me. There were mild consequences if I broke things. And, if I made things better for the players, it felt good.
For me, this environment was so much better than doing programming problem sets by myself, writing code that no one would ever use.
+1 — cut my teeth on learning C in middle school by hacking up a DikuMUD derivative. So many great memories of that period.
And not just C but Linux (Slackware!), sockets, even kludging the single-player DOS port to be two-player by playing over a serial cable to another PC. And annoying my future Dropbox teammates by including an extra space after/before parens in function calls (and if/for/switch statements), putting { on its own line, etc as was the convention in that code base IIRC.
I knew a little C, but I learned about sockets and files (and later databases) and various other things but hacking on DikuMUD, CircleMUD, and SocketMUD, and later writing my own MUDs.
I also learned C this way (with ROM 2.4 in my case), but what I really should have learned is social skills. Instead, once I got good enough at C to make the playerbase my mostly unwilling playthings, all pretense of being anything other than the most insufferable insane dictator in human history went right out the window, and I was so drunk on my own "power" that I was entirely blind to it until it was far, far too late.
Over 100 simultaneous users is quite the success for a MUD back then and especially today. I also learned C by forking DikuMUD too, it was so accessible and easy to tweak.
It was indeed quite the success, but there were a number of MUDs in the 90s and 00s that would hit 100+ regularly. The MUD I mostly played at that time (WoTMUD) was hitting 200+ regularly for awhile.
MUDs are how I began programming, about 30 years ago at the age of 16. Now I'm a senior engineer making mobile games. Unsurprisingly I focus on the backend.
MUDs taught me C, devops, multiplayer/sockets, security to some extent, databases (I wrote my own MUD that used MySQL). Also HTML/webpages eventually. MUDs taught me the full stack.
I began with a MUD too. Though for me it was.. mIRC scripting of all things lol. I knew nothing of programming and spent many, many hours learning patterns through brute force obsession.
I wonder what would have been of my life had i not encountered mIRC.
I think this highlights one of the tenets that I try to advocate for when folks ask me how to get started on some sort of computer science journey. Find a thing that interests you, and work to make that. Whether it's working on a game (from scratch, a mod, whatever), building a hosting platform, writing a little utility to make your life easier, making a website, picking a project that has problems you are motivated to solve does wonders to help you through the initial suck of getting started. And as Jake the Dog says, "sucking at something is the first step to being kinda good at something", so anything that helps offset the suck can be essential.
I started "real" programming with MUDs, and after a hiatus I'm still helping run a C-based MUD, and it's awesome.
Much water has passed under bridges, yet there are dozens of us even creating new ones and doing all sorts of weird things with this great hobby.
The Multi User Dungeon discord is nowadays the place to meet like-minded people who like, or code, or balance, or design, or write or use clients for, MUDs. Join us at https://discord.gg/multi-user-dungeon-279748146316312576
> === How to Learn in the First Place
>
> (1) Play with something.
> (2) Read the documentation on it.
> (3) Play with it some more.
> (4) Read documentation again.
> (5) Play with it some more.
(6) You're starting to learn it! Now fix the documentation
Back in like 1996 I tried to write a MUD using Visual Basic when I had no idea how classes and objects work, but I understood arrays and how to use "Redim Preserve" to change the size of an array while keeping its contents. So any time something needed to make a reference to something else, I stored the index of where that thing was in another array. It made code EXTREMELY ugly.
No data structures, just lots of arrays. Instead of something like "player.health = 100", it was "playerHealth(playerIndex) = 100".
If I wanted to make a player hit a monster, it was like "monsterHealth(playerTarget(playerIndex)) -= playerStrength(playerIndex) + weaponDamage(playerWeapon(playerIndex))"
LPMUD taught more people how to code and more effectively than basically any online educational environment I can think of, and it did it without people even realizing that's what they were learning.
unlike other MUDs it had a built-in ftp server, and ed.
i learned concepts like trampolines and blueprints, which i later learned were closures and classes. and i learned about inheritance and objects. conveniently, objects in an LPmud are real tangible objects like a dragon or a sword.
remember those dumb sounding introductions to OO programming, like class dog, inherits animal? in LPmuds you really have examples like that: class dwarf, inherits NPC, or class sword, inherits weapon.
one of the features that LPmuds needed was the ability to update objects from changed classes/blueprints at runtime without restarting the server so that the wizards could work on the game while others were playing it. it was coding in production, but usually the areas in development were closed of to regular players. but you can imagine how robust LPmuds and LPC had to be to enable that.
then the web came up and i was looking for a better webserver than the ones from NCSA and cern. i discovered spinner. and to my surprise i found that it was written in uLPC, a rewrite of LPC. spinner was renamed to roxen, and uLPC was renamed to pike.
spinner/roxen had modules that were easy to write: class mymod, inherit SomeModuleType, do stuff.
roxen modules were objects that got instantiated each time a http request was made. the http request object would call them in some order and let them do their thing and add data to the response object. i wrote many such modules to customize the behavior of my websites. one morning i woke up and realized what OO programming really meant because i understood how the different objects interacted with each other and encapsulated things. until then i had only been going through the motions because that's how i learned to do things, but i didn't know why.
roxen also was able to reload modules from changed code at runtime. (remember the LPmud ability to reload objects? it's the same feature. in roxen it was a bit weaker because it only applied to new instances, but that was intentional, because unlike LPmuds, in roxen objects were short lived anyways)
fast forward almost a decade and i discover open-sTeam, an object storage server written in pike, using MUD concepts internally. it had rooms and doors/gates to connect them. users logging in had an inventory and could pick up and drop documents like objects in a MUD. it also had object level access control. the developers said they chose pike because it was the only language that allowed them to implement this kind of access control. and here too, like an LPmud open-sTeam has the ability to reload objects with new class code. and unlike roxen it does so for existing objects too.
i am still using open-sTeam to build my websites today, after modernizing it by adding a REST API combined with a modern frontend framework. and i can do live coding while the server is running. for my own websites i do that in production. for client websites i keep a separate dev server. although, since the server is so rich in features i rarely have to do any custom backend coding. most of the work in in the frontends now.
I learned C by writing a MUD client around '87-89. This was for VMS, where the telnet client didn't properly handle newlines and carriage returns, which made telnetting into a mud (tinymud at CMU mainly, then chaos and a few others) painful. I recently dug up the code (it was still online somewhere) and had a laugh.
Interestingly enough, many MUDs don't actually explicitly support the telnet protocol (but some do). It just so happens that a telnet client would generally work, even if it wasn't the most suitable.
My friends group got really good at Unix filesystem permissions at a time when people were having to be cajoled into using email. Someone found a little space to stash programs and we had tcsh and tinyfugue among other things available to us.
Some of my first programming experience was using the language inside of a MUSH (TinyTIM to be specific, based on TinyMUSH but heavily modified). Interactive experiences could be built up using the rudimentary logic afforded.
Found this repository of MUSH code if anyone is curious what it looked like: https://www.mushcode.com/
Modifying Eggdrop (the IRC bot written in C) was another project that contributed to my early understanding.
MOOs have been around forever and are like more-easily programmable MUSHes. Educational institutions loved them back in the day. There's even still development of the MOO server, active social MOOs, websites running MOO as the webserver... lots of fun stuff!
This is how I got started, from a DikuMUD. I had met a couple of other people on Medievia and we decided to give it a go. I knew a tiny bit of C from an old pirated copy of Borland TurboC and just jumped right in.
Great stuff -- I remember my proudest moments were adding color to the various system messages (vanilla Diku at the time didn't do that), and adding online level editing with saving; previously you had to create maps offline.
Never contributed upstream (I was in high school and didn't even understand what that would mean), and eventually kind of drifted away from the community. But I got a ton of experience in just jumping in and working in C.
'vi'
'emacs'
'jove' -- use whatever editor floats your boat
but learn the hell out of it
you should know EVERY command in your editor
Those who picked emacs from that list never got the point of writing any code for the MUD. They greatly contributed to OS development all over the world however.
The first production lines of code I wrote was fixing SO_LINGER on diku so that we could restart the server if someone shut down their computer without disconnecting properly.
Later I wrote a string intern() function for a highly modified MUD that was having memory issues. But they balked at the complexity of having to use a malloc/free replacement even after I made the arena logic dead simple :/
Also the first implementation of a Slab allocator I ever read about, by a wide margin, was in LPMud, which one of my roommates and a friend were into. I wouldn't hear that concept again, unless I brought it up, for a decade or so.
I started playing computer games and accidentally became a programmer. I wasn't even trying to make games, just play them.
Shit, I even tried not to become a programmer, but people kept offering me jobs that paid enough that it was hard to say no. At some point it's like... grad school and some career I want at poverty wages and having to work hard to find employment at all, or stare at glowing screens for the next few decades but just have high-paying jobs thrown at me based on stuff I picked up by accident?
Playing a MUD was the reason I started making websites so my friends could "easily" share equipment stats with each other without needing to scan them in the game.
In terms of "games as an entry into programming": The first-person shooter Starseige:Tribes (1998) had strong scripting support for both server-side gameplay mods and for client-side conveniences.
For example, many gameplay mods allowed players to dynamically place new entities (walls, platforms, turrets), and if your team was too competent and you got bored guarding the flag you put on an a client-side script to play Tetris in a custom HUD.
There were a lot of Pascal based door games (including MUDs) for DOS based BBSes. I wasn't writing software back then, but I gather Borland Turbo Pascal was a nice way to work.
Although a majority of BBS games were indeed written in Pascal, the BBS MUDs tended to be written in C or C++. Most of these were MajorBBS/WorldGroup modules, which (if I recall correctly) only supported C / C++.
For conventional BBS's running standard doorgames, there were only a few true MUDs (mostly on the later / post-dial-up time frame) and it varied a bit more, but I can say DoorMUD was definitely written in C++.
I was never involved in running a multi-line BBS (so, no BBS-based MUDs for me), but I did help with a couple of boards that ran a Turbo Pascal-based single user MUD-like game (called "Cyberspace"). It was TinyMUD-esque. At one point we had 10 - 12 people actively building rooms, adding mobile NPCs, etc. It was loads of fun even though only one person at a time was interacting with the software.
I got my first compiler (Turbo Pascal 2.0!) from a friend's mother who was taking CS classes at the local community college. It ran on her Tandy 1000, I'm not sure what they wrote programs on at her school but she always had stacks of greenbar paper with source code on them.
I remember reading this guide as a Medievia and small-communitt dikumud player in the early 2000s. It was zipped up with a few other guides, including Beej's socket guide iirc.
> GET THIS STRAIGHT: 'VAX' IS NOT AN OPERATING SYSTEM. It's the name of a
family of computers from DEC. There are plenty of Vax'es running VMS, and
there are even more Vax'es running Berkeley Unix or Ultrix. The Vax'es
running Unix have a lot more in common with other machines running
Unix than they have with Vax'es running VMS.
GET THIS STRAIGHT: 'VAX' IS A CPU ARCHITECTURE AS WELL AS THE NAME OF SOME COMPUTERS CREATED BY DEC. The plural of "Vax" is "Vaxen".
Amazing that they wrote this wonderful, detailed rant without mentioning Windows at all. VMS was certainly not the most popular OS or even most popular non-UNIX OS.
I mean, this is 1993 and they did mention DOS. But reading this, you would not know that most of those DOS machines were running Windows and that they were far, far more numerous than either UNIX or VMS. And Windows NT was already released when that was written.
Not that I am a Microsoft apologist. My main machine was OS/2 back then, I was already using Linux, and ( if I had the money ) NeXTstep would have been my dream platform.
Diku and most (all?) other MUDs were "BSD" socket-based. Windows did not even ship with a sockets layer (winsock) until 1994, with Windows NT 3.5, and it made its way to consumers with Windows 95.
Merc did allow for compiling on Mac and MS-DOS, but in this mode reads and writes to the console, without a socket implementation. No multiplayer.
> Windows did not even ship with a sockets layer (winsock) until 1994, with Windows NT 3.5, and it made its way to consumers with Windows 95.
A lot of people used third party Winsock implementations, e.g. Trumpet Winsock, under Windows 3.1. As a 1990s teenager I remember seeing it a lot. Even into the second half of the 1990s, because it wasn’t like all Windows 3.1 machines were upgraded as soon as Windows 95 came out.
> And Windows NT was already released when that was written.
Windows NT 3.1 was released on July 27th; this document was dated August 1st. Basically nobody had a copy yet; even if they did, MERC wouldn't have run on it without substantial porting effort, as it depended on Berkeley sockets.
The first version of NT was released July 27, 1993. This document was published August 1, 1993. What valuable first-hand programming-on-NT information would you liked them to have included about an OS that had been available for 4 days?
> The large majority of folks were still running straight MS-DOS.
My recollection is by 1994, Windows 3.1 was everywhere. My school had literally dozens of computers running it. It was on every PC at my father’s work. We had several computers in our house and they all ran it except the 286 we used to play games (which my dad ended up giving to his brother, since it was a big upgrade to the 8086 he’d been using to run WordStar)
At home we didn’t run Windows 3.1 full-time, we’d exit to DOS to play games. But we’d use Microsoft Word to write assignments for school.
I dual-booted into OS/2 2.0 because I was really into computers. Nobody else in the house knew what to do with it, and I didn’t know anyone else who ran it. After a while OS/2 got replaced by Slackware, and nobody else knew what to do with that either.
My school had mostly MS-DOS 5.0 computers, the UNIX class was taught by bringing a PC tower with Xenix, where the class would take 15 m turns after preparing their samples on MS-DOS with Turbo C 2.0, and it was a model school.
In 1992 I did my typing exam using MS-DOS 3.3, on edlin.
The other school down the block was still using Amstrad PC1512, with CGA and EGA monitors.
Most of us had Ataris and Amigas at home, if families were rich enough, otherwise we had to still make do with our C64 and Spectrum variants.
By the early 1990s most families (in my upper middle class milieu) had PCs. Minority had something else instead-Macs and Amigas most commonly.
9 year old me started using Windows 3.0 in 1991, when it was still quite rare in the home. My dad pirated from his work, which were adopting it. But by 1994 or so I was seeing Windows 3.x everywhere (mostly 3.1 or WfW 3.11 instead of 3.0)
I went to three different primary schools. First one (1987-1991) had Apple IIs; second one (1991-1992) had one computer lab containing IBM PC JXs running DOS (the JX was a derivative of the PCjr only sold in Japan, Australia and NZ), another with Acorns, and classrooms had a mix of Apple IIGS and 8-bit Apple II; third one (1993), our classroom had a C64 and an Acorn, and I know some other classrooms had Macs. Secondary school (1994-1999) was all PCs and Acorns. I think all the PCs ran Windows 3.x (later in 1990s newer machines got Windows 95), and most were in Windows nearly all the time. The exception was the machines in the CAD lab, which probably had Windows installed, but our CAD software only ran under DOS, so Windows was rarely used on them.
Around 1997 or so people were throwing out old 8-bit machines like crazy. I went to the school fair and bought a pile of Apple IIs and C64s for $5 each. Unfortunately my dad made me get rid of them all because he didn’t like the clutter.
Plenty of people ran BBSes on DOS, but there's not much of a reason to run a BBS on Windows 3. Windows 3 doesn't give you anything that a DOS based BBS hadn't already figured out. At best, you might run your DOS BBS inside a command prompt in Windows.
Windows 3.1 provided no services which would have been relevant to MUD development. It didn't even have a networking stack - Trumpet Winsock was a third-party addon, and wasn't compatible with Berkeley sockets.
> reading this, you would not know that most of those DOS machines were running Windows and that they were far, far more numerous
Why not include the microcontroller in microwaves, too? Because those aren't real computers.
(All in good fun! I don't endorse such an opinion, but it would have been common among both VMS and Unix users at the time. After all those PC OSes don't even have networking or preemptive multitasking.)
you see the email addresses in the document? in 1993, not many Microsoft Windows users had email addresses. It was prehistoric times for them, and their histories were not saved. Nobody knew what the Who's down in Whoville were doing.
Lots of windows users were on the Internet or otherwise online, but the form it would take was pulling up ProComm and dialing into an isp, fidonet bbs, compuserve, etc.
You didn't need to have a local TCP stack running to use email, ftp, etc. You'd just have a shell account somewhere and/or use dedicated dialup tools
For quite a while after Windows already became popular, any program that did networking on IBM PCs still had to be an MS-DOS program.
In 1993, (regular, consumer) Windows didn't really "support" networking; (limited) OS support for networking was something only available in Windows For Workgroups, which itself was something you'd only expect to find installed in offices, not on the kind of home PC owned by someone dialing into a MUD.
I believe that you could run these networked programs in a Windows 3.1 OS DOS virtual machine, so you didn't have to reboot fully into DOS just to run them.
But it makes sense, from the perspective of an author of networked software at the time, to think of IBM PCs as being "MS DOS machines." That's the abstraction the developer had to work against for that port of the software.
Windows programming was not very accessible in 1993, and it was especially not very accessible for network programming. Making a Win16 application that was non-trivial and didn't crash spectacularly was wizardry.
Network PC games of this era were written using DOS extenders and IPX networking.
While VB3 applications wouldn't crash, they were pretty limited and didn't look and feel like full Win16 applications. The requirement for vbrun300.dll was a sign that something was not going to be good.
In 1993, there weren't many third-party controls. Any networking was accomplished through FFI.
32-bit C programming on wintel systems in that era would have looked like using DOS extender/DPMI and would have been lumped under "MS-DOS" even if you were assuming the user was running Windows. (Even if your IDE was a Windows GUI program)
MUDs are played over network or on a multiuser mainframe, in realtime. DOS (and windows) machines back then were single user and networks for them were rare, specialized and/or asynchronous, like BBS.
hah, when my grandmother wished to get a computer (she was a volunteer secretary in a few organizations doing a lot of typing on a mechanical typewriter until then) grandpa sent me out to get it, and i chose some decent machine for the time and put OS/2 on it (and LaTeX). meanwhile i had linux on my own machine, and when the opportunity arose i used my student status to buy a discounted copy of OpenStep for the PC. a few years later i got my hands on a NeXT cube and a few slabs from a university auctioning off old equipment ;-)
I learned C by running a MUD — a DikuMUD derivative. I was in high school, in the 90s, and I didn't know any programmers in my town who could teach me how to really code. My high school computer science teacher didn't know.
What I loved about the MUD as a learning environment was the players. On a busy night we'd have over a hundred people playing. So, I got to cut my teeth on a real, live production system with actual users. That motivated me. There were mild consequences if I broke things. And, if I made things better for the players, it felt good.
For me, this environment was so much better than doing programming problem sets by myself, writing code that no one would ever use.
https://tashian.com/articles/how-i-learned-to-program/
+1 — cut my teeth on learning C in middle school by hacking up a DikuMUD derivative. So many great memories of that period.
And not just C but Linux (Slackware!), sockets, even kludging the single-player DOS port to be two-player by playing over a serial cable to another PC. And annoying my future Dropbox teammates by including an extra space after/before parens in function calls (and if/for/switch statements), putting { on its own line, etc as was the convention in that code base IIRC.
Ditto... loved me those old DikuMUD variants. Cut my own teeth on Shadows of Isildur!
I was in highschool in the 2000's and learned C# working with the RunUO emulator for Ultima Online which MUDs were the predecessor for.
I always thought a programming class with assignments to add spells/new weapons/quests/etc on a shared class server would be great.
I also learned C by running a MUD, and I'm amazed how many people shared that experience with us LOL.
I knew a little C, but I learned about sockets and files (and later databases) and various other things but hacking on DikuMUD, CircleMUD, and SocketMUD, and later writing my own MUDs.
I also learned C this way (with ROM 2.4 in my case), but what I really should have learned is social skills. Instead, once I got good enough at C to make the playerbase my mostly unwilling playthings, all pretense of being anything other than the most insufferable insane dictator in human history went right out the window, and I was so drunk on my own "power" that I was entirely blind to it until it was far, far too late.
Over 100 simultaneous users is quite the success for a MUD back then and especially today. I also learned C by forking DikuMUD too, it was so accessible and easy to tweak.
It was indeed quite the success, but there were a number of MUDs in the 90s and 00s that would hit 100+ regularly. The MUD I mostly played at that time (WoTMUD) was hitting 200+ regularly for awhile.
MUDs are how I began programming, about 30 years ago at the age of 16. Now I'm a senior engineer making mobile games. Unsurprisingly I focus on the backend.
MUDs taught me C, devops, multiplayer/sockets, security to some extent, databases (I wrote my own MUD that used MySQL). Also HTML/webpages eventually. MUDs taught me the full stack.
I began with a MUD too. Though for me it was.. mIRC scripting of all things lol. I knew nothing of programming and spent many, many hours learning patterns through brute force obsession.
I wonder what would have been of my life had i not encountered mIRC.
Similar story here! They are great platforms to create and explore with. Built up CircleMUD 1995-1999 here.
The good old days when you could just hook up some hacked up C code to the internet and pray you caught all the potential exploits.
I think this highlights one of the tenets that I try to advocate for when folks ask me how to get started on some sort of computer science journey. Find a thing that interests you, and work to make that. Whether it's working on a game (from scratch, a mod, whatever), building a hosting platform, writing a little utility to make your life easier, making a website, picking a project that has problems you are motivated to solve does wonders to help you through the initial suck of getting started. And as Jake the Dog says, "sucking at something is the first step to being kinda good at something", so anything that helps offset the suck can be essential.
I wrote thousands of lines of spaghetti Python code this way.
Finally, doing things the right way no longer seems like overthinking but instead a massive timesaver longterm.
I started "real" programming with MUDs, and after a hiatus I'm still helping run a C-based MUD, and it's awesome.
Much water has passed under bridges, yet there are dozens of us even creating new ones and doing all sorts of weird things with this great hobby.
The Multi User Dungeon discord is nowadays the place to meet like-minded people who like, or code, or balance, or design, or write or use clients for, MUDs. Join us at https://discord.gg/multi-user-dungeon-279748146316312576
IAC WILL MUD
Back in like 1996 I tried to write a MUD using Visual Basic when I had no idea how classes and objects work, but I understood arrays and how to use "Redim Preserve" to change the size of an array while keeping its contents. So any time something needed to make a reference to something else, I stored the index of where that thing was in another array. It made code EXTREMELY ugly.
No data structures, just lots of arrays. Instead of something like "player.health = 100", it was "playerHealth(playerIndex) = 100".
If I wanted to make a player hit a monster, it was like "monsterHealth(playerTarget(playerIndex)) -= playerStrength(playerIndex) + weaponDamage(playerWeapon(playerIndex))"
Awful and unmaintainable.
A lot of production VB apps were written the same way. Array was the only data structure.
LPMUD taught more people how to code and more effectively than basically any online educational environment I can think of, and it did it without people even realizing that's what they were learning.
i also learned LPC in an LPmud.
unlike other MUDs it had a built-in ftp server, and ed. i learned concepts like trampolines and blueprints, which i later learned were closures and classes. and i learned about inheritance and objects. conveniently, objects in an LPmud are real tangible objects like a dragon or a sword.
remember those dumb sounding introductions to OO programming, like class dog, inherits animal? in LPmuds you really have examples like that: class dwarf, inherits NPC, or class sword, inherits weapon.
one of the features that LPmuds needed was the ability to update objects from changed classes/blueprints at runtime without restarting the server so that the wizards could work on the game while others were playing it. it was coding in production, but usually the areas in development were closed of to regular players. but you can imagine how robust LPmuds and LPC had to be to enable that.
then the web came up and i was looking for a better webserver than the ones from NCSA and cern. i discovered spinner. and to my surprise i found that it was written in uLPC, a rewrite of LPC. spinner was renamed to roxen, and uLPC was renamed to pike.
spinner/roxen had modules that were easy to write: class mymod, inherit SomeModuleType, do stuff.
roxen modules were objects that got instantiated each time a http request was made. the http request object would call them in some order and let them do their thing and add data to the response object. i wrote many such modules to customize the behavior of my websites. one morning i woke up and realized what OO programming really meant because i understood how the different objects interacted with each other and encapsulated things. until then i had only been going through the motions because that's how i learned to do things, but i didn't know why.
roxen also was able to reload modules from changed code at runtime. (remember the LPmud ability to reload objects? it's the same feature. in roxen it was a bit weaker because it only applied to new instances, but that was intentional, because unlike LPmuds, in roxen objects were short lived anyways)
fast forward almost a decade and i discover open-sTeam, an object storage server written in pike, using MUD concepts internally. it had rooms and doors/gates to connect them. users logging in had an inventory and could pick up and drop documents like objects in a MUD. it also had object level access control. the developers said they chose pike because it was the only language that allowed them to implement this kind of access control. and here too, like an LPmud open-sTeam has the ability to reload objects with new class code. and unlike roxen it does so for existing objects too.
i am still using open-sTeam to build my websites today, after modernizing it by adding a REST API combined with a modern frontend framework. and i can do live coding while the server is running. for my own websites i do that in production. for client websites i keep a separate dev server. although, since the server is so rich in features i rarely have to do any custom backend coding. most of the work in in the frontends now.
I learned C by writing a MUD client around '87-89. This was for VMS, where the telnet client didn't properly handle newlines and carriage returns, which made telnetting into a mud (tinymud at CMU mainly, then chaos and a few others) painful. I recently dug up the code (it was still online somewhere) and had a laugh.
Interestingly enough, many MUDs don't actually explicitly support the telnet protocol (but some do). It just so happens that a telnet client would generally work, even if it wasn't the most suitable.
My friends group got really good at Unix filesystem permissions at a time when people were having to be cajoled into using email. Someone found a little space to stash programs and we had tcsh and tinyfugue among other things available to us.
Some of my first programming experience was using the language inside of a MUSH (TinyTIM to be specific, based on TinyMUSH but heavily modified). Interactive experiences could be built up using the rudimentary logic afforded.
Found this repository of MUSH code if anyone is curious what it looked like: https://www.mushcode.com/
Modifying Eggdrop (the IRC bot written in C) was another project that contributed to my early understanding.
tim.org is still online. Originally started by Jason Scott of textfiles.com and now at archive.org.
I'm convinced the Slack-killer is going to be a user programmable MUSH.
MOOs have been around forever and are like more-easily programmable MUSHes. Educational institutions loved them back in the day. There's even still development of the MOO server, active social MOOs, websites running MOO as the webserver... lots of fun stuff!
If there's any interest:
Archived MOO knowledge: https://lisdude.com/moo/ Modern MOO server: https://github.com/lisdude/toaststunt/ Active social MOO: https://chatmud.com/
That's what Slack kind of started out as right? (it was a multiplayer game)
This is how I got started, from a DikuMUD. I had met a couple of other people on Medievia and we decided to give it a go. I knew a tiny bit of C from an old pirated copy of Borland TurboC and just jumped right in.
Great stuff -- I remember my proudest moments were adding color to the various system messages (vanilla Diku at the time didn't do that), and adding online level editing with saving; previously you had to create maps offline.
Never contributed upstream (I was in high school and didn't even understand what that would mean), and eventually kind of drifted away from the community. But I got a ton of experience in just jumping in and working in C.
'vi' 'emacs' 'jove' -- use whatever editor floats your boat but learn the hell out of it you should know EVERY command in your editor
Those who picked emacs from that list never got the point of writing any code for the MUD. They greatly contributed to OS development all over the world however.
The first production lines of code I wrote was fixing SO_LINGER on diku so that we could restart the server if someone shut down their computer without disconnecting properly.
Later I wrote a string intern() function for a highly modified MUD that was having memory issues. But they balked at the complexity of having to use a malloc/free replacement even after I made the arena logic dead simple :/
Also the first implementation of a Slab allocator I ever read about, by a wide margin, was in LPMud, which one of my roommates and a friend were into. I wouldn't hear that concept again, unless I brought it up, for a decade or so.
I've played a MUD and accidentally learned Perl once.
I started playing computer games and accidentally became a programmer. I wasn't even trying to make games, just play them.
Shit, I even tried not to become a programmer, but people kept offering me jobs that paid enough that it was hard to say no. At some point it's like... grad school and some career I want at poverty wages and having to work hard to find employment at all, or stare at glowing screens for the next few decades but just have high-paying jobs thrown at me based on stuff I picked up by accident?
Playing a MUD was the reason I started making websites so my friends could "easily" share equipment stats with each other without needing to scan them in the game.
In terms of "games as an entry into programming": The first-person shooter Starseige:Tribes (1998) had strong scripting support for both server-side gameplay mods and for client-side conveniences.
For example, many gameplay mods allowed players to dynamically place new entities (walls, platforms, turrets), and if your team was too competent and you got bored guarding the flag you put on an a client-side script to play Tetris in a custom HUD.
Really curious about this:
> If you have access to a program named 'Purify' ... learn how to use it.
Anyone know what this was or use it?
It's a memory debugger, in the same class of things as Valgrind: https://en.wikipedia.org/wiki/PurifyPlus
Fun fact: it was written by the cofounder and chairman of Netflix.
Quick google suggests it was https://pages.cs.wisc.edu/~hasti/cs368/CppTutorial/NOTES/PUR...
It's kind of like Valgrind and was (is? I'm not sure.) used for finding memory leaks.
When I started into UNIX, the MUDs we were running were based in Pascal actually, surprisingly in a C ecosystem.
There were a lot of Pascal based door games (including MUDs) for DOS based BBSes. I wasn't writing software back then, but I gather Borland Turbo Pascal was a nice way to work.
Although a majority of BBS games were indeed written in Pascal, the BBS MUDs tended to be written in C or C++. Most of these were MajorBBS/WorldGroup modules, which (if I recall correctly) only supported C / C++.
For conventional BBS's running standard doorgames, there were only a few true MUDs (mostly on the later / post-dial-up time frame) and it varied a bit more, but I can say DoorMUD was definitely written in C++.
I was never involved in running a multi-line BBS (so, no BBS-based MUDs for me), but I did help with a couple of boards that ran a Turbo Pascal-based single user MUD-like game (called "Cyberspace"). It was TinyMUD-esque. At one point we had 10 - 12 people actively building rooms, adding mobile NPCs, etc. It was loads of fun even though only one person at a time was interacting with the software.
Unfortunately they never did UNIX, the Pascal compilers for UNIX were rather lame, mostly ISO without much extensions.
Probably P2C was the best, followed by gpc years later, and finally FreePascal came to be.
Pascal was the typical learning language at most schools before Java caught on.
before Java was invented
I got my first compiler (Turbo Pascal 2.0!) from a friend's mother who was taking CS classes at the local community college. It ran on her Tandy 1000, I'm not sure what they wrote programs on at her school but she always had stacks of greenbar paper with source code on them.
I remember reading this guide as a Medievia and small-communitt dikumud player in the early 2000s. It was zipped up with a few other guides, including Beej's socket guide iirc.
> GET THIS STRAIGHT: 'VAX' IS NOT AN OPERATING SYSTEM. It's the name of a family of computers from DEC. There are plenty of Vax'es running VMS, and there are even more Vax'es running Berkeley Unix or Ultrix. The Vax'es running Unix have a lot more in common with other machines running Unix than they have with Vax'es running VMS.
GET THIS STRAIGHT: 'VAX' IS A CPU ARCHITECTURE AS WELL AS THE NAME OF SOME COMPUTERS CREATED BY DEC. The plural of "Vax" is "Vaxen".
(https://en.wiktionary.org/wiki/VAXen
Alongside the Unix boxen.
http://catb.org/jargon/html/B/boxen.html
Related: I wrote a MUD engine and worldbuilder when I decided I wanted to learn Node.
Okay, I'll ask - what's a MUD?
Multi user dungeon...text based mmorpg usually played through telnet or a specialized application
Thanks
Amazing that they wrote this wonderful, detailed rant without mentioning Windows at all. VMS was certainly not the most popular OS or even most popular non-UNIX OS.
I mean, this is 1993 and they did mention DOS. But reading this, you would not know that most of those DOS machines were running Windows and that they were far, far more numerous than either UNIX or VMS. And Windows NT was already released when that was written.
Not that I am a Microsoft apologist. My main machine was OS/2 back then, I was already using Linux, and ( if I had the money ) NeXTstep would have been my dream platform.
Diku and most (all?) other MUDs were "BSD" socket-based. Windows did not even ship with a sockets layer (winsock) until 1994, with Windows NT 3.5, and it made its way to consumers with Windows 95.
Merc did allow for compiling on Mac and MS-DOS, but in this mode reads and writes to the console, without a socket implementation. No multiplayer.
See: https://github.com/alexmchale/merc-mud/blob/master/src/comm....
> Windows did not even ship with a sockets layer (winsock) until 1994, with Windows NT 3.5, and it made its way to consumers with Windows 95.
A lot of people used third party Winsock implementations, e.g. Trumpet Winsock, under Windows 3.1. As a 1990s teenager I remember seeing it a lot. Even into the second half of the 1990s, because it wasn’t like all Windows 3.1 machines were upgraded as soon as Windows 95 came out.
> And Windows NT was already released when that was written.
Windows NT 3.1 was released on July 27th; this document was dated August 1st. Basically nobody had a copy yet; even if they did, MERC wouldn't have run on it without substantial porting effort, as it depended on Berkeley sockets.
The first version of NT was released July 27, 1993. This document was published August 1, 1993. What valuable first-hand programming-on-NT information would you liked them to have included about an OS that had been available for 4 days?
Well Windows existed before NT didn't it? Don't know how much people cared for it though at that point
Windows 3.0 was the first that really mattered, and you needed at least an expensive 386SX to run it.
A 286 could do it as well, but then you wouldn't be able to use the new enhanced mode.
The large majority of folks were still running straight MS-DOS.
Also the games industry only adopted Windows after Windows 95, very few titles cared about WinG on Windows 3.1 / 3.11 / Win32s.
> The large majority of folks were still running straight MS-DOS.
My recollection is by 1994, Windows 3.1 was everywhere. My school had literally dozens of computers running it. It was on every PC at my father’s work. We had several computers in our house and they all ran it except the 286 we used to play games (which my dad ended up giving to his brother, since it was a big upgrade to the 8086 he’d been using to run WordStar)
At home we didn’t run Windows 3.1 full-time, we’d exit to DOS to play games. But we’d use Microsoft Word to write assignments for school.
I dual-booted into OS/2 2.0 because I was really into computers. Nobody else in the house knew what to do with it, and I didn’t know anyone else who ran it. After a while OS/2 got replaced by Slackware, and nobody else knew what to do with that either.
I imagine, US economy.
My school had mostly MS-DOS 5.0 computers, the UNIX class was taught by bringing a PC tower with Xenix, where the class would take 15 m turns after preparing their samples on MS-DOS with Turbo C 2.0, and it was a model school.
In 1992 I did my typing exam using MS-DOS 3.3, on edlin.
The other school down the block was still using Amstrad PC1512, with CGA and EGA monitors.
Most of us had Ataris and Amigas at home, if families were rich enough, otherwise we had to still make do with our C64 and Spectrum variants.
By the early 1990s most families (in my upper middle class milieu) had PCs. Minority had something else instead-Macs and Amigas most commonly.
9 year old me started using Windows 3.0 in 1991, when it was still quite rare in the home. My dad pirated from his work, which were adopting it. But by 1994 or so I was seeing Windows 3.x everywhere (mostly 3.1 or WfW 3.11 instead of 3.0)
I went to three different primary schools. First one (1987-1991) had Apple IIs; second one (1991-1992) had one computer lab containing IBM PC JXs running DOS (the JX was a derivative of the PCjr only sold in Japan, Australia and NZ), another with Acorns, and classrooms had a mix of Apple IIGS and 8-bit Apple II; third one (1993), our classroom had a C64 and an Acorn, and I know some other classrooms had Macs. Secondary school (1994-1999) was all PCs and Acorns. I think all the PCs ran Windows 3.x (later in 1990s newer machines got Windows 95), and most were in Windows nearly all the time. The exception was the machines in the CAD lab, which probably had Windows installed, but our CAD software only ran under DOS, so Windows was rarely used on them.
Around 1997 or so people were throwing out old 8-bit machines like crazy. I went to the school fair and bought a pile of Apple IIs and C64s for $5 each. Unfortunately my dad made me get rid of them all because he didn’t like the clutter.
Not US, Australia
Ok, comment edited with how my bubble looked like.
Plenty of people ran BBSes on DOS, but there's not much of a reason to run a BBS on Windows 3. Windows 3 doesn't give you anything that a DOS based BBS hadn't already figured out. At best, you might run your DOS BBS inside a command prompt in Windows.
Windows 3.1 provided no services which would have been relevant to MUD development. It didn't even have a networking stack - Trumpet Winsock was a third-party addon, and wasn't compatible with Berkeley sockets.
> reading this, you would not know that most of those DOS machines were running Windows and that they were far, far more numerous
Why not include the microcontroller in microwaves, too? Because those aren't real computers.
(All in good fun! I don't endorse such an opinion, but it would have been common among both VMS and Unix users at the time. After all those PC OSes don't even have networking or preemptive multitasking.)
you see the email addresses in the document? in 1993, not many Microsoft Windows users had email addresses. It was prehistoric times for them, and their histories were not saved. Nobody knew what the Who's down in Whoville were doing.
Lots of windows users were on the Internet or otherwise online, but the form it would take was pulling up ProComm and dialing into an isp, fidonet bbs, compuserve, etc.
You didn't need to have a local TCP stack running to use email, ftp, etc. You'd just have a shell account somewhere and/or use dedicated dialup tools
For quite a while after Windows already became popular, any program that did networking on IBM PCs still had to be an MS-DOS program.
In 1993, (regular, consumer) Windows didn't really "support" networking; (limited) OS support for networking was something only available in Windows For Workgroups, which itself was something you'd only expect to find installed in offices, not on the kind of home PC owned by someone dialing into a MUD.
I believe that you could run these networked programs in a Windows 3.1 OS DOS virtual machine, so you didn't have to reboot fully into DOS just to run them.
But it makes sense, from the perspective of an author of networked software at the time, to think of IBM PCs as being "MS DOS machines." That's the abstraction the developer had to work against for that port of the software.
Windows programming was not very accessible in 1993, and it was especially not very accessible for network programming. Making a Win16 application that was non-trivial and didn't crash spectacularly was wizardry.
Network PC games of this era were written using DOS extenders and IPX networking.
what about Visual Basic?
While VB3 applications wouldn't crash, they were pretty limited and didn't look and feel like full Win16 applications. The requirement for vbrun300.dll was a sign that something was not going to be good.
In 1993, there weren't many third-party controls. Any networking was accomplished through FFI.
32-bit C programming on wintel systems in that era would have looked like using DOS extender/DPMI and would have been lumped under "MS-DOS" even if you were assuming the user was running Windows. (Even if your IDE was a Windows GUI program)
I tried running a server on regular Windows back then, it was too unreliable, constant hanging requiring reboot.
Later I tried Windows NT for a server and it was on such a different level, no comparison. It worked like real operating systems should.
NT4 released in '96. SP4 a couple years later made it really stable.
MUDs are played over network or on a multiuser mainframe, in realtime. DOS (and windows) machines back then were single user and networks for them were rare, specialized and/or asynchronous, like BBS.
hah, when my grandmother wished to get a computer (she was a volunteer secretary in a few organizations doing a lot of typing on a mechanical typewriter until then) grandpa sent me out to get it, and i chose some decent machine for the time and put OS/2 on it (and LaTeX). meanwhile i had linux on my own machine, and when the opportunity arose i used my student status to buy a discounted copy of OpenStep for the PC. a few years later i got my hands on a NeXT cube and a few slabs from a university auctioning off old equipment ;-)
In 1993, not really.
Not everyone was into Windows 3.x.