DoomNew, is a rather ambitious project by Maraakate, to attempt to revert the old linuxdoom-1.10 to something more akin to what shipped for DooM 1.9 using Hexen/Heretic source code to fill in many of the blanks in a very Jurassic Park like manipulation of it’s DNA (source code). It’s great and gives you a very cool MS-DOS based engine using the original Watcom tools. But there is always the one catch, which is that it relies on the original sound library, DMX.
And unfortunately, nobody has been able to get ahold of Paul Radek to see if he’d be okay with any kind of open-source license. So, sadly DMX has been a long-standing stumbling block for that ‘authentic’ super vanilla DOS DooM.
Enter the Raptor
Raptor: Call of the Shadows
Fast forward to a few days ago, and I come across dosraptor on github. I had a copy of this back in the day, it was bundled on CD-ROM or something. I am absolutely terrible at games like this, but I did remember this one being incredibly fluid, and fun despite me having no skill. Raptor was written by Scott Host, and it’s still on sale over on steam! The source had been cleaned up with help from skynettx, nukeykt and NY00123.
I went ahead and built it from source, and in no time I was up and running. I found Watcom 9.5 was the best path to go with. I even made a ‘release‘ for those who don’t want the joy of building from source, and of course picked up a copy on both steam and his site. While building the source code, and looking at the directory tree that’s when I noticed apodmx:
This is a DMX sound library wrapper, which is powered by the Apogee Sound System, the latter being written by Jim Dose for 3D Realms. When used together, they form a replacement for DMX.
The DMX wrapper was written by Nuke.YKT for PCDoom, a DOS port of id Software's Doom title from the 90s.
It also includes the mus2mid converter, contributed by Ben Ryves for Simon Howard's Chocolate Doom port, as well as the PC Speaker frequency table, dumped by Gez from a DOOM2.EXE file and later also added to Chocolate Doom.
A few years later, this wrapper was modified by NY00123; Mostly to be built as a standalone library, while removing dependencies on game code.
So it turns out that Raptor used DMX, just like DooM!
Well, isn’t that incredible!
Now the first question I had, was apodmx a direct drop-in replacement for DMX? Well basically, yes! Let’s check out the Adlib driver!
DooM 1.9 introNewDoom intro
As you can hear, the intro is very different. But it’s playing at least. Ok how about E1M1?
DooM 1.9 E1M1NewDoom E1M1
The Apogee Sound System is softer, and not quite the same as DMX, but compared to nothing I’m more than happy with it. The AdLib is kind of a weird card to drive, and I guess it’s not to surprising that there is such a variance.
How about a Roland Sound Canvas?
Nuked-SC55: Roland SC-55 emulation
Sadly, mine is inaccessible, but thanks to nukeykt there is the Nuked-SC55: Roland SC-55 series emulation. I had to setup the MidiLoop as expected, and configure DosBox for the Loop and now I have a virtual Sound Canvas. So let’s see how the two engines deal with a common instrument!
Sydney’s idea of what Visual C++ for OS/2 should look like
No, it’s not a typo.
This is a long-winded post, but the short version is that I found a working combination to get the C compiler from Visual Studio 2003 targeting OS/2.
Once I’d learned how C compilers are a collection of programs working in concert, I’d always wanted to force Microsoft C to work in that fashion, however it is born to be a compiler that integrates everything but linking. There has been a “/Fa” or output assembly option, but I’ve never gotten it to do anything useful. I’m not that much into assembly but it seemed insurmountable.
But for some reason this time things were different.
This time I used:
Microsoft (R) Macro Assembler Version 6.11
After the great divorce and the rise of Windows NT, Microsoft had shifted from the OMF format to COFF. However somewhere buried in their old tools it still supports it, namely MASM. For example, if I try to run LINK386 (the OS/2 Linker) against output from Visual C++ 2003 I get his
However if I output to assembly and then have MASM assemble that, and try the linker, I’m bombarded with errors like this:
warp.obj(warp.asm) : error L2025: __real@4059000000000000 : symbol defined more than once
warp.obj(warp.asm) : error L2029: '__ftol2' : unresolved external
If I was smart I’d have given up, there is pages and pages of this stuff. But I’m not smart, so instead I decided to something different, and use SED, the stream editor, and try to patch out the errors.
The ftol2 call is for newer CPU’s and any OS/2 library won’t have it. But instead of binary editing symbols we can replace the ftol2 with ftol with this simple line:
sed -e 's/_ftol2/_ftol/g'
For some reason Visual C++ likes to make all it’s reals “public” meaning there can only be one, but yet there is so many. Why not comment them all out?
sed -e 's/PUBLIC\t__real@/;PUBLIC\t__real@/g'
And there are various other annoying things, but again they can be all patched out. Just as the older Windows 1991 Pre-release compilers also have weird syntax that MASM doesn’t understand.
astro.asm(59): error A2138: invalid data initializer
which goes into how Microsoft C used to initialize floating point constants:
This one was a little hard for me as I’m not a sed expert, but I did figure out how to mark the section, and then to replace it
sed -e "s/DQ\t[0-9a-f]r/&XMMMMMMX/g" $.a1 | sed -e "s/rXMMMMMMX/H/g"
And so on. At the moment my ‘mangle’ script is now this:
.c.obj:
$(CC) $(INC) $(OPT) $(DEBUG) /c /Fa$*.a $*.c
wsl sed -e 's/FLAT://g' $*.a > $*.a1
wsl sed -e "s/DQ\t[0-9a-f]*r/&XMMMMMMX/g" $*.a1 \
| wsl sed -e "s/rXMMMMMMX/H/g" \
| wsl sed -e 's/call \t\[/call DWORD PTR\[/g' \
| wsl sed -e 's/PUBLIC\t__real@/;PUBLIC\t__real@/g' \
| wsl sed -e 's/_ftol2/_ftol/g' > $*.asm
ml /c $*.asm
del $*.a $*.a1 $*.asm
This allows me to plug it into a Makefile, so I only have to edit it in one place.
Not surprisingly, this allows the LINK from Visual C++ 1.0 to link the MASM generated object files and get a native Win32 executable. Even from the oldest compiler I have from the Microsoft OS/2 2.00 Beta 2 SDK from 1989!
But now that we have the C compilers being able to output to something we can edit and force into a Win32, there is a few more things and suddenly:
C:\cl386-research\bin.10.6030\cl386 /u /w /G3 /O /c /Faphoon.a phoon.c
C:\cl386-research\bin.10.6030\CL386.EXE: warning: invoking C:\cl386-research\bin.10.6030\CL.EXE
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.6030 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
phoon.c
wsl sed -e 's/FLAT://g' phoon.a > phoon.a1
wsl sed -e "s/DQ\t[0-9a-f]*r/&XMMMMMMX/g" phoon.a1 | wsl sed -e "s/rXMMMMMMX/H/g" | wsl sed -e 's/call \t\[/call DWORD PTR\[/g' | wsl sed -e 's/PUBLIC\t__real@/;PUBLIC\t__real@/g' | wsl sed -e 's/_ftol2/_ftol/g' > phoon.asm
ml /c phoon.asm
Microsoft (R) Macro Assembler Version 6.11
Copyright (C) Microsoft Corp 1981-1993. All rights reserved.
Assembling: phoon.asm
del phoon.a phoon.a1 phoon.asm
msdos286 run286 C:\cl386-research\bin\ddk12\LINK386.EXE @phoon.lnk
Operating System/2 Linear Executable Linker
Version 2.01.012 Nov 02 1993
Copyright (C) IBM Corporation 1988-1993.
Copyright (C) Microsoft Corp. 1988-1993.
All rights reserved.
Object Modules [.obj]: astro.obj date_p.obj phoon.obj
Run File [astro.exe]: phoon2 /NOE /NOI /NOD:OLDNAMES
List File [nul.map]: nul.map
Libraries [.lib]: ..\..\lib2\libc.lib +
Libraries [.lib]: ..\..\lib2\os2386.lib
Definitions File [nul.def]: nul.def;
LINK386 : warning L4071: application type not specified; assuming WINDOWCOMPAT
I know it’s a bit of a word salad, but the key thing here is that using Visual C++ 2003’s compiler (version 13.10.6030), and outputting to assembly that we can edit, we can then use MASM to build objects that surprisingly LINK386 version 2.01.012 will link with. I suspect this has to do with device drivers, and probably the majority of the OS/2 operating system.
Anways, we’ve done the incredible, using the same object files, we made both a Win32 application, and an OS/2 application!
phoon-13.10.6030.exe: PE32 executable (console) Intel 80386, for MS Windows phoon2.exe: MS-DOS executable, LX for OS/2 (console) i80386
Phoon compiled by Visual C++ 2003 on OS/2 2.00
Incidentally Happy CNY!
Obviously, this is VERY cool stuff.
I know the next question is do we have to rely on a 16bit linker? How about Watcom?
C:\cl386-research\proj\trek>wlink @trek.wlk
WATCOM Linker Version 10.0
Copyright by WATCOM International Corp. 1985, 1994. All rights reserved.
WATCOM is a trademark of WATCOM International Corp.
loading object files
searching libraries
Warning(1008): cannot open LIBC.lib : No such file or directory
Warning(1008): cannot open OLDNAMES.lib : No such file or directory
creating an OS/2 32-bit executable
Ignore the warnings and YESwe can Link from something much newer & 32bit! In this example I linked the old TREK game, also built with Visual C++ 2003. The response file looks lke:
It’s probably needing additional stack space, maybe some other stuff, or resources, maybe how to flag it’s windowing compatible.
TREK built by Visual C++ 2003, and Linked using Watcom C/C++ 10.0
How do I get started, if I dare?! First download and unpack cl386-research-v2. Ideally on the root of your C: drive, because why not?
run the ‘env’ command to set your environment up. Its pretty complicated but in the proj directly there is currently:
*NOTE that I do use SED scripts, I have it set to use Linux in the WSL package. I tried some Win32 sed but it didn’t work. So you need WSL or a working sed!
and it’ll compile populate a floppy and launch the emulator
Its all good fun.
Read the Makefiles to configure a compiler, how to run it, and if you need to mangle the assembly. The 32bit new stuff needs to be mangled, the older stuff almost always works with just compile.
# Version 6.00.054 1989
# https://archive.org/details/os-2-cd-rom_202401
PLATFORM = ddksrc
In this case it’ll select the platform from the ‘ddksdk’ release. The next is if the compiler is OS/2 based or native win32. Basically 73g / windows 95 & below are native Win32.
In the above example we comment out the dos extended cross
# dos exteded cross
CC = $(EMU) $(DOSX) $(CL386ROOT)$(PLATFORM)\cl386
# native CC
# CC = $(CL386ROOT)$(PLATFORM)\cl386
Next is the mangle strategy. In this case it’s an ancient OS/2 (like) compile so try un commenting the ‘just compile’ line
# must include ONLY ONE strategey..
# for OS/2 it must have been assembled my MASM 6.11
include ..\-justcompile.mak
#include ..\-mangleassembly.mak
#include ..\-plainassembly.mak
save the makefile, and run
nmake os2
You can just close the emulator as after each run it’ll unpack a hard disk image, so nothing will be lost. or saved. It’s just for testing. You may need to periodically clean the floppy drive, as that is the only way to transfer stuff in and out of the VM.
What versions of CL386 have I found? Well, it’s quite a few, although I know I’m missing quite a few.
== c386 ============================
Microsoft C 5 386 Compiler
Microsoft C 5.2 286/386 Compiler -- Driver
@(#)C Compiler Apr 19 1990 11:48:30
Copyright (c) Microsoft Corp
1984-1989. All rights reserved.
(press <return> to continue)
Microsoft 386 C Compiler. Version 1.00.075
Quick C Compiler Version 2.00.000
1.00.075
== ddk12 ============================
C 6.00 (Alpha) Aug 24 1990 19:12:31
Copyright (c) Microsoft Corp
1984-1989. All rights reserved.
(press <return> to continue)
Microsoft 386 C Compiler. Version 6.00.054
Quick C Compiler Version 2.00.000
6.00.054
== ddk20 ============================
C 6.00 (Alpha) Aug 16 1990 23:04:06
Copyright (c) Microsoft Corp
1984-1989. All rights reserved.
(press <return> to continue)
Microsoft 386 C Compiler. Version 6.00.054
Quick C Compiler Version 2.00.000
6.00.054
== ddksrc ============================
C 6.00 (Alpha) Aug 24 1990 19:21:49
Copyright (c) Microsoft Corp
1984-1989. All rights reserved.
(press <return> to continue)
Microsoft 386 C Compiler. Version 6.00.054
Quick C Compiler Version 2.00.000
6.00.054
== nt-sep ============================
@(#)C Compiler 6.00 Feb 06 1991 17:15:19
@(#)C Compiler 6.00 May 13 1991 23:54:12
@(#)C Compiler 6.00 Jun 03 1991 15:16:22
Copyright (c) Microsoft Corp
1984-1991. All rights reserved.
(press <return> to continue)
Microsoft 386 C Compiler. Version 6.00.077
Quick C Compiler Version 2.00.000
6.00.077
== nt-oct ============================
@(#)C Compiler 6.00 Jun 03 1991 15:16:22
@(#)C Compiler 6.00 Jun 13 1991 22:07:23
@(#)C Compiler 6.00 Oct 10 1991 00:42:24
Copyright (c) Microsoft Corp
1984-1991. All rights reserved.
(press <return> to continue)
Microsoft 386 C Compiler. Version 6.00.080
Quick C Compiler Version 2.00.000
6.00.080
== nt-dec ============================
@(#)C Compiler 6.00 Jun 03 1991 15:16:22
@(#)C Compiler 6.00 Jun 13 1991 22:07:23
@(#)C Compiler 6.00 Oct 10 1991 00:42:24
Copyright (c) Microsoft Corp
1984-1991. All rights reserved.
(press <return> to continue)
Microsoft 386 C Compiler. Version 6.00.081
Quick C Compiler Version 2.00.000
6.00.081
== 73g ============================
1984-1993. All rights reserved.
Copyright (c) Microsoft Corp
8.00.3200
32-bit C/C++ Optimizing Compiler Version
Microsoft (R)
== msvc32s ============================
Microsoft 8.00.0000 - Copyright (C) 1986-1993 Microsoft Corp.
Microsoft 8.00.0000 - Copyright (C) 1986-1993 Microsoft Corp.
@(#) Microsoft C/C++ 32 bits x86 Compiler Version 8.00.XXXX
8.00.000
== 13.10.6030 ============================
Microsoft (R) C/C++ Compiler Version 13.10.6030
From my install of Visual Studio 2003 Enterprise
As you can see many of these earlier OS/2 compilers report the same versions but are in fact different builds on the inside. I suspect Microsoft had to support one version, and an Alpha version of version 6 is as good as it got. I would have imagined there were internal 32bit versions of 6 or 7, but I haven’t seen them.
Compiling and running TREK
Hopefully this gives some idea of how I tried to made a probably too modular build system to try all kinds of different compilers. I might have to see if it’s possible to run the tools from the 1992 versions of Windows NT in this setup, perhaps they are interesting as well.
One thing in my porting GCC to OS/2 experience is that the usability of the C compilers from 1991 were dramatically better than what Microsoft had given IBM at the time of the divorce. No doubt the upcoming NTOS/2 project was placing a bigger demand on the tools team.
If anyone has any access to other ‘cl386’ compilers, or early OS/2 2.00 stuff, please let me know! I’d love to do build/tests and see if my idea of distributing objects ‘just works’!
I had a small twitter account, and I tried not to get dragged into anything that would just be basically wasting my time. Just stay focused and on topic. FINE. I just wanted to see if anyone ever saw it, if it was even worth the effort of doing WIP’s as I didn’t want to make it super annoying.
I logged on to post a fun update that I’d finally gotten a Phar Lap 386 version 4.1 app to do something halfway useful, the sairen AGI interpreter up and running in the most basic sense.
Talking about DOS Extenders is spammy and manipulation!
I don’t get what triggered it, but oh well there was a ‘have a review’ and yeah that was fine. Great. So I’m unlocked so I go ahead and post with the forbidden topic, as I’m clearly dumb, and forgetting that Twitter is for hate mobs & posting pictures of food, and cat pictures.
The Sairen AGI interpreter built with Watcom 386/7.0 & Phar Lap 386 4.1
So yes, that was a line too far, and now that’s it.
Now some of you may think, if you buy ‘the plan’ you’ll no doubt be exempt from the heavy hands of Twitter
3 squids a month
But I already was and had been for a while.
Your account is suspended
So that’s the end of that. I guess it’s all too confusing for a boomer like me.
Cancel me, cancel you
So needless to say I cancelled Twitter as well. Kind of sneaky they didn’t auto-cancel taking money.
So yeah, with that out of the way, let’s continue into DOS Extender land. I added just enough 386 magic, onto github: neozeed/sarien286. Yes I see now it really was a poorly named repo. Such is life.
There is 3 main things for porting old programs where they take care of all the logic, it’s going to be File I/O, Screen I/O, and timers. Luckily this time it was easier than I recalled.
Over on usenet (google groups link) Chris Giese shared this great summary on direct memory access from various methods:
/* 32-bit Watcom C with CauseWay DOS extender */
int main(void) {
char *screen = (char *)0xA0000;
initMode13();
*screen = 1;
return 0;
}
/* 32-bit Watcom C with DOS/4GW extender
(*** This code is untested ***) */
int main(void) {
char *screen = (char *)0xA0000;
initMode13();
*screen = 1;
return 0;
}
/* 32-bit Watcom C with PharLap DOS extender
(*** This code is untested ***) */
#include <dos.h> /* MK_FP() */
#define PHARLAP_CONVMEM_SEL 0x34
int main(void) {
char far *screen = (char far *)MK_FP(PHARLAP_CONVMEM_SEL, 0xA0000);
initMode13();
*screen = 1;
return 0;
}
/* 16-bit Watcom C (real mode) */
#include <dos.h> /* MK_FP() */
int main(void) {
char far *screen = (char far *)MK_FP(0xA000, 0);
initMode13();
*screen = 1;
return 0;
}
It is missing the Phar Lap 286 method:
/* Get PM pointer to text screen */
DosMapRealSeg(0xb800,4000,&rseg);
textptr=MAKEP(rseg,0);
But it’s very useful to have around as documentation is scarce.
Which brings me to this (again?)
Phar Lap 386|Dos-Extender 4.1
Years ago, I had managed to score a documentation set, and a CD-ROM with a burnt installed copy of the extender. I didn’t know if it was complete, but of course these things are so incredibly rare I jumped on the chance to get it!
2011!
Unfortunately, I didn’t feel right breaking the books apart, and scanning them, then add in some bad life choices on my part, and I ended up losing the books. Fast forward *years* later and Foone uploaded a document set on archive.org. GREAT! As far as I can tell the only difference in what I had is that I’ve got a different serial number. Thankfully I was smart enough to at lest email myself a copy of the CD-ROM contents! And this whole thing did inspire me to gut and upload the Phar Lap TNT 6.0 that I had also managed to acquire.
Although unlocking the video RAM wasn’t too bad, once I knew what to do, the other thing is to hook the clock for a timer. ISR’s are always hell, but at least this is a very simple one:
The methodology is almost always the same, as always, it’s the particular incantation.
So yeah, it’s super simple, but the 8086/80286 calling down to DOS/BIOS from protected mode via the int86 just had to be changed to int386, and some of the register structs being redefined. I’m not sure why but the video/isr code compiled with version 7 of Watcom, but crashes. I think its more drift in the headers, as the findfirst/findnext/assert calls are lacking from Watcom 7, so I just cheated and linked with Watcom 10. This led to another strange thing where the stdio _iob structure was undefined. In Watcom 10 it became __iob, so I just updated the 7 headers, and that actually worked. I had to include some of the findfirst/next structures into the fileglob.c file but it now builds and links fine.
Another thing to do differently when using Watcom 7, is that it doesn’t include a linker, rather you need to use 386LINK. Generating the response file, as there is so many objects didn’t turn out too hard once I realized that by default everything is treated as an object.
Another fun thing is that you can tell the linker to use the program ‘stub386.exe’ so that it will run ‘run386’ on it’s own, making your program feel more standalone. From the documentation:
386 | LINK has the ability to bind the stub loader program, STUB386.EXE, to
the front of an application .EXP file. The resulting .EXE file can be run by
typing the file name, just like a real mode DOS program. The stub loader
program searches the execution PATH for RUN386.EXE (the
386 | DOS-Extender executable) and loads it; 386 | DOS-Extender then loads
the application .EXP file following the stub loader in the bound .EXE file.
To autobind STUB386.EXE to an application .EXP file and create a bound
executable, specify STUB386.EXE as one of the input object files on the
command line.
So that means I can just use the following as my linker response file.
One interesting observation is that the 386 extender is actually smaller than the 286 one. And being able to compile with full optimisations it is significantly faster.
16bit on the left, 32bit on the right.
I ran both the prior 16bit protected mode version (on the left), and 32bit version (on the right), on the same IBM PS/2 80386DX 16Mhz machine. You can see how the 32bit version is significantly faster!.
I really should profile the code, and have it load all the resources into RAM, it does seem to be loading and unloading stuff, which considering were in protected mode, we should use all ram, or push the VMM386 subsystem to page, and not do direct file swapping, like it’s the 1970s.
I’ve haven’t built the FreeDOS kernel in a while and I have to say it’s pretty easy. I’m taking the easy way out here, so I’m using OpenWatcom v2, because I figured the tools should be both at least Win32/Win64 and halfway up to date. Don’t get me wrong, MS-DOS Player is a fantastic app but I don’t want to lean on it for 100% of the build.
I configured it for something in my mind generic with the following flags:
build fat16 wc 86 win
Naturally it had issues with 3 executables, two of which are generated as the project builds, and I just did some silliness to have MS-DOS player make ‘native’ versions:
The same went for sys\bin2c.exe but it’s not rebuilt every time so it doesn’t matter.
And with that in hand it boots. YAY
And now for some absolutely unfair testing. Before anyone complains, yes this is absolutely unfair I mean hell if you bought Windows 3.1 in 2021, I guess get OS/2 or just keep digging at the yard sale and get MS-DOS. Anyways here we go:
Whoopsies!
Turning off InDOSPolling gives this lovely crash. Naturally then it’s still required.
My go-to test, Running Infocom/FASA BattleTech Crescent Hawk’s Inception in CGA mode in a Window hard locks the VM before anything is drawn to screen. Bummer. And that is pretty much the story of FreeDOS under Windows on this build. Again it’s 2021 who even needs Microsoft VDMs?
That said there must be some weird hook in MS-DOS that Win32s relies on. Just like before Win32s fails to run.
The holy trinity of ‘bad’ Windows 3.0 games, Sim City, Sim Earth and Sim Life work just as they did in the prior version, with Sim Earth instantly quitting. Not sure what is going on there. It does launch with virtual memory enabled, but then proceeds to corrupt all the file handles and Program Manager loses it’s mind. In the productivity front Excel v3, and Microsoft Word v2 run fine. Yay!
Windows 3.1 is serious business!
So in conclusion doing Win16 things in Windows 3.1 is seemingly fine.
I’ve always been fascinated with DOS Extenders, as they are such an ingenious method of breaking the rules of an environment by cheating the system. The first one I, like many others I imagine was using was DOSX that is the heart of Windows 3.0 on the 286. An incredibly tiny program but it let Windows run in protected mode, unlocking the potential of the machine. Great!
But as an aspiring programmer things were a quite a bit different. While QuickC for Windows did give you Microsoft C 5 hosted inside of Windows, effectively making the $99 for Windows and $99 for QuickC for Windows the cheapest DOS Extender dev kit of the time, it was of course limited to the 286. The 386 stuff although being the genesis of the DOS Extender was far more expensive.
But then with the advent of EMX for OS/2 and DJGPP for MS-DOS, both of them included DOS Extenders, and even better they were gratis! But of course they were GCC focused, and me being a kid saw the incredible 1MB++ size of CC1.EXE was thinking it’s insanely bloated, and of course slow. I don’t think many people were using 80386sx-16’s but I was.
Then there was this incredible offer from Watcom, who’d just become an internet (yes on usenet!) darling for being the compiler used to port DooM from NeXT to MS-DOS and it was available to students for a whopping $99. Neat!
Watcom C/C++ 10.0 retail packaging
Being in collage this was great. Another big plus of Watcom is that it was able to host on MS-DOS, Windows NT, and OS/2. And target far more!
So much included in the box!
Back then there was such incredible platform diversity in the PC space. Servers could be NetWare, Unix, OS/2 and that new fangled and often delayed Windows NT. Watcom was uniquely positioned to support so many of them, all from the same compiler set.
And of course most famously was DOS/4GW included in the box!
Despite having this, I’d always wanted Phar Lap TNT, as it brought insane features of Windows NT to MS-DOS, like DLL’s, and threads! But it was expensive, and I couldn’t justify it.
And this is where the story gets weird as I was also looking for their 286 product, and I found a copy on Ebay, and even better I easily won!
I can’t get a higher resolution image as the auction has expired out. But take note of the thumbnail.
PBI
And this happened. I was all happy expecting it to arrive when out of the blue the order was cancelled and refunded. I contacted the seller as I was totally wanting to get this, and to see if there had been some screwup in shipping, and they had told me that they didn’t know either has they had been refunded the sale price+shipping. So there we both were, me without my 286 Extender, and the seller with no disks to try to sell back again. And then this happened:
Phar Lap 286 magically reappears!
The disks showed up again for sale. We were both dumbfounded, how did this happen? Somehow someone intercepted the sale, and refunded us both, and then is trying to sell it on their own? Interestingly they won’t ship it to me, almost as if they are trying to block me from it.
Sketchy as hell as they say they are reselling from 3rd parties. Is there some kind of hustle going on where someone at a combined overseas shipping centre grabs random items, they can issue a refund for both parties so we don’t care, and then use a proxy sales site to sell them again?
Interestingly they know the disks read fine, as I know that too as I’d asked the seller to image them for me incase anything happened in shipping. I just never imagined it’d have been intercepted and resold. Maybe it’s common place, but I’ve been using Ebay since 1998 or so and well it’s the first time I’d ever seen something like this. Naturally bringing it up with Ebay is a total waste of time.
I’ll have to continue this with a deeper look into Phar Lap 286|DOS-Extender 2.5 as this is already far too much of a diversion from where I was going. But I thought I should point out this thing so buyer beware about the current listing.
**EDIT
Well seems I had the opposite effect I was looking for:
well rounding out the experiment is of course the hidden OS/2 2ine. And how does it respond to the various linkers?
Operating System/2 LX (Linear Executable) Linker
Version 2.00.000 Mar 20 1992
Copyright (C) IBM Corporation 1988-1991.
Copyright (C) Microsoft Corp. 1988-1991.
All rights reserved.
If you remember this is from the Limited Edition or Citrix Multiuser 2.0 version:
[<ohestwo>-C:\TEMP]\os2\link386 mt.obj
Operating System/2 Linear Executable Linker
Version 2.01.005 Mar 16 1993
Copyright (C) IBM Corporation 1988-1993.
Copyright (C) Microsoft Corp. 1988-1993.
All rights reserved.
Run File [mt.exe]:
List File [nul.map]:
Libraries [.lib]:
Definitions File [nul.def]:
LINK386 : warning L4071: application type not specified; assuming WINDOWCOMPAT
[<ohestwo>-C:\TEMP]mt
hi
[<ohestwo>-C:\TEMP]
and on 2ine?
$ ./lx_loader /mnt/c/msos2/test/mt.exe
not an OS/2 module
$
Well this all sucks. But how about a 3rd party linker? Watcom?!
C:\msos2\test>cl386 /c mt.c
Microsoft (R) Microsoft 386 C Compiler. Version 1.00.075
Copyright (c) Microsoft Corp 1984-1989. All rights reserved.
mt.c
C:\msos2\test>wlink d all SYS os2v2 op m op maxe=25 op q op symf @mt.lnk
C:\msos2\test>dir mt.exe
Volume in drive C has no label.
Volume Serial Number is 3C41-1D63
Directory of C:\msos2\test
13/05/2021 01:48 am 5,160 mt.exe
1 File(s) 5,160 bytes
0 Dir(s) 646,855,708,672 bytes free
C:\msos2\test>
Obviously this needs more testing on later versions of OS/2. I tried wlink from Watcom C/C++ 10.0 and it won’t run. Once more again the devil is in the linker, and just as last time, it turns out that the ‘portable’ tools are 16bit!
I found this collection recently by accident, but it’s certainly worth sharing. I was a SUPER big fan of Watcom C/C++ 10.0 back in the day as it includes not only so many targets, but also host setups making it a really great compiler for the day to target 16-bit MS-DOS, 32bit extended DOS, OS/2 16bit & 32bit, Win16, Win32, a custom 32bit Windows extender, 32bit Novel NLM’s, Autocad extensions, and no doubt many more I’m forgetting.
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.
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.
Wolf4GW
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.
