So I thought I’d look for the latest release build of ReactOS, and give it a whirl. First I download 61112, and installed it on Qemu 1.7rc2 on OS X. First I gave the VM a 500MB disk, and 500MB of ram… which led to the thing using the whole disk for paging and was terribly unstable, and all around no good.
So next I got smart, used 64MB of ram, and a 1Gig disk, installed then turned off swap. Now it is more usable. I thought I’d do something crazy, and install Visual C++ 4.0. The installer works, except there is no progress, and it can’t create program groups. No problem I think as it does the same thing on CrossOver(wine). I download my QWDOS project with firefox, extract, and open the makefile and… all the menus are blanked out. And dropping down to the CLI, although the installer ‘registered environment variables’ the compiler wasn’t in the path. Clearly registry information is dropping.
So falling back to nmake I can at least compile my release build, and amazingly -it works!
So is it perfect? No far from it, but it certainly is a lot more usable than it was a year ago.
I built 1.7rc2 on OSX, and I’ve only tested the x86 portion… x86_64 of course still fails on vista & friends… 2003 of course hangs at “starting windows” so no progress there. I haven’t tried any MIPS, PowerPC, or SPARC things…
Also the Adlib/SoundBlaster is still broken in this release, there is a source change in adlib.c that has to be made. Also I just noticed that IRQ sharing works in ISA mode again, so the Ne2000 can go back to 0x300 IRQ 9.
Also speaking of emulation, I was thinking of shoving a VAX-11/780 into the world for the heck of it. Although I don’t think anyone would care. I’ll have to dig out the source to 4.3 and give the shell the ability to add new users. I wrote it once, and I fear I’ve lost those changes but it was cool for something back then.
Really I saw it right here! It is only in it’s beginning stages, but it can run some very simple COM programs.
I should also say, I ran a nightly build, and it is coming along much more than the last year.. I didn’t trap or anything messing around. What I did do was run out of disk space with a large swap file, and downloading too much crap….
A good friend passed on this link. And what an amazing thing!
So basically a Raspberry Pi (which can be had for sub $50 USD), running a bare metal program can emulate the control signals of an Amiga floppy drive. It reads disk files from a flash card, and serves them to the Amiga. It can even kickstart an Amiga 1000.
I know that floppy emulators have been an on/off hot topic, but this is pretty interesting!
I stumbled across this site a while back, but could never get it to run. From the description VIM is:
..(vim) is a debugger, I can’t let a bad program take out the interrupt vectors, DOS, or whatever. Hence the “Virtual” in the name — VIM takes whatever memory it can get, and sets up the interpreter to use a “virtual” processor. So, when the interpreter uses Interrupts, DOS, etc, it’s using the virtual copy, so that a bad program destroying them won’t hurt VIM, the real DOS, real interrupt vectors, etc.
Which is very cool, unlike traditional debuggers which try to hide in memory, VIM executes outside of memory and is then invisible. Unfortunately it is rather tied to ANCIENT hardware. And executes better on an 8088/8086/80286 processor. I thought I could run it on Qemu, but it’ll trap on the BIOS as it’ll have instructions outside of VIM’s understanding. However using PCem’s 80286 emulation it’ll run fine.
Another interesting thing about VIM, is that it includes the full source code, which is built with Aztec/C, however it doesn’t build cleanly as you have to finagle some of the assembly.
Running this on PCem is quite nice, as you can set it for a FAST 80286 computer, so it won’t take 10 minutes to boot a virtual copy of MS-DOS.
Is this useful? Well maybe if you feel the need to write an MS-DOS device driver, VIM can debug it.. but otherwise, it is an interesting fossil.
So I spent a few hours updating some QuakeWorld clients.. for reproducibility sakes, I built out the MS-DOS one and that worked fine. The OS/2 one ‘works’ but the keyboard isn’t working. Not so sure why not. The Win32 version works fine, although I’m building with Visual C++ 4.0, and no assembly or DirectX. Just straight GDI.
Next will be Linux with svgalib.
So my work is here. I could go more into how to build, but I don’t know if anyone cares.
I know this may sound silly, but I’m a silly person. And yes, QuakeWorld used to build cleanly and fine on Linux. However it doesn’t anymore, things have changed a *LOT* in the world of Linux, since the birth of QuakeWorld in 1996. A different LIBC standard or two, and all kinds of other changes in the compiler. Not to mention I have a x86_64 machine, and I want a pure 32bit binary, so the best way to go about that is to setup a 32bit virtual machine, and build from there. I know I could cross compile, but on the otherhand I don’t want to install all this kind of crap on my server if I don’t have to. So there is all kinds of reasons why you may want to build your own. Not to mention if you are running Linux, but on a non x86 platform. I guess the Raspberry Pi would be a good choice now that it is over two million units sold.
The first thing you need of course is the source code to Quake, from iD (my mirror). Next you’ll need a more up to date Makefile. I used the one from the LinuxGL-QuakeWorld-mini-HOWTO. Don’t worry about the client stuff, it doesn’t matter the first thing it does anyways is build the server.
For the sake of preserving it, here is the makefile:
With that saved into a file, it is time to build. Unzip the source code into a directory, and then from the QW directory run the new Makefile. If your GCC is new enough it’ll complain about the -m486 directive. Just remove that from the Makefile. On my bare build system it compiles the server in a few seconds, but then fails to build the GLQuake client because I don’t have any OpenGL installed. But again this is fine, I just want the server.
The next part is to copy in the pak0.pak & pak1.pak from your registered copy of Quake 1 into /usr/local/quake/id1. You can always buy it on steam, although it is so old I’m sure you’ve already acquired a copy or two in the last few years. Note that pak0.pak is the shareware portion of the datafile! To be a server you require pak1.pak from the registered copy of Quake. Although the source to the maps has been released, I’m pretty sure you will be missing all kinds of otherthings from pak1.pak.
Ok now with the pak’s in place, you need the QuakeWorld scripts in place. Copy the ‘progs’ directory into the qw directory
However you probably will want a server.cfg. And incase the page goes offline here is a pretty basic config:
hostname ”Your Quake DM Server”
serverinfo admin ”email@example.com”
serverinfo url “http://www.yourwebsite.com”
floodprot 4 8 30
floodprotmsg “You have activated the flood protection and will be silenced for 30 seconds”
Naturally you may want to change things. Save the config file into the id1 directory.
Now when it comes to running the server, the console will want to be interactive to the user. If you nohup the process it’ll go bezerk. The best way to do this is with screen. In my /etc/rc.local I add the following line:
screen -dmS quake /usr/local/quake/quake.sh
And of course the shell script is:
Very simple stuff. If the server crashes or stops for any reason it’ll restart.
By default QuakeWorld will listen on UDP port 27500. The next thing you’ll need is a client to test. I’m kind of partial to the MS-DOS (qemu) and OS/2 clients.
And there we go, now you too can host your own QuakeWorld server. And for those who can’t compiler, you can try my x86 binary here.