So the floors and ceiling render, but the walls are all screwed up… so close!
If you remember a while back, I had found the ‘missing link’ of Wolfenstein to Wolfenstein SDL, Wolf4GW. Well Tobias has cleaned it up somewhat, and now it compiles on the latest builds of OpenWatcom 2.0c!
The first thing you’ll notice if you try to compile it, is that now it’s a single source file, that includes all the other modules. And it compiles FAST, for me 1 second fast.
From the changes:
- Compiles with OpenWatcom v2.
- Keys (for Run, Shot…) are shown.
- Hang with optimization is fixed.
- Missing Spear of Destiny SignonScreen added.
- Inter-procedural optimization (unity build).
- External assembler routines re-implemented in C.
- Better interrupt enablement /disablement.
- Dead Code removed or #ifdefined.
So, if you want to Wolf3d, or SPOD, I’d check out Tobias’s Wolf4GW if you have a 32bit capable machine. The maps load instantly, and it just feels all around much more smoother than the old 8086 code.
I know what you are thinking, wouldn’t it be great if you could create MS-DOS executables directly from a Win64 desktop with no MS-DOS needed?
Well, I just found out about this unofficial Open Watcom v2 project that targets the usual suspects, allows you to compile from Win64!
Some of the features of this fork include:
- New 2-phase build system, OW can be build by platform native C/C++ compiler or by itself
- Code generator properly initialize pointers by DLL symbol addresses
- DOS version of tools now support long file names (LFN) if appropriate LFN driver is loaded by DOS
- OW is ported to 64-bit hosts (WIN64, Linux X64)
- Librarian support X64 CPU object modules and libraries
- RDOS 32-bit C run-time compact memory model libraries are fixed
- Resource compiler and Resource editors support WIN64 executables
- OW text editor is now self containing, it can be used as standalone tool without any requirements for any additional files or configuration
- Broken C++ compiler pre-compiled header template support is fixed
- Many C++ compiler crashes are fixed
- Debugger has no length limit for any used environment variable
Binaries are available on sourceforge.
So how does it fare? I thought I’d take the old Wolf4GW, and compile it with this toolset. The first hurdle I hit was this fun feature:
- The C++ compiler now treats warning W737, implicit conversion of pointers to integral types of same size, as an error.
Which is an integral part of wl_menu.cpp . So this was somewhat problematic, until I just commented out that block, and while I was expecting no working keyboard, I’m able to play, and load/save games…. Even the boss key works.
So with the W737 taken care of, I have to say this thing compiles FAST. Incredibly FAST. If for some reason you have to build 16bit or 32bit anything, you should look at a 64bit tool chain, well assuming you have a 64bit computer by now.
If anyone want’s to build their own Wolf4GW with the newer OpenWatcom, my source drop is here.
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:
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!
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.
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.
So, I came across this project from some random google search on Watcom the other day. Simply put it is a MS-DOS API that is supported in both a 16bit real mode operating system, and a 32bit operating system. It is quite sparse but very interesting all the same. Using the ancient EMX port of GCC you can build 32bit (simple) programs, and run them in the 32bit DOS like Operating System. What makes this even more interesting is that there is a port to the IBM 370, and 390 based hardware, along with the fictional 380.
You can download my diskimages, (VMDK & floppy disk) that I’ve used with Qemu to build & boot PDOS both 16bit and 32bit.
The included libc & system libraries are lacking compared to real MS-DOS, but this is public domain code, and with a bit of TLC it could be made into something much more.
After reading about the Blake Stone compile fixes, as it was a Wolf3d port, I came across a post on the forum Wolf3d Haven about trying to find the source code to something called wolf4gw. Now wolf4gw is a port of the Borland C source of Wolfenstein 3d to Open Watcom C++‘s 32bit MS-DOS extender DOS/4GW, done by ‘ripper’.
The project eventually gave way to wolf4sdl, and as they say the rest is history.
Sadly it seems that just about all the source copies of wolf4gw were lost, except I did manage to find an ‘improved’ version simply refered to as wolf3dx. From the blurb:
Tricob has released the Wolf4GW-based source code of WolfDX. Included is a text file called (Tricob).TXT.
So I have been using Watcom 10.0 for Duke Nukem 3d, however, this version relies on the _asm inline assembler which was introduced in Watcom 11. However Watcom 11c had issues with some of the assembly forcing me to go even further to OpenWatcom 1.3. For me the install was easy, I used CrossOver to install OpenWatcom for DOS-DOS32bit only, copied the compiler into DOSBox, and played mostly with the makefiles, and finally got a working exe!
I know it may not look like much, but really it is running in 32bit protected mode!
Since all of this is open/freeware/shareware I can redistribute OpenWatcom, the source to wolf3dx, and the shareware levels of Wolfenstein. Naturally I’m using DOSBox to compile and test, but you can use anything that can run MS-DOS 32bit stuff.
Download my archive here.
Well most of it anyways….
I mashed in all you need to build it for MS-DOS under MS-DOS here.
It should be really simple, just run the Watcom C’s setvars, then go into the duke3d\source directory and run ‘wmake’ … All being well it’ll output some exe’s. I’ve also included the shareware data files so you can test your executables.
Not bad for being under 10Mb, compressed.
My package from Germany finally arrived…!
And it contains Phar Lap 386 versions 4.1 and 5.0!
But something arrived in the mail. So I spent 2 hours cleaning things up and fighting with Watcom getting a skeleton verison of Doom to build. It’s finally running. Now to do some keyboard/video stuff.
Maybe more later though. But I may have to bench them some how Dos4G/W vs Phar Lap 386…. I donno.
The things I see go through my blog… Well someone googled that (blogger.com shows me top hits, on what people search, and how they got here).. and I have to admit it made me laugh.
But my exposure to Watcom really didn’t start until I was in college, and I found some $99 offer to buy Watcom 10.0 CD only package. At the time I thought it was super exciting, because it not only included 32bit tools, but also the 16bit stuff. At the time, I still had a 286 running OS/2 so for me this was awesome!
So for my $99 I got a 32bit MS-DOS,OS/2,Windows NT & Novell Netware compiler, along with a 16bit MS-DOS, Windows & OS/2 compiler.
Ok, so that’s the ‘good’. All the documentation was online, which was ok, but it was in like 30 different files…. The UI was weird, but really in the early 1990s everyones UI was odd. Heh even Microsoft ended up taking over the UI from QuickC for Windows as their ‘professional UI’.
Now what of the Watcom Legacy? Well sure we all know that the iD software guys, used Watcom as their 32bit compile to ship DOOM to the MS-DOS world. Just as 3D Realms used it for Duke Nukem 3d!. But I’d suspect this was mostly because of the DOS4G/W DOS Extender, and it’s royalty free redistribution with Watcom C++. From what I understand Pharlap TNT was *VERY* expensive to license, with regards to it’s royalty price.
Also at the time, Watcom C++ was the fastest compiler available.
But time and competition wasn’t kind to Watcom. Eventually the language company slipped, was purchased for a side product sold off and killed. It’s kind of funny that a language company that produced a SQL server as a necessity ended up being the only product that people sought, and didn’t want to let discontinue.
So sure Watcom C/C++ was a great compiler for it’s time, but the time has passed. In the meantime we are lucky that it’s been open sourced so it hasn’t faded off to oblivion.
Although the C/C++ is what people know them for most, Watcom had a lot more, as seen in their source, they did have support for the Dec Alpha. also did have a Fortran compiler. Back a long long time ago, this Waterloo Ontario based company used to supply computer languages to all kinds of Canadian endeavors. It’s a shame that us kids never got to really see them, but rather it was more so for research as I’m lead to understand.
So really what separated Watcom from say Microsoft? Maybe it was their proximity to research? Maybe government contracts? Perhaps reluctance to enter the operating system business? I don’t know it’s really hard to say, I’m sure it’d make an interesting documentary but I’m afraid the audience would be pretty small.
But then again the Canadian government does like to green light this kind of thing, so maybe someone out there will take it up.
At any rate, I’m sure others may want to chip in on how they feel about Watcom.
I see now that the phrase actually comes from doom
‘!’, // shift-backslash – OH MY GOD DOES WATCOM SUCK
This is in the heads up code, hu_stuff.c
So I guess that ends that eppisode.