While stumbling around, I found Open Quartz, which is to Quake as FreeDooM is to DooM, or for those who don’t know it is free assets allowing a fully redistributed game. Although the bundled levels are actually kind of reminiscent of Q3 Arena, one of the great abilities of Quake 1 was inline total game conversions like Team Fortress. Yes it started as a Quake mod.
So I downloaded the Open Quartz binary pak’s and went to do a quick comparison of the two:
I should do an update for QWDOS to allow multiple clients at once for OS’s that’ll support multitasking (Windows) where you can bind the client to different ports to allow more than one to work at a time. The line is:
Although I guess the next best thing is to change the NET_Init code to start with the default port as a base, and if it can’t bind to it, then just increment until you get a winner.
And yes, that is the Quake World for MS-DOS port running on Windows. I built it with Visual C++ 5.0, although using a newer linker that I pulled from masm32.com, which would work with the newer libs, well all except the ogg vorbis stuff, so I just disabled it, as I just wanted to test, and didn’t care too much about music.
So I guess the next thing to do is bundle it all together into something more convenient to the end user.
I had a single issue with the code, d_copy.s the following line was giving me trouble:
changing it to the following however, let my version of GAS happily assemble it.
After a while of messing with the Makefile, and adding in the DOS components, it was easy enough to get an executable. And even better it’ll run with the data/music from the demo disc!
I used Daemon tools to mount the MDS/MDF image, and just pointed DOSBox to the CD drive letter with a simple:
mount d: f:\ -t cdrom
And now when I fired up Quake, it’ll play the music tracks from the CD.
One thing that caught my interest was that when you exit the game, I get the “couldn’t load endscreen.” message.
Well it turns out that someone was naughty and had modified common.c on January 20th 1997, and made the following addition:
if (h == -1)
Con_Printf ("Playing shareware version.\n");
// if (com_modified)
// Sys_Error ("You must have the registered version to use modified games");
So yeah, since they had double commented out that return statement, it’ll fall out the logic, and set the game to registered, which is why the endscreen message is missing. Uncommenting them all will restore the default execution behavior. Speaking of registered, on the CD there is a file QUAKE.MJ3, which is 25MB, which looks like an encrypted version of the registered game. I guess it’d be ‘neat’ to have version 1.01, although the Steam version I have is 1.06 and I don’t know how much difference it’d really make. Although I guess 22 years later it doesn’t matter much.
On the one hand I’m really impressed that it works. For anyone who is slightly interested I guess, you can find my re-build of the source here:
There’s a reason I didn’t have anything to link for (a). That’s because to the best of my knowledge and research, no version has survived these past decades.
As for (b), it seems only the linked version 3.99 from the year 2003 was saved.
The CVS repository and thus commit history has been lost.
If anyone has either actual code for the old Perl Q or the CVS repo for the old
Q written in C, please reach out to me via `xorhash ++at++ protonmail.com’.
I’m most interested in looking through it.
However, not all hope was lost with the old Perl Q. As it turns out, most likely, the old Perl Q was actually based on an off-the-shelf product called “CServe”. What makes me think so?
Let’s take a look at [the QuakeNet Q command listing from 1998.
I picked the command “WHOIS” and googled its use “Will calculate a nick!user@host mask for you from the whois information of this nick.” This lead me to a help file for StarLink IRC. At the top, it reads:
CStar3.x User Command Help File **** 09/10/99
Information extracted from CServe Channel Service
Version 2.0 and up Copyright (c)1997 by Michael Dabrowski
Help Text (c)1997 (c)1997 StarLink-IRC (with permission)
Wait a second, “CServe Channel Service”? I know that from somewhere.
So the commands between that help file and the QuakeNet Q command listing match up and so does Q’s host today. Most likely, I’m on the right track with this. What’s left is to track down a copy of CServe.
Note: I’ve been on the old Perl Q for a while and this strategy didn’t use to work. It seems Google newly indexed these pages. For once I can sincerely say: Thank you, Google.
The only surviving versions are 3.0 and 5.1. CServe got renamed to “CS” starting with 5.0 and was rewritten in C by someone other than the original CServe author, going by the comments in the file header of CS5.1 `src/show_access.c’. CS was actually sold as a commercial product. I wonder how many people bought it.
QuakeNet most likely took a version between 2.0 and 4.0, inclusive, as the basis for the old Perl Q. Which one in particular it was, we may never know. If you have any details, please reach out to me at the e-mail address above.
I can’t make any clever guesses anyway since the only versions that the web archive has are 3.0 and 5.1. The latter is written in C, so it quite obviously can’t be the old Perl Q.
Making It Run
So now that I have CServe 3.0, I wanted to actually see it running.
There are three ways to reasonably accomplish this:
a. port CServe to a modern IRCd’s server-to-server protocol,
b. port an old IRCd to a modern platform,
c. emulate an old platform and run both IRCd and CServe there.
I chose option (b).
Once upon a time, I did option (a) for the old UnderNet X bot. It was a very painful exercise to port a bot that predates the concept of UIDs (or numeric nicks/numnicks as ircu’s P10 server-to-server protocol calls them). There’s nothing too exciting about doing (c) by just emulating a 486 or so and FreeBSD, just sounds like a boring roundtrip of emulation and network bridging.
Fortunately, the author was a nice person and wrote on the CServe website that version 3.0 requires “ircu2.9.32 and above”.
It seems the ircu2.10 series followed right after ircu2.9.32. While I’m sure there’s some linking backwards compatibility, determining which ircu in the ircu2.10 series still spoke enough P09 to link with CServe sounded like an exercise in boring excruciating pain. Modern-day ircu most certainly no longer speaks P09. Besides, what’s the fun in just doing the manual equivalent of `git bisect’?
So after grabbing ircu2.9.32, I tried to just straightforward compile and run it.
There’s a `Config’ script that’s supposed to be kind of like autoconf `configure’, but I’ve found it extremely non-deterministic. It generates `include/setup.h’. I’ve made a diff for your convenience. It targets Debian stable, and should work with any reasonably modern Linux. There are special `#ifdef’ branches for FreeBSD/NetBSD in the code. This patchset may break for BSDs in general.
Do not touch `Config’, meddle with `include/setup.h’ manually. Remember this is an ancient IRCd, there are actual tunables in `include/config.h’.
The included example configuration file is correct for the most part, but the documentation on U:lines is wrong. U:lines do what modern-day U:lines do, i.e., designate services servers with uber privileges.
Excuse Me, But What The Fuck?
Of course, I’m dealing with old code. It wouldn’t be old code if I didn’t have some things that just make me go “Excuse me, but what the fuck?”
Looping at the speed of light
for (acptr = client, (void)collapse(mask); acptr; acptr = acptr->next)
if (!IsServer(acptr) && !IsMe(acptr))
if (!match(mask, acptr->name))
See that `continue’ way on the left? What is it doing there? Telling the compiler to loop faster?
Carol of the Old Varargs
So apparently some of this code predates C89. Which means it uses old-style declarations, but that’s okay. It also uses old-style varargs, which is adorable.
The hacks around not even that being there are adorable, too:
These functions were declared like this (the example chosen above actually has
no declaration because why not):
extern void sendto_ops();
There are `mycmp’ and `myncmp’ for doing RFC1459 casemapping string comparisons. `strcasecmp’ got `#define’d to `mycmp’, but in one case `mycmp’ got `#define’d back to `strcasecmp’. It seemed easier to just remove `mycmp’, replacing it with `strcasecmp’ and forgo RFC1459 casemapping. This is doubly useful because CServe doesn’t actually honor RFC1459 casemapping.
Waiting for the Cookie
ircu uses PING cookies. I was rather confused when I didn’t get one immediately after sending `NICK’ and `USER’. In fact, it took so long that I thought the IRCd got stuck in a deadloop somewhere. That would’ve been a disaster since the last thing I wanted to do is get up close and personal with the networking stack.
As it turns out, it can’t send the cookie:
* Nasty. Cant allow any other reads from client fd while we're
* waiting on the authfd to return a full valid string. Use the
* client's input buffer to buffer the authd reply.
* Oh. this is needed because an authd reply may come back in more
* than 1 read! -avalon
I lowered `CONNECTTIMEOUT’ to 10 in the diff linked above. This makes the wait noticeably shorter when you aren’t running an identd.
CServe Isn’t Much Better
Not that CServe is much better. I have to hand it to Perl, I only needed to undo the triple-`undef’ on line 450 of `cserve.pl’ and it worked with no modifications. God bless the backwards compatibility of Perl 5.
That said, it has its own interesting ideas of code. This is the main command execution:
Yep, it opens, reads into an array, closes and then evals. For every command it recognizes. Of course, this means code hot swapping, but it also means terrible performance with any non-trivial amount of users.
Oh, and all passwords are hashed. But they’re hashed with `crypt()’. And a never-changing salt of ZZ.
Was it worth it?
No, not really.
Would I do it again? Absolutely.
You probably do not want to expose this to the outside world.
The IRCd code is scary in all the wrong ways.
Some other things if you’re into ancient IRC stuff:
As always, the old iD catalogue is on sale, featuring DooM!
Ultimate DooM is $9.75 HKD which is $1.25 USD. So if for some reason you have never bought DooM, at this price it’s hard not to have it. And of course all the old MS-DOS DooM can be had for $3.15 USD! And of course for those who want to downgrade to version 1.1, don’t forget my ancient article “Just how ‘original’ is the Ultimate Doom on steam?“
No, really I got an email today from Frank Sappone, that his passion project the fixing and overhaul of Daikatana was written up on PCGAMER. Although my involvement may have gotten edited down, honestly all I did was give that little bit of a push and inspiration that it could be done by spending a good week on installing Solaris, and porting the dedicated server portion from SPARC Solaris, to x86 Solaris. Once we had it running there, it was far easier to then get it running on Linux and OS X as a dedicated server. Once we had that push Frank was able to use his great knowledge of Quake/QuakeWorld/Quake II and fix an incredible amount of bugs, and bring it into a fairly good state.
The real star here is of course the Johns, John Carmack for making the source code to Quake/QuakeWorld, Quake II, open so we could always refer back to this code, which Daikatana was based off an early beta of Quake II, and John Romero for giving us the needed source to make it all possible.
(or if you’re running 64-bit Windows): C:\Program Files (x86)\Steam\steamapps\common\Daikatana\
If it asks if you would like to overwrite any files, do so and overwrite the files. End result is that when Daikatana starts you can see in the right bottom corner of the red area in main menu “1.3” instead of “1.2”. You’re also able to access for example the HD resolutions from the Video menu.
If you start playing multiplayer with Daikatana community, you’re also going to need:
And to further celebrate this awesome press day, I’ve purchased a limited number of steam keys, reply with a comment (be sure to include a working email address!) and I’ll send you a key! That’s right it’s the:
So forever ago I had done a super bare port of Quake to NeXTSTEP. It was based on a copy of UAE 0.6.0 source code that included hooks for NeXTSTEP. So seizing on this I built a shaky framework and amazingly got it to work. Well work enough I had trouble with the mouse part, and never did get around to fixing it, but I kicked it out into the world. And amazingly the HPPA cross compiled version that I compiled but never tested runs!
The following is a guest post / wrap-up of the Q2DOS adventure by [HCI]Mara’akate.
In the last update sezero and I([HCI]Mara’akate) tied up most loose ends with regards to Q2DOS. Specifically: adding in DXE support for mods and cleaning up some code from the early efforts. During this time, a forum user by the name of ggorts (strogg spelled backwards!) mentioned the possibility of using an old Mesa version with 3DFX support in DOS. I worked on separating the ref_soft from being statically linked into a DXE form and sezero cleaned up any potential problems there.
I mentioned the possibility of attempting the Mesa port to sezero and he thought it was probably a wasted effort and thought making a ref_glide depending only on glide3x.dxe would be a better way to go with less overhead. I started some initial work on it but quickly abandoned this side-project as I have no real glide (or even OpenGL) knowledge and didn’t have enough time on my hands to play around with it.
Around this time, we also separated the GameSpy browser code into a separate DXE for potential legal issues. The GameSpy code was publicly released, but never officially GPL’d. Using this method, other port authors could link against a gamespy.dll to add in the browser capabilities that connect to my GameSpy master server emulator (see QDOS branch for source code to that particular project).
Ggorts also came up with some code for us to be able to finally use the banked modes and Mode-X 320×240. Though 320×240 Mode-X seems to have some issues with certain emulator configurations, for the most part it works OK. This also helped us to get some ASM rendering code in from Q1 and help clean up the original mess that was the SVGA driver; a lot of unused code from Q1 was removed and sezero found a clever way to send the video modes list between the game binary and renderer DXE.
In any event, one night I figured I’d take a stab at trying to get Mesa working in Q2DOS. Checking out the Mesa3d FTP and researching the various changelogs it appears as if Mesa 5 series was the last true effort with Mesa 6.4.x series being the last maintained version with 3DFX specific code. I got everything to compile but ran into hard-lock issues no matter what I attempted. During this time, ggorts found out some various small, but now obvious issues. Including increasing the stack size to 1MB and he hard-coded the ref_gl to only work in 640×480. It took a lot of pleading but eventually he released his source with a static compile for Voodoo 1 cards only as he was testing this on emulators like DOSBox with glide support and PCem dev branch.
I worked on cleaning up the source and he produced some glide3x libraries for me for Voodoo 2 and Voodoo 5 as these were the only cards I personally owned. Imagine my surprise as I first loaded it up and it actually worked! And it was smooth with no rendering issues!
At this point, sezero became involved and worked very hard to clean up the Mesa compile issues, including various scary warnings and helped to update us to the final glide3x commit pushed to the development branch and Mesa v6.4.3 which was an unreleased maintenance update for Mesa v6.4.2.
It was a long journey to get the code all working together just right, and a big thanks goes out to the early Mesa crew including Brian Paul, Daniel Borca, and “KoolSmoky” and the mysterious ggorts fellow who pushed hard for this feature.
To recap, Q2DOS from the last time we talked now has:
3DFX Rendering with Mesa v6.4.3 for all Voodoo cards.
Separated renderer so it is no longer statically linked.
GameSpy is now a DXE.
WAV streaming, which is practically free as opposed to the OGG format.
We are about at the end of our Q2DOS journey. A few odds and ends with Mesa and Voodoo 5 SLI issues remain (though nothing too show stopping) and there’s a small wishlist of some unnecessary features but it’s come a long way from the initial null driver effort!
I have to say it is simply incredible to see how Q2DOS went from a very primitive ‘wow it works’ port to a full featured port. Simply amazing!
Since the last update we got some help in a few fields that have really fleshed out this ‘experimental’ port into a full fledged port. First RayerR helped us with the fun of getting us onto the latest deployment of DJGPP, 2.05 (rc1). It’s always nice to be in the latest available release. Next in a passing comment, Ruslan Starodubov had mentioned that he had gotten a much older build of our QDOS to support the Intel HDA sound chipset via the MPXPlay sound library. I wrote to the author of MPXPlay, Pádár Attila asking for us to distribute his source in our project, and he granted permission.
So at this point things were looking good. The only ‘feature’ that modern OS’s really held over us was the ability to dynamically load and unload game modules on the fly. I had tried to use DLM, but it stripped the DPMI functionality out of the MS-DOS Extender making the port really useless. I tried to build the newer DXE3 support but had no luck. I suspect now my native tool chain was interfering with the build process. But Maraakate managed to get it to not only build, but to run!
Adding in DX3 support was relatively painless. I first looked at DJGPP’s FAQ and downloaded the example code. In the example code there was small helper functions to make unions and check the symbols. If they didn’t exist a printf was spit out to alert you about it. To resolve the issue you simply just add DXE_EXPORT to the other list of missing exports.
Compiling the game code was easy, again referring to the example I saw that basically they compiled it the same, but at link time you use DX3GEN and -U flag to ignore unresolved symbols.
The biggest head scratcher was the Sys_GetGameAPI failing to find GetGameAPI from the DX3. After some piddling around I noticed that it listed GetGameAPI as _GetGameAPI inside the DX3 itself. I added the underscore and it worked!
Other things that were relatively to easy to import was R1Q2’s HTTP downloading code. Compiling CURL was kind of tricky because of the linking order, but thankfully neozeed figured it out quickly.
All of Yamagi’s Quake 2 updated game DLLs were all diff’d by hand using BeyondCompare to make sure I didn’t clash using some newer functions that weren’t available in DJGPP. I also merged their Zaero code with their baseq2 code by comparing Zaeros code to the Quake 2 SDK, marking every thing that was changed. The result is a really stable Zaero game code. If you haven’t played Zaero check it out. I think it’s a lot better than Rogue, but Xatrix is probably my favourite (even over stock Q2).
Other cool things I’m glad to get into the code was the GameSpy Browser. It took me quite a bit of work to get it where it is, but it’s really nice to just be able to ping to a master server (a custom GameSpy emulator I wrote specifically for Q2DOS. Source is not finalized yet, but will be available soon for those curious), pick a server and go! All in DOS!
So here we are at the end of the journey. Or at least safe enough for a 1.0 release.
To recap, we have:
* SVGA (LFB modes only)
* SoundBlaster and Gravis UltraSound Family
* CD-ROM music
* OGG music
* Networking (You need a packet driver)
* Loading/unloading game DLLs in DX3 format.
* Intel HDA support -hda
* Mouse wheel support with -mwheel