Moving servers again..

FragReady!

FragReady!

(EDITED)* So it seems that Fragready just knee jerks to bogus virus claims by fly by night idiots like  clean-mx.de because they are terrified of nethack on WindowsCE.  Yes really they deleted my server because of an old game on an old platform.

So here we go. again.  2013 seems to be the year of plenty of moves.  While cruising around LEB, I came across this special on Frag Ready.  So yeah I’m going to collapse all my VPS stuff (once it is finished copying) and move everything to a dedicated server.

What I’m hoping this will mean is that I can do far more neater things as now I don’t have to worry about CPU limitations, blowing my own quotas or being able to load whatever I want.  I think I’ll even go back to offering some kind of public UNIX thing, I just have to decide if I want a SIMH VAX running BSD 4.3 UWisc, or whatever.  I know I’ll certainly bring the Quake 1 server back, and maybe, just maybe hack enough to get a Doom dialup server going (if I can convince it to talk to my fake modems).

Another observation is that using the new ext4 filesystem means things are slower than ever.  I know this server is two years old but still my seven year old Mac Pro destroyes it running Qemu vs running KVM on this linux box.  I’ve found the two things help for performance some.

Convert disk images from sparse VMDK to QCOW2

# qemu-img convert -f vmdk -O qcow2 -o preallocation=metadata source.vmdk destination.qcow2

And changing KVM from ‘-hda disk.vmdk’ to

kvm -cpu pentium -m 256 -drive file=/usr/local/kvm/disk.qcow2,if=ide,index=0,media=disk,cache=none -vnc :0 -net nic,model=pcnet -net user

Next was to change the way the volume was mounted.  First a change in the filesystem

tune2fs -o journal_data_writeback /dev/sda1

Then changing the options to the following in fstab:

noatime,data=writeback,barrier=0,nobh,errors=remount-ro

So yeah, it feels a little better now.

Here we go, again with what is moved over so far:

Crossover version 13 released today!

Or so I think, I got my alert while running some highly productive software..

From their announcement:

The focus of CrossOver 13.0.0 is better performance for games.
CrossOver 13.0.0 includes our new Performance Enhanced Graphics.  With
Performance Enhanced Graphics, CrossOver creates a dedicated thread
for graphics commands, making better use of the CPU and GPU.  During
in-house testing we have seen some frame rates double what they were
with earlier versions of CrossOver.

CrossOver 13.0.0 also includes numerous other enhancements for your
favorite Windows applications.  This release includes a new version of
Wine – the open source Windows API layer that makes your Windows
applications run.  On the Mac, CrossOver 13.0.0 includes several fixes
to our Mac Driver.  On Linux, we are now shipping multiarch packages
on Debian-based distributions, which should make for smoother
installation of CrossOver.

A changelog for CrossOver 13.0.0 is shown below.

Mac customers with active support entitlements will be upgraded to
Crossover 13 the next time they launch Crossover. Linux users can
download the latest version from http://www.codeweavers.com/.

If Crossover asks for registration use your codeweavers.com email
address & password to register and unlock Crossover. Email
[email protected] if you need more help.

Thank you all for your support, and we hope you enjoy CrossOver 13.0.0!

Changelog:
==========
CrossOver 13.0.0 – 11/12/2013

* Games Support:

o CrossOver 13 has our new Performance Enhanced Graphics. Games will run
faster, with higher frame rates! This is a major overhaul of the 3D
graphics processing in CrossOver, and gives significant improvements in
many, many popular games.
o The launcher for Borderlands 2 is working.
o Both the Gem Store and mouse work with Guild Wars 2.
o The mouse pointer in Terraria is now accurate when the window is resized or
zoomed.
o Rendering bugs with RIFT on NVIDIA hardware are fixed.
o Multi-core rendering can now be enabled in Source games.
o Mirror’s Edge now runs under CrossOver.

* Mac OS X:

o Input Managers will no longer cause Windows applications
running under CrossOver to crash.
o When you Command-Tab out of a full-screen program and then back,
CrossOver will restore that program’s display resolution setting.
o CrossOver uses accelerated OpenGL in all cases.
o Added support for Mac-style full-screen windows.
o Enhanced the system tray icon support to handle right-clicks and
middle-clicks.
o Fix a bug which could cause CrossOver to display two mouse
cursors in some applications.
o Lots of window management fixes.
o Fixed scrolling going diagonal when it shouldn’t.
o Fixed certain programs (e.g. Quicken 2013) failing to launch when
using certain keyboard layouts (e.g. US International PC).
o Fixed a bug where the select-bottle section of the Software Installer
window would say Please Wait forever.
o Improved icon extraction from Windows executables.

* Linux:

o Architecture specifications have been removed from our package installer
filenames. That is, our package installers filenames no longer include the
‘i386’ specifier. This is purely a cosmetic change in the filenames we ship
– some customers were confused, believing they needed a different installer
for 64-bit machines, which is not true after the switch to multiarch.
o Files saved with Microsoft Office are no longer marked as ‘executable,’
meaning they can be opened by clicking on them in Nautilus or other file
browsers.

* Application Support:

o Project 2010 will run faster.
o Macros function much better in Microsoft Excel.
o Access 2000 user interaction is smoother on OS X.
o The system tray for QQ is functional now on OS X.
o Kayak Foundry will load files again.
o Fixed a crash in the Chinese version of Microsoft Office Home and Student
Edition.

 

I’m one of the people who ‘flocked the vote‘ back in the day for a free version, and now I get new versions for something like $30 USD a year.  I know I could probably build wine on its own, but honestly even back in 1994 building wine was a PITA, and I’m too old to care about doing it now.  I just kinda want it to work.

PCem 0.7 and beyond

Checking out that javascript PCe made me want to check out PCem.  And good reason too, as its latest version 0.7 can run OS/2!

At first I tried version 2.0 and it just reboots once it is going to start the installer, (I haven’t tried a pre-installed disk image yet) but for the heck of it I shoved in an OS/2 1.1 boot diskette, and it came up!  So all excited I tried 1.21 and it worked as well!  The caveat is that OS/2 cannot partition or format the disk.  I didn’t try giving it a HPFS volume, but rather setup for a DualBoot with MS-DOS, and that worked fine.

OS/2 1.21 on PCem 0.7

OS/2 1.21 on PCem 0.7

Some of the cool things about PCem is that it runs REAL firmware, so you get the real XT/286/386/486 experience.  Also it is cycle accurate so things are SLOW like they were back in the day.  I’ve noticed that disk IO is really slow.  Again just like it was back then.  Things like DOOM take forever to load on a 386.  Just like the real thing!

If you have the ROMs the CGA/EGA & SVGA emulation is pretty good.   Again this is largely from running the actual firmware.

Work has slowed on PCem, but there is a source repo here.  I haven’t tried to build it yet.

The only thing I’d say is missing is some kind of ethernet adapter.  It would be cool to get this onto the internet.  But at the same time I’ve got to say this is pretty cool, especially if you want to enjoy the PC experience from 20 years ago, this is the way to go!  Although after a few minutes of running a 286 at 6Mhz, you’ll want to push for the fastest 486 it can emulate!

PCE.js

.js like JavaScript?.  YES.  I’m not kidding.  James Friend has whipped up a port of PCE to javascript!

Screen Shot 2013-11-12 at 3.39.05 PM

Complete with Macintosh, and IBM PC!

Yes, it even runs Wolfenstein 3D!

Yes, it even runs Wolfenstein 3D!

However on my 2006 Mac Pro it is VERY VERY slow.  But then again what would you expect from javascript?

It is far more heavier than jdosbox, but at the same time no pluggins!

I’m still on the fence at the moment about something as heavy as pc emulation in javascript, but it is still fun/neat!

So I was playing with Watcom C/386 8.5 today

This was the first version of Watcom that included the much beloved DOS4/GW dos extender.  Funny enough it doesn’t bind in a stub for running DOS4/GW by itself, you have to do it manually or I guess write the stub for yourself.  Another fun feature of Watcom C/386 8.5 is that it includes the win386 windows extender.

Basically it does to Windows 3.0 what DOS4/GW does to MS-DOS.  Now I’ve never messed around with win386 that much because by the time I did have a 386sx processor with more than 1MB of ram, Win32s & OS/2 2.1 were all the rage.  But in the world of VM’s I thought I’d give it a shot.

The default example is the game of life.  It compiles trivially, but the moment you got to run it you get this fine error:

Ooops!

Ooops!

It turns out that it is a timing loop error, and effects of all things Microsoft FoxPro!  The solution is provided by Microsoft, in the form of IPatchFP.exe. Naturally it is a console Win32 executable.  But with enough of the HX DOS Extender‘s runtime I can run the patch inside of MS-DOS.

With my executable all patched up, I can now run the game of life!

Conway's game of life

Conway’s game of life

Which is all very exciting.

Win386 was very cool for the time, taking the Win16 API and making their own Win32 set out of it. Another cool thing is that there wasn’t a separate runtime to repackage, as Win386 was just bound to the executable. I’m sure it didn’t fall on deaf ears at Redmond with the disillusion of Cruiser, that Win16 could have a brave new future in Win32.

And I should mention I’ve gone over a lot of the Win32s versions here.

Microsoft OS/2 2.0 SDK Beta

Something interesting crossed my desk today.  The much-fabled Microsoft OS/2 2.0 SDK beta.

OS/2 2.0 SDK in action

OS/2 2.0 SDK in action

Sadly, this does *NOT* include the operating system, just the C compiler and the SDK bits. As you can see, the C compiler is version 1.00.075, a full year+ before the WindowsNT 3.1 1991 pre-release which had 6.00.080. An interesting thing is that the C compiler can be run from 16bit OS/2.  Unfortunately, the EXE’s produced by the SDK will not run on a production OS/2 system.  The fault lies with the linker & resource compiler.  However swapping those two components out for production versions seems to remedy this and produce working executables.  The only SDK examples that don’t work correctly involve the creation of DLL’s.  I’m sure it is again related to either the linker again, or from some gem I saw in the SDK saying you should always link by ordinal, and never by name.  Apparently a bunch of function calls were going to change name from OS/2 1.2 to 2.0.  It is interesting to me that going from the old Windows 3.1 to NT days we always had so much issues with people calling by ordinal vs the function name.  It broke all the time, but it is funny to see possibly where this bad habit started.

Import and link by Ordinal? What were they thinking!?

Import and link by Ordinal? What were they thinking!?

For those who don’t know DLL’s contain a table of functions sorted by NAME, and NUMBER.  The names have to be unique but the number depends on the order in which the DLL is linked together.  And it is very easy for someone to accidentally change the link order, and next thing you know the ordinal are all wrong.

Otherwise, yeah the tools from the MS OS/2 2.0 beta working in 2013.  I do believe that the object files can also be strung together with some DOS Extenders from the era to produce DPMI exe’s.

But I’ll save that exercise for later, like here! targeting OS/2 with Visual Studio 2003!

Building Descent 1 from source

Descent I

Descent I

I never was good at this game.

As a matter of fact, I was terrible.

Apparently I get lost in 3d worlds like this, and I get dizzy and need to lie down.  Something about these kinds of 3d virtual worlds.  At least it doesn’t pertain to virtual machines.

While browsing around, I came across the source code.  From their notes they built the thing using:

  • Watcom C/C++, version 9.5
  • Microsoft Macro Assembler, version 6.1x
  • Opus Make, version 6.01

 

I was unable to find Opus Make, however with a little bit of tweaking, Microsoft nmake can happily read the makefiles.  The other small snag largely was due to MS-DOS not being able to process massive commandlines, and having to build response files to the librarian and linker in various parts.  But all in all it was thankfully a trivial amount of work to get a working executable.

I only tested it for a few minutes until I was feeling out of it again.  I guess it isn’t surprising, I had issues when it was full screen back in 1994, but in a tiny window in 2013 it is unbearable.

For the two or three people who care, here is my VMDK that I used.  It works fine with Qemu probably other emulators that can read VMDK’s.