World Of Warcraft has gone “free”…

Good lord like things could possibly look any worse!

The end of humanity

I don’t know what even overcame me as I read the news on thinkq, but I’m already thinking of backing out. LOL  But it’s now “free” to people for the first 20 levels.  But who would want to quit at level 20 and not go all the way to 87?

Oh the humanity.

For anyone crazy enough you can join HERE (Europe) or HERE (United States), HERE(Korea), HERE(Chinese)

Oddly enough no links for Japan.

Anyways don’t say I didn’t warn you but…. The full install is also some 10GB!  Good luck you people in capped areas.

OS/2 2.1 and TCP/IP 2.0

So I thought I could simply take my OS/2 2.0 install on Qemu with an ISA NE2000 and simply upgrade it to OS/2 2.1 and it’d work, right?



So after an hour screwing around with various drivers, I found of all things, the PCI NE2000 will work.  The driver is available

Thankfully the NIF’s and OS2 bits work right so you can actually use LAPS to configure it, once you copy the NIF & OS2 files into the c:\ibmcom\macs directory.

LAPS to the rescue (for once)

And then with that in place configured for user mode networking ( DNS

All is working as expected.  I’m hoping that the DPMI emulation is better in 2.1 vs 2.0.  Although what is interesting is that after applying XR06200, my OS/2 2.1 is now 2.11 …

terraria networking

Personally, I couldn’t care less about Terraria, although it reminds me a bit of Zelda III back in the day, but it does have this multiplayer capability.  But it never mentions the TCP port.  Well the default port is:


And if you have an Apple airport network, a teenager that needs to have ‘cut off times’ and sits 2 levels of NAT in, you’ll have to forward TCP 7777 all the way to their computer.  It’s not the end of the world but UPNP doesn’t work in nat-nat scenarios (thankfully) but the blasted game doesn’t mention when setting up a network game, oh by the way you’ll need to NAT TCP 7777.

Oh well that is all.

Building Qemu for a VPS

So touching on my prior long winded post, I was mentioning that running Qemu ‘headless’ on a resource constrained VPS was different then running it interactively at home.  For starters you don’t want to install X11, and all the necessary libraries just for a single program if your VPS is limited to 2GB, as it is more then likely that you will exceed your disk space just by trying to get a workable environment.

Instead, I’ve found the way to go is to take advantage of Qemu’s built in VNC server.

I build my own version of Qemu at home, then just upload the binary.  While there may be packages, because of the expectation that you’ll be running X11 for the SDL output it could easily pull in several gigabytes, that I’d rather use for disk images.  I recommend people build with the same OS as their VPS uses, to keep things ‘sane’.  Not to mention you’ll have a far higher success rate by matching OS levels.  And yes I do this in a VM, all the more reason to have VMs.

Also I should mention that in constrained space, I find that 32bit OS stuff is smaller, if you have a 64MB memory limit, then yes size does matter.

The steps are pretty simple, it’s basically download & unpack the source, then configure it something like this:

./configure --target-list=i386-softmmu --disable-sdl --enable-vnc-thread --disable-bluez --disable-curl --disable-vnc-tls --disable-vnc-sasl --disable-spice

Then run make, and after a few minutes it should complete the build.  I then manually ‘strip’ the qemu executable, tar it up and then take it for a test run.  For the most part it really is that simple.

Again I’ve found building on the same distro as your VPS is using helped an incredible amount.  Not to mention trying to keep your ‘build’ machine as bare as possible so it’s not pulling in all kinds of wild dependencies.

The next thing with Qemu uploaded is you’ll want to test it.  It works like normal Qemu with the exception of how you then specify your display to go out via VNC. For me, I run it like this:

./qemu -m 16 -hda os2.disk -hdb data500.qcow2 -vnc <Public IP>:101 -net nic,model=ne2k_isa -net user -L pc-bios -fda empty.vfd -no-reboot  -redir tcp:23::23

Then you can connect with just about any VNC client on VNC port :101 (or TCP 6001)

My OS/2 BBS on Qemu via VNC

And from there I just wrap it in a while true/do true script so that way every time I reboot the VM or if it were to crash for what ever reason it’ll keep on trying to start it over and over.

Back to memory consumption, as you can see I’ve configured my Qemu intance for a whopping 16MB of ram, and this is what it looks like according to top:

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND 2785 root      20   0 72868  33m 2164 S    2 57.5   1:03.69 qemu

Which is the resident size is 33MB, out of my 64MB VPS, with lhttpd running and php for the socket support I have a whopping 1MB free!

That about covers it, and for the Debian people out there here is my build of Qemu 0.14.1. I should imagine it’ll run on other i386 Linux OS’s (or x86_64’s with the 32bit compatibility installed)

Another day in the cloud.

So my BBS thing is down… hard.  After asking the provider ….

It appears that one of the air conditioning facility at the data centre has ceased operation and so servers are struggling with the heat. Emergency work is already being carried out.

Such is life in the ‘cloud’.

It’s times like this it’d be nice if doubletake were cheap enough for us low end users.

I suppose there is rsync, but that’d take a little work with Qemu, or would it?

Well I pulled the plug on the old place….

So now this is pretty much vacant…

If anything it’ll be interesting to see the ‘google’ fallout as I know I was indexed here, but pretty much everything I wrote showed up from the old site.  Oh well worst case I can always restore the backup.

But I’m also keeping ‘virtually fun’… I spent too many years on that one to just let it lapse out for someone to google poison the thing.

Anyways I also started to add some generic info pages on OS’s and emulators… At least it’ll be a somewhat better way to find the latest builds of Qemu or what is the current release of whatever OS…

I should have done that a while back, but as they say no better time then the present.

Pre-release versions of DOOM

On the heels of a jdosbox update, I figured it’d be cool to try ALL the early pre-release versions of Doom!  I’ve setup the links so you can click on any picture, and it’ll launch the appropriate jdosbox emulator, with the disk image.  Just click & go!

So here we go!

Doom 0.2

This is a pre-alpha version of DOOM from early February 1993 — only 2 months of work had been done to this point.

This is the first version that was made semi-public.  As you can see the HUD is the inside of the helmet.  The sky doesn’t work, but you can move around, and see the monsters from various angles..

Doom 0.4

Yes, it’s the DOOM ALPHA!  (Actually, we’re just try to release theseevery two weeks or so.  This WAS going to be a pre-beta, but a certainperson let us down Super-Nintendo cart-programming-wise, so it’s just analpha.  Nonetheless, here ’tis.)

It feels more doom like… But you can’t kill anything, and they can’t kill you… better textures and whatnot.

Doom 0.5

From the notes:

It’s an ALPHA version of doom (I just run it to make sure)called “Doom: Evil Unleashed”.  Start up screen says Doom Alpha byId Software.

It has the basic Doom engine, but:

  • It has the basic Doom engine, but
  • The imps and pink demons are in the game they don’t move or anything just stand there
  • No barrels (as noted above)
  • A lot of graphics from wolf is used (eg medic kit, gold treasure cup)
  • The map key is “a” not tab
  • The strafe and open door key are both alt
  • No sounds!
  • The two weapons you start with are (1) bayonet and (2) rifle
  • There is no run key (that I could find, so makes getting around really slow)
  • It is quite easy to recognise some of the structures in the game (so the whole map structure is now over two years old).  I can’t quote exactly were they are from but I do recognise them.
  • In the screen options there is high, medium, low, <another one>, and HIGH RES, so it looks like there use to be a high res mode that was taken out in the official release.

Doom Press Release Pre-Beta

This is the press release pre-beta version.  As you can tell from the screen shot it’s basically DOOM.  Some things are different though.  The readme is pretty long, and I think it’s better to just link it here.  I took the CPU cap off this one as it really seems to want to run FAST.  But I’m probably just screwing something up in the world of jdosbox.  But it does run, and quite nicely on my core i7.

So there you basically have it… Lots and lots of DOOM!

Update for jdosbox 0.74.23

Woo new update, and here is what’s changing!

0.74.23 June 5, 2011
* Fixed a serious memory error that mostly affected EGA era games
* Increased performance of the dynamic core a bit
* Improved audio by reducing stuttering on some games

0.74.22 May 29, 2011
* More fixes for Windows 3.11

0.74.21 May 27, 2011
* Fix for Windows 3.11 that affected Freecell

0.74.20 May 27, 2011
* New dynamic core, most games are 2x faster than build #19
* Fixed lots of minor bugs, mainly around installers

Download it here!

So i did update my jdosbox stuff, for anyone that enjoys this stuff. Hopefully it won’t blink like crazy on OS X.


Pushing Windows/386 out the door…

While one may think that Windows 2.x started with the ‘regular’ version, it does indeed turn out that rather the 386 specific version was rushed out the door to appease Compaq, and their new Desqpro 386 computer, namely the 20Mhz 386 model that was going to debut in late 1987.  Indeed, Compaq not only set the standard with the 386 CPU, but they were going to set the future standard of bundling not only MS-DOS but Microsoft Windows.  At this moment in 1987 you could really say that the ‘modern pc market’ was born.

Windows/386 2.01 from OS/2 Museum.

And it does make perfect sense, with 386 specific software being very rare/hard to come by, keeping in mind that Phar lap 386 was only announced in December of 1986!  But it was expensive, and 386 specific applications cost a fortune, and didn’t have wide market penetration (we were still years away from DOS4G/W or GCC).

Another thing to keep in mind is that OS/2 had not shipped either at this point, and apparently this version of Windows/386 would not even support the IBM PS/2 model 80, as there was some noise about IBM not wanting to bundle Windows on their computers.  Now when you think about it, it is kind of funny that Windows an inferior product came out with a GUI and multitasking MS-DOS via the 386’s v86 mode, while OS/2 was still in a beta stage.  Not to mention IBM’s reluctance to bundle Windows/386 shows just how the Windows rift was an issue even back in 1987!

Looking at this December 1987 InfoWorld issue we can see it in action:

From, InfoWorld Dec 1987, Windows/386 in action

And it’s no wonder why this was going to be a hit.  And the UI looks just like how Presentation Manager for OS/2 1.1 was going to look, almost a full year before OS/2 1.1 was delivered (Halloween 1988!)

Now trying to peg down exactly When these releases of Windows 2.x were, esp with Windows/386 2.01 being the first, in September of 1987.

From what I can work out, Windows 2.01 ‘regular’ was shipped around November of 1987, with the 2.1 update in July of 1988, and 2.11 in March of 1989.

While on the topic of Windows 2, there was one slightly interesting feature, of the ‘regular’ or ‘286’ version of this product.  It could multitask MS-DOS.  No really, but it was all out of the same conventional memory space.  So unless you were into COM programs it wasn’t terribly useful.

The later 286 versions included early himem.sys drivers that permitted some trickery with the A-20 gate allowing an additional 64kb of ram to be accessed from real mode.  It may be a good thing that nobody found out about unreal mode at the time..!

I don’t know if it is even possible to tell them apart, besides the 386 and 286 (regular) versions but here is a small gallery of Windows 2.0 running

Windows 2.03

Windows/386 2.03

Windows/286 2.1

Windows/386 2.1

Windows/286 2.11

Windows/386 2.11

Included is something special for the 2 or 3 people that’ll figure it out. 🙂

Running QEMU from a VPS

I’ll expound on this as I go on.  For now this will be an overview with separate articles going into each part.  I’ll go into the process of how I created my OS/2 2.0 BBS, .

VPS’s (Virtual Private Servers) are getting cheaper as the days go on, and it only makes more and more sense to take advantage of these great things!  Almost all of them are geared to running Linux, a few to Windows, and well anything outside of those two is damned near impossible to find (I’ve seen ONE NetBSD VPS service).

So if you want to say run MS-DOS, OS/2, Xenix, or any other crazed OS (why not?!) you are basically SOL as they say, except of course, if you utilize our old friend Qemu.

The first thing you’ll need is a VPS.  Now there are thousands of providers out there, I can recommend what I use (and I’ve got a few) but as always, pick a plan that you feel comfortable with.  To get started on something small a budget of under $10 USD a month is perfectly fine.  Shop around and you can certainly find cheaper in the month to month space, and if you are willing to pay up front, I’ve seen them average down to $2.50 USD a month.  Yes for less then a Big Mac, you can have your own ‘server’ in the sky (or part of the cloud nonsense if you are into that).  Hell you can even setup your own global infrastructure, with servers in Europe, Asia and North America for about $20 a month!

Anyways you can find an overload of reviews, and listings on sites like, and lowendbox.  Again I know it can be overwhelming but googling around you can eventually find what you are looking for.

Now what is important for running Qemu on a VPS? I’d have to say, memory is the #1 thing, bar none.  Now the joy of running older OS’s is that they didn’t need much back then so any new VPS ought to be ‘extravagant’ to them, but keep in mind Qemu needs a fair bit of memory itself!.  I generally worked it out to consume with a ‘bare’ CentOS or Debian install with an 8MB VM to consume around 60MB of memory.

Keep that in mind, that with your VM the OS will need memory, as long as disk space is also needed.  So it all depends on what OS you plan on running.  I’ve run MS-DOS, OS/2, Windows NT, and 386BSD all on the ‘cloud’.. And 8MB was fine for 386BSD but really the VM was overtaxed for anything outside of serving the VM… This for me was fine.  Again keep this in mind if you had hopes of serving web pages, hosting a blog (wordpress needs like 512MB of ram++!!!!!) or whatever.  Another thing is the x86 vs .x86_64 (32bit/64bit) question, and for VPS’s that need to keep small you will want to run 32bit code.  Esp if your VPS is configured under 2GB of ram, really there is no big ‘deal’ in loading 64bit stuff, epically since the 64bit versions consume more memory.

If in doubt setup a VM at home with the same constraints you are shopping to see if you can even do what you hope to do.  This is the big advantage of VM software as you can test all of this from home, without any major pain!

Another thing to keep in mind is that with your own VPS you will be the one required to keep it up to date!  Pick a distro that you are somewhat comfortable with.  Personally I went with Debian in my VPS’s as that is what I’m the most comfortable with.  Also I’d HIGHLY recommend NEVER EVER installing a compiler on the VPS.  If someone does get onto your system, handing them a compiler is like a loaded gun.  At least make it more…. involved for them.  Also setup a VM at home with the same OS, same cpu, same flavor *WITH* compiler, so that way you can check updates at home, to make sure things work, and of course compile things like Qemu for your environment without worrying about things that are either incredibly stale in packages, or just not there at all.  The same goes for things like firewalls.  Again pick something you are most comfortable with, and try to stick with that. The majority of OS’s available are Debian, various Debian forks (Unbutu?!) and CentOS, the RedHat ‘free’ clone.

With a VPS selected and created, and a VM at home loaded up with the same OS you will want to build Qemu.  Now keep in mind that since you’ll be running this on a server that will *NOT* have any local X11, and to minimize memory consumption & disk space by not loading .. X11, you will need to create a version of Qemu that is VNC display only.  It’s not that difficult.  It’s covered in the config process.

With a version of Qemu built, and uploaded to your VM (I use scp) you will then need to decide if you are going to encrypt your disk images (can you really, really trust your host?) or if you are fine with the way things are, and you are going to run in the open.  Naturally ‘fixed/flat’ disk images will be faster and not as CPU intensive, but of course they consume more disk space.  If you are going to ‘overcommit’ your VM or just don’t want to have the empty space right away, I’d highly recommend making a swap disk for the VM, that way you won’t blow out your disks with swapfile growth/shrinks and eventual fragmentation and moves.

If you did choose to encrypt your disks, you will need the program ‘screen’.  It’s been around for a long long while, and every Linux distro should have it available.  You will need to run screen, then launch Qemu from within screen, then it’ll prompt for the password for each disk drive.  Once Qemu is operational you can disconnect the screen session and it’ll remain operational.  Doing so in a script would require you to store the password locally, and defeats the whole point of encrypted storage.

Beyond storage, you’ll want to select some kind of method for external communications with the world.  For an OS/2 BBS I simply take TCP port 23 and forward it to the VM’s port 23.  SIO & vModem take care of all the logic from there.  If  you wanted to telnet into a *NIX box, again tcp port 23.  Maybe you want to run Windows NT 4.0 Terminal server, in that case the default TCP port is 3389.  While NT 4.0 is limited to Internet Explorer 6.0 and Firefox 1.5, it still can be a handy thing to have a multiuser version of NT (like a windows mainframe) out there somewhere for some things, although its usefulness is dwindling.  Maybe you want your own Exchange Server, or even SQL 7 instance, again older software performs better in tight disk/memory constraints.

Another thing to keep in mind is CPU consumption.  You will want a guest OS that can idle.  Otherwise you will consume 100% of the CPU 100% of the time, and they *WILL* notice this, and kick you out.  Be mindful of VPS services, and you have to share CPU resources.  Again watch your task manager or ‘ps’ locally and watch how things behave.  I know for the BBS stuff, you have to watch what doors you are interested in running as some of them happily gobble 100% of the CPU.  OS/2 friendly stuff is the way to go (IMHO) as CPU hogging was a big deal back then, and it’s best to ride on the back of how people solved this stuff a while ago.  Also for MS-DOS people, things like Dbase III applications it’d be a “bad idea” to put them into the cloud.  Although if you get one with a higher SLA that lets you run 100% then.. have at it!

If Qemu runs ‘normally’ you can even set it up into a batch file loop that calls Qemu over and over as needed between reboots.  You could even do some ‘house cleaning’ between reboots, say make a backup, email a notice etc… It’s all up to you, and what you are capable of batch script programming wise.

Also you will probably want your VPS to automatically launch your Qemu VM, and the best way I’ve found to do this is via the GNU screen program.  I just added the following to my /etc/rc.local file:

screen -S qemu -d -m /usr/local/os2bbs/
screen -S cpulimit -d -m /usr/local/bin/cpulimit -e qemu53 -l 8

This gives me two named instances, and will automatically limit my Qemu to only 8% of the host CPU that way I don’t get kicked for being a CPU hog.  8% of a 3Ghz CPU is more than enough for stuff that ran comfortably on a 16Mhz machine back in the day.

Then that would about wrap it up, you would now have a Linux VPS running your own OS, so you could serve up whatever application you want in the cloud.  The best part is, because Qemu is multiplatform, and will run on various OS’s and CPU combinations, you can jump ship very quickly to other platforms as you see fit, as all you need to do is rebuild your Qemu hosted binary, then copy your disk images & startup scripts and you are good to go!

Not to mention there is nothing to stop you from building the VM on Windows, to upload to Linux, then maybe move to SPARC Solaris!

Screw Java, Qemu is the ultimate VM!