The biggest gotcha seems to be that the MSDE/Visual C++ 4.0 studio crashes. And pinball doesn’t work. Very possible some issue with the dingus PowerMac emulator.
I’ve tried to port MAME 0.36 & Fallout1-RE, but both I’m having some DirectX issues. I’m honestly surprised MAME links. It’s getting harder and harder to find those old win32 update packages for MAME. Not sure anyone saved them?
Windows NT 3.51
And as a bonus, for those wanting 3.51, I’ve also setup a CD-ROM with SP5:
First thing to take care of, is if you have the old pcap on Windows running around. If you have it, you’ll know as you’ll get spammed with “FATAL Bad Memory Block.”, although things will continue to operate just fine.
Win10Pcap!
C:\dynamips\netware\qemu-0.90-pcap-client>qemu -m 16 -L pc-bios -M isapc -hda client.disk -soundhw sb16,adlib -net nic,macaddr=52:24:00:22:00:01 -net pcap,devicename={BFA868ED-E508-4436-B085-EC815C4C544C}
Eth: opened {BFA868ED-E508-4436-B085-EC815C4C544C}
Could not open '\\.\kqemu' - QEMU acceleration layer not activated
FATAL Bad Memory Block.
FATAL Bad Memory Block.
FATAL Bad Memory Block.
FATAL Bad Memory Block.
So be sure to dump that for the one over on npcap!
The old times, actually running Netware 3.12
There was a time when Windows NT didn’t dominate the 1990’s data centre. Instead as a carryover from the 1980’s the majority of corporate LANS were instead based on Netware. And the only way Windows NT was going to make space in this environment was to dress up in sheep’s clothes and mingle among them unnoticed. That brings us to this GEM:
Services for NetWare
This fun CD will let our NT 4.0 server emulate a NetWare server! The first thing in one of these stealth migrations was to just join the existing network.
The existing network is 0C0FFCAB
In order to do this, the two bits of information we need is the frame type, since NetWare supports so many, and the network address. In this case its 0C0FFCAB.
default IPX is no good
By default the NT server will just listen to the network, and participate on what it sees. This is fine if you are just playing along as a dynamic node, but being a NetWare node requires you to step it up, and have these values set, as it is very possible that you could be the first one (or only one) live on the network, and you don’t want clients trying to think on their own.
I also gave mine an internal network number of 1381, because you know, it’s NT 4.0.
To add the FPNW, you need to add it as a new service. Just tell it you have a disk
You’ll then have to point it to the path of the install. This is honestly the hardest part.
Selecting the first option will install the NetWare Server emulation on the NT server.
I went ahead and named my NetWare emulation as SHEEP, as I NT to blend into the existing NetWare network, with nobody being the wiser.
indeed, on our client that was already connected to the Qemu server before I built WOLF, I ran an slist command to show all the servers on the network, and there is my Wolf in Sheep’s clothes.
Creating NetWare compatible volumes is done in the Server Manager, under the FPNW option. It’s pretty self explanatory, nothing too exciting there.
The truth is during the period where this was important the NT 3.51-40 timeframe, NetWare was still a dominant force. But once Windows 95 had launched, and the explosion of people wanting MORE, the natural interest of people going to NT was just amazing to see in corporate space. While there was an early beta of the newshell for NT 3.51, when NT 4.0 shipped it was just amazing as all the reservations for running NT had just evaporated. We’d gone from hiding among the sheep to full on eating them all. It was staggering how fast we were backing up NetWare volumes to only re-format the servers to NT, and get people converted to using them. Before NT 4, the consensus was that rolling out the client config was going to be a nightmare, and that being able to emulate NetWare was the way to go, as it would just work (see the MS-DOS VM talking to NT with an unmodified NetWare client). Instead we saw a massive drive to Windows 95, which ended up changing the client landscape and upending NetWare completly.
About the most difficult thing was user mappings, there was tools to do this kind of thing, and I believe we had something to even proxy passwords, but it was easier to make people just login to the NT side.
Of course this is ONE of the emulators, you might be asking, okay, what is the other?
Why, it’s WINDOWS 95.
YES.
I’m joining the NT domain for the full experence, but the NetWare emulation relies on NetWare servers for authentication. You could use an actual NetWare server, or of course a FPNW server.
Adding file and printer sharing for NetWare workgroups under Windows 95 is done by adding a Service to the network stack. It’s even on the floppy version.
To maximize the functionality and the pain, be sure to turn on SAP Advertising. This way it’ll appear in server lists.
SAP on!
So with all of this in place, yes you can map drives from the MS-DOS client to the Windows 95 workstation acting as a server.
Mapping a drive on 95, authenticated by the WOLF hiding as a SHEEP
And there we go, I can now see the Windows 95 workstation on the SLIST, and connect and map drives. My user account of course exists on the NT side.
While professionally I didn’t rely too much on this feature, but it was nice in that era where you still had MS-DOS/MacOS/OS2 desktops with NetWare clients to quickly share stuff. But in a large organisation this would lead to major issues.
The fundamental flaw in NetWare is that there is no directory service. Instead, all the servers have to broadcast that they exist, along with what services they provide.
On my tiny demo network this isn’t that much traffic. But on a larger network that spans continents this becomes a problem. With thousands of servers there can be an incredible amount of this SAP announcement traffic. Since there is no directory service, the other problem is that when a new client is booted up, it’ll do what is known as a GNS or Get Nearest Server request in order to find the closest server to attach to, in order to facilitate a login. And EVERY server will reply.
And as you can see some servers even will reply more than once. And this can have other effects where people reboot servers during the day, something that is very natural for a Windows 95 user, which could create issues for other users, even forcing them to reboot! And yes, anecdotally I ran into this so many times where people with laptops with this feature turned on, and they would screw up the local office building (impacting hundreds of people). Even when they weren’t winning the GNS elections.they are still generating extra traffic, and occasionally they will win. This was another problem we had with all these wolves hiding in sheep’s clothing.
In the end, NetWare was utterly removed from the data center’s by the end of 1997. Windows NT just scaled too well for SMP and large disks (I had one server with 1TB! It was using 4GB disks it was massive!), along with being able to easily install stuff like SQL Server & SNA Server, unlike NetWare where any NLM conflict will bring the entire thing down. Not having a name lookup server was a giant pain, but the final nail was also in 1997 with the rise of the internet, and normal people now getting involved the entire LAN/WAN was going TCP/IP, where it had only been a fringe protocol used for managing cisco routers, and tftp/ftp some files around, Windows NT’s ability to encapsulate named pipes, and NETBIOS over TCP/IP let them embrace this new world where the TCP/IP stack on NetWare 3.12/4.11 was only good for sending SNMP alerts.
But don’t cry for NetWare, they made so much money they were able to coast for decades before being bought out in 2010 by a Mainframe Terminal Emulation company of all things, The Attachmate Group, who was later in turn bought out by Micro Focus, a COBOL language company. I guess in the end, the Mainframes won?
Years ago when I’d bought Office 4.2 for Windows NT, it only included i386 & Alpha builds of Word and Excel in the box, and a coupon for MIPS and PowerPC.
About the only thing interesting is that it actually ran under Win32s.
But today looking at term24‘s uploads on archive.org, I saw two CD-ROM images:
I quickly fired up Qemu MIPS NT, and confirmed that both do in fact contain a MIPS version! Excel does have the PowerPC version as well.
As far as I know the only RISC platform to get apps from Office 97 was the Dec Alpha, but at least MIPS users can rejoice now, knowing that they too have been blessed with 32bit Office 4.2 apps!
One of the amazing things about NT & portable apps is that visually, they look identical. So other than me telling you that these are the MIPS native versions, there really is no way to tell.
Well, other than there is no ntvdm running. There is no WOW needed here!
100% native.
I guess the only other question is that since the Word is 1994, and Excel is from 1995, did they have earlier versions for Windows NT? It seems like everything was finally coming together for RISC NT, except the users. Would a release of 64bit Windows 2000 on Dec Alpha save the platform by bringing a strong 64bit platform with integrated JIT i386 WoW built in? (AXP64 Windows 2000 didn’t use !FX32). I guess we’ll never know.
This is something that honestly deserves so much more. Back in the original scope of NT OS/2 it was going to be a C parallel of OS/2 2.00 Cruiser that had the promise of running on one of those new fangled microkernels, and those trendy RISC workstations. The 486 / Pentium were considered like the 68040/68060 to be the peak of CISC processors and from there on it was going to be a RISC world, the only question was to be which one?
Many of the Motorola customers who couldn’t afford to make their own (SUN with the SPARC), or license a school project (SGi with MIPS) were expected to use the 88000 processors that were expected to eclipse the 68040. There was an Apple initiative, and even a NeXT RISC Workstation built among many others. Only with the launch of the 88010 it was discovered performance was nowhere near expected and it’d take significant work to fix.
Back on the i386 side, Microsoft had been working with Intel on their upcoming RISC, the NTen aka i860. And just like the 88000 it too had performance issues, which resulted in Microsoft retargeting the MIPS.
Things changed along the way, and not only was the primary CPU platform dumped, but Windows 3.0 became such an incredible seller that OS/2 Cruiser was dumped from NT OS/2, and it became Windows NT. NT had been promised with the ability to run OS/2, MS-DOS, and POSIX applications, with an emphasis on Win16 and the new extended Win32 applications. However MS-DOS was super limited, POSIX was just enough to run vi & tar, Win16 was incredibly slow as it ran through WOW (Windows on Windows), and OS/2 had been kneecapped to the 16bit 1.x support as it was primarily a vehicle for running Microsoft SQL Server 1.0/4.0 . Another consequence of this is that OS/2 was command line only. In the back of deployment guides, and resource kits there was always an inference to a Presentation Manager subsystem for NT, although I’d never seen one in the wild.
Until I got a hold of a bunch of Microsoft Select CD-ROM’s that mostly were multilingual service packs of Office and Windows 98 / NT 3.51 & NT 4.0 But burred in there was a copy of Presentation Manager for NT 3.51!
First off it’s a text based install. It feels like October 1991 all over again. It installs a parallel OS/2 directory with presentation manager support.
Once it is installed it’ll setup program icons from the Windows NT side. Presentation manager runs in a separate window from the GDI. This is akin to how OS/2 would run Windows in a ‘full screen’ session. So oddly enough both support each other’s 16bit applications full screen, while reserving the desktop for 32bit applications. IBM would later introduce dual mode video drivers capable of rending Windows and OS/2 applications at the same time. Clearly Microsoft would never do this.
Launching the control panel reveals that it’s OS/2 version 1.3. No big surprise there. You can return to the Windows NT desktop either via the Windows NT icon in the bottom right, or via a Control+Alt+Delete.
The DeScribe 3 beta installs pretty smoothly into the subsystem. However running Describe is a different story:
It hangs trying to open or do anything. Even the ‘help about’ is too much. Such a pitty.
The readme warns against trying to copy the file manager from OS/2 although it does tell you what files to copy in manually. Naturally there is no ‘console’ for Presentation Manager, rather that is handled on the Windows desktop.
No doubt there had to be some big customer that demanded a way out for their investment in Presentation Manager on Windows NT. Otherwise this would have been built in. And it’s only 5 diskettes so it’s not a space issue. I suspect since it was on a Select CD, it really was not meant for wide scale distribution.
Last time I tried, Excel 3, and Word 1 had issues running on Windows NT, as the loader tried to intercept them as Win16. Things didn’t go so well. Or maybe it’s my memory. I went ahead and installed Excel 2.2 for OS/2
Despite it being text mode, it has Presentation Manager hooks, and needs PM Shell to be running. It’s a simple setup program, but yes, it’s text mode.
One nice thing about Describe & Excel is that they can see the program groups on the NT side, and create icons over there. However NT has no ability to read OS/2 resources so the icons are all incorrect.
And yes, Excel for OS/2 runs on Windows NT! Back then Excel was super expensive, this is before the big Office OEM bundles that took over the industry. So I could totally see preserving this massive investment in Excel.
Despite having 80286 emulation in the earlier versions of NT, and 80486 emulation in Windows NT 4.0 (Yes DooM runs on the MIPS!) the OS/2 subsystem was never available on the RISC platforms. I suspect had Windows 3.0 not been a big seller it may have. Then again without the big ‘rabbit out of a hat’ like DOS Extenders, Windows would have died on the vine. Who knows, maybe NT OS/2 is a thing in a parallel universe.
The following is a guest post by PA8600/PA-RISC! Thanks for doing another great writeup on that PowerPC that was going to transform the industry!.. but didn’t.
The history of the PReP platform from IBM is quite interesting, not only because of its place in the history of Windows NT but also the history of the PowerPC architecture in general. When the PowerPC platform was new, IBM (just like a few other vendors, notably DEC) had grand plans to replace the x86 PC clone market (they helped create) with PowerPC. Of course thanks to various factors such as Apple’s refusal to play along, the launch of the Pentium Pro CPU (and the later Itanium disaster), and high cost, this plan never ended up panning out. Later IBM PReP machines were designed for AIX and Linux use only, and they were sold as regular old RS/6000 computers.
Still, Microsoft being Microsoft and willing to port their OS to literally anything hedged their bets and made MIPS, PowerPC, and Alpha ports of Windows NT (along with a PC98 release for Japan only). In the guest post about Solaris for PowerPC I made, I talked about the history of IBM’s PReP platform some more so you should go read that post if you want an initial rundown on PReP’s flaws and history. But I have learned a bit about the Windows NT port for PowerPC, and I discovered a rare version of it as well. By now everyone with a PReP machine (or PPC Thinkpad) has run Windows NT 4.0 on it, and if PReP machines are emulated it’s guaranteed this will be the second most run OS on it aside from AIX of course.
IBM also made a half-baked OS/2 port for PowerPC as well, and then there’s the previously mentioned Solaris port. All of these are rarities and it’s worth documenting. With how rare PReP machines are and their high prices on eBay when they do turn up for sale (or their tendency to be snapped up fast), I think it’s fitting to write perhaps the most in depth look at PReP hardware that anyone has seen.
Windows NT 3.51: “The PowerPC Release”
It’s commonly accepted that Windows NT 3.51 was the first release for PowerPC hardware and it was even called this within Microsoft. Featuring HALs for most of the early PReP machines including the Moto Powerstack, the rare FirePower machines built for NT (which used Open Firmware), the Power Series 6050/70 (and maybe 7248), and the unobtanium IBM 6030, it’s pretty much what you’d expect for a first release for PPC. It’s a polished, solid OS that’s arguably faster than NT4 on the same machine. Aside from the red boot screen (on my Weitek GPU), it’s pretty much Windows NT 3.51 but on the PowerPC. It’s like running NT 3.51 on MIPS or Alpha, it’s interesting but more software will likely run on 4 anyhow (especially on Alpha).
One interesting quirk of Windows NT for PowerPC is it does not report the CPU type of your machine. It simply reports “PowerPC” and what machine you’re running it on. It does not tell you that you’re running it on a 601, it tells you that it’s running on an IBM-6015.
Unsurprisingly Visual C++ 4 works on PowerPC Windows NT 3.51 as well. This is no shock, Visual C++ 4 was designed to work on 3.51 as well as NT 4.0. The same goes with many of the pre compiled programs. One advantage Windows NT 3.51 offers over 4.0 is that it is simply faster than 4.0 on the PowerPC 601.
There’s not much else about Windows NT 3.51 for PowerPC quirk wise that hasn’t been said elsewhere about NT 4. It runs in little-endian mode (one of the few PPC OSes to), it has 16 bit Windows emulation that’s slow, and it needs specific PReP machines to run. One interesting series of articles about the “behind the scenes” of the port worth reading is the Raymond Chen article series, and this discusses the quirks of programming a PowerPC 60x CPU in little-endian mode as well. It can be installed with the same ARC disks NT4 uses, and of course the same SMS and firmware disks will work. In fact QEMU at one time was capable of booting the IBM firmware image from these disks.
Here’s something I’ve found out from research however. There was actually a limited release of Windows NT 3.5, it’s been dumped, and it is a real operating system. It also requires a very specific model of RS/6000 to work, and one with a interesting history giving it a unique place among the PReP machines. While I was unable to make it work in the end, I did discover and document a lot of interesting features of PReP machines.
Enter Sandalfoot: The IBM 7020/6015 (and demystifying PReP machines)
To understand the HCL and weirdness of Windows NT for PowerPC (and why it won’t run on Macs), we need to take a look at one such machine it runs on. This is my RS/6000 40p, a machine that was given several brand names by IBM and used as a development platform for PReP software and operating system ports. This is also perhaps the most historically significant RS/6000 model from the era. While it wasn’t the first PowerPC RS/6000 (that honor goes to the 250), it was the first to use the PCI and ISA busses and it was a few months ahead of both the initial PCI PowerMacs and other PReP boxes. It’s also one of the few true bi-endian machines as just like other PReP machines, the MIPS Magnum, HP’s Integrity, and modern Power8+ machines it has OSes for both endians available.
In 1994 (presumably October 28, if the planned availability date is correct), IBM released the RS/6000 40p (announcement letter here, codenamed Sandalbow) and the Power Series 440 (codenamed Sandalfoot). Both are near-identical machines with different faceplates and boot screens. The RS/6000 ranged in price from around $4,000-6,000 and was designed to be an entry-level AIX workstation, bundling a copy of AIX with each machine. As an AIX machine it’s relatively slow and fits the entry-level badge quite well, but thanks to the 601’s POWER instructions it served as a transition machine over to the later 604 AIX machines. Unlike the later PowerPC 603 and 604 machines, it featured POWER instructions allowing it to run both legacy AIX POWER software and later PowerPC software. The Power Series was presumably sold to those wanting a PReP box for Windows instead.
Since IBM PReP hardware is so obscure and undocumented, I’m going to document this as best as I can being the owner of an IBM Model 6015/7020. The machine features a 66mhz PowerPC 601 (similar to that of the Power Mac 6100 and RS6K 250), PCI and ISA slots, and IBM’s “Dakota” PReP firmware (more on the boot process here). It uses an off the shelf NCR 53c810 SCSI controller, Crystal CS4321 sound chip, an Intel 82378 PCI bridge, and a NIC can be inserted into the ISA slots (mine has the famous 3com Etherlink III). The Super-IO chip is also off the shelf, and is a National PC87312VF. The clock IC is a Dallas DS1385S, a close relative of the Dallas DS1387 (with internal battery). At least some of the IBM custom ICs are the chipset ICs and those are also documented. A Linux 2.4 dmesg can be found here.
Mine is also maxed out at 192mb of RAM, however there are some solder pads for more and the chipset is limited at 256mb. This makes me wonder if the system was based on a reference design of some sort. There was an ultra-rare 604 upgrade as well, but considering how there are more 7248 and 7043 machines in the wild I can assume many customers just waited for that instead due to its superior AIX performance.
If the idea sounds familiar (off the shelf chips + RISC CPU) it’s because it was the very same idea used to create the two other non-x86 Windows NT platforms. The Microsoft Jazz MIPS platform most MIPS NT boxes were influenced by was infamously based on the same idea of a “PC with a MIPS CPU”. To a lesser extent, this was also seen on the DECpc AXP 150 and other EISA/ISA/PCI based Alpha machines designed to both run Windows NT and DEC’s own OSes. Crazy undocumented custom hardware and expansion busses were thrown out the window in favor of industry standards. In fact when I posted a photo of the motherboard to a chat full of PC nerds, they stated it looked remarkably like a normal PC motherboard. The whole industry would later adopt PCI and sometimes ISA on non-x86 machines to cut costs and reuse the same expansion cards.
The main difference between the RS/6000 40p and the Power Series variant is the boot ROM logo and chime. The RS/6000 and “OEM” systems used a boot ROM that featured the PowerPC logo and just a beep, while the Power Series machines featured a logo more closely resembling the PowerPC Thinkpads complete with the chime. One can boot firmware from a floppy as well by typing in the name of the ROM image in the prompt and pressing enter, and watching as it reboots once the firmware is loaded into RAM. Here’s a video I filmed demonstrating this, along with some other quirks including there being two SMS keys: F1 for a nice flashy GUI SMS and F4 for a text based SMS, along with F2 for netbooting (with the right NIC of course).
The Sandalfoot machines were LPX form factor machines, featuring a riser card and generic sheet-metal case popular with prebuilt machines from this era. The LPX form factor was wildly popular in the mid 90s due to its versatility, seeing use by both IBM and DEC for their RISC machines, various PC builders, and even Apple for the clone program and clone based Power Macintosh 4400. The Sandalfoot machines also drove home one of the core goals of the PReP project, which was to build a PowerPC platform using as many off the shelf and PC style components as possible instead of using lots of custom ICs like Apple did. I dug out one of my cameras to take a few high-res photos of the motherboard of this computer to illustrate this. Compare this to the motherboard of the Power Macintosh 6100 or even the 601 based 7200 and notice the bigger heatsink and use of fewer custom ICs (Apple loved those).
There were three main GPU options: the famous S3 Vision864, the Weitek Power 9100 (or P9100 for short) as a higher end option, and IBM’s own GXT150P. The S3 was the entry level GPU and the Weitek was a higher-end and faster GPU. The GXT150P is beyond the scope of this because it is unsupported on the other PReP OSes, only AIX. The other two video cards are essentially unmodified Diamond PC cards with the BIOS chips missing.
The Sandalfoot machines are perhaps the most important PReP machines due to their role in PReP OS development. Both OS/2 Beta 1 and Windows NT 3.5 were written for this machine in particular as it was one of the first PowerPC machines to support PReP and feature PCI/ISA slots, unlike the NuBus Macs released a few months earlier or the first PPC box: the MCA based RS/6000 Model 250. They also often shipped with the well documented and emulated S3 Vision 864 video card, a common GPU family in PCs of the time to the point where it was even included on some motherboards and emulated in too many PC emulators/virtualization programs to count (notably 86box/PCem). In fact it’s successor (the 7248) featured one soldered to the motherboard.
Windows NT 3.51 was dubbed the Power PC release, because it was designed around the Power PC version of NT, which was originally supposed to ship in version 3.5. But IBM constantly delayed the Power PC chips, necessitating a separate NT release. “NT 3.51 was a very unrewarding release,” Thompson said, contrasting it with Daytona. “After Daytona was completed, we basically sat around for 9 months fixing bugs while we waited for IBM to finish the Power PC hardware. But because of this, NT 3.51 was a solid release, and our customers loved it.” NT 3.51 eventually shipped in May 1995.
I think a more accurate thing to write is that there simply weren’t many PReP boxes out in late 1994. Windows NT 3.51 supported the Motorola PowerStack series, the IBM 6050/6070 (and maybe the 7248, which came out in July 1995), and rare FirePower machines. Windows NT only features HALs for the 6015 (Sandalfoot/Power 440/RS6K 40P), 6020 (Thinkpad 800), and the 6030 (a rare IBM machine that likely was only sent to a few developers). By 1995, there were more PReP machines on the market and this made the NT 3.51 release logical. NT4 even supported a few servers, mainly the RS6K E20, E30, and F30.
Windows NT 3.5 was most likely a limited release for testing purposes on the Sandalfoot machine as it’s HCL file declares it as “Build 807” with a date of October 18, 1994. The date seems to be around a week or two before the first 40p machines at least shipped. Some more files were modified later on and the folders were created on November 9th, 1994. Hardware support is very barren, and the readme file even has a section dedicated to quirks of the 40p along with a list of supported software for the x86 emulator. This might have been considered a beta as well, as an announcement letter for the Thinkpad 800 (6020) explicitly mentions Windows NT and that this version might be a beta for developers. It also talks about a Windows SDK for it and a Motorola compiler used to build 3.5 software.
However the real problem for me has to do with getting a video card. Windows NT 3.5 for PowerPC does not support the Weitek P9100 GPU that came with many RS/6000 branded machines, and neither does OS/2 for PowerPC. It only supports the S3 Vision 864 and 928 video cards. It’s listed in the setup options, but choosing it causes a txtsetup.sif error. I’m going to assume that the development units came with the S3 video card instead. My box contained a Weitek card which works for AIX, Solaris, and Windows NT 3.51/4. I bought a card from eBay to use with NT 3.5 and the OS/2 port.
The readme also features an ominous warning with the S3 video cards, that only revision B3 is supported and that 928 cards need 2MB of VRAM for anything above 256 colors. My revision of the card I ordered was B4, so I took the risk of seeing if it worked with my system. I also removed the ROM chip as the system initializes the video card itself and that having a ROM chip can cause the system to not complete the self-test or display video. As the IBM Weitek card lacks a BIOS, I did this.
Despite the scratches on the card from possibly coming out of an ewaste pile, the card worked fine in both a PC I inserted it in for testing purposes and the IBM system. I now had a 40p with a GPU much more well supported among non-AIX or Windows NT operating systems.
Anyhow, let’s talk about the install process in closer detail here. Windows NT for PowerPC installs in a similar manner to Solaris for PowerPC on the IBM PReP machines. First the floppy disk boots ARC, then when you choose to install it the machine copies the ARC bootloader/firmware to the hard disk so it can load it from there at each boot. The floppy disk can also be used to load ARC if the loader is damaged on the hard disk. Keep in mind, on IBM machines ARC is not stored in the ROM unlike on many other ARC capable machines so this has to be done. The Firepower machines do something very similar by using an Open Firmware shim, and unsuccessful attempts at emulating PPC NT have exploited VENEER.EXE to attempt booting instead of using the IBM firmware. It fails because they’re not emulating the hardware, just trying to find a quick way to just boot NT.
Once this is done, the installer loads up and installs just like every other NT install. It checks the HAL by reading the machine ID, what video hardware the machine has, and whatnot to prepare the installer. You need a IBM 6015, 6020, or 6030 according to the HALs it has and only the S3 video cards are on the HCL.
Or that’s what should happen. I first tried using ARC 1.51 as it worked for 3.51 and was greeted with a HAL error BSOD:
I first attempted to use older ARC boot floppies and I got somewhere, the BSOD changed to the classic 07b, and then I got nothing else. Using ARC 1.48 and 1.49 gave me this, I got some i/o error with ARC 1.46 (the first 3.51 ARC floppy), and any previous ARC floppy is most likely undumped. I’m assuming either the error is due to an ARC mismatch, a weird firmware mismatch/hardware revision mismatch, or some incorrect SCSI ID Solaris style. There might very well be some weird forgotten trick to making it work (maybe a Windows expert could dig through the files and find some weirdness), but I’m going to move onto another obscure PPC rarity:
OS/2 PowerPC Boot Attempts: Beta 1 and the Final
Recently the OS/2 Museum site dumped Beta 1 for PowerPC. It’s an earlier version of OS/2 for PowerPC that insists on a Sandalfoot machine with an S3 GPU. Unlike the other OS/2 PowerPC disc, it features a verbose boot featuring the kernel it uses. If you want to really see OS/2 for PPC working, try it on a 7248 or read this post about it.
This failed to boot, throwing up an error about mounting the disk or something. I did record it doing something at least however, an improvement over the Weitek which just does nothing at the PowerPC screen. I tried several things including removing the external SCSI CD drive and that didn’t fix much. It also declares 88c05333 an unknown PCI device.
So I decided to try the “final” build. The final build requires a 6050/70, and some people did get it working on the PPC Thinkpads. I decided to see what it’d do on my machine. Unsurprisingly it did absolutely nothing but give me a blank white screen and sometimes a 00016000 error (for a trashed CMOS). If anything the 6015 loves to trash it’s CMOS contents for absolutely no reason, especially when OS/2 is involved.
Anyhow this was very anti-climatic, as the OSes I threw at it found reasons to not work on it whatsoever. I weeded out the GPU being at fault by testing Windows NT 4.0 and finding out that it works just fine with the GPU, however I seem to have fewer resolutions available than what the Weitek card allows. It did change the boot screen font, making me wonder if the red boot screen is a GPU driver quirk.
However changing the device IDs with OS/2 PowerPC Beta 1 got me somewhere, as I now got a screen about the HDD failing to write. I formatted the HDD to FAT using the ARC diskette, then I nuked all the partitions, but not much else changed. I’m not sure what the error means, but it was a letdown.
Unless these OSes require some long lost firmware, I’m wondering if there’s else that’s causing issues with installation. Either way, it was a letdown. Nothing I tried worked and I spent hours messing with everything from SCSI IDs to using different drives.
I cannot understand why you want this, or why I’m even going to do it. Â At this point in GCC history the winnt-3.5 target had been dumped in favour of going all in with Cygwin. Â So yeah, this does not either clearly configure, or compile. Â But a little bit of mashing files, and I have it at least compiling some assembly that can be translated into an object file that a later version of MinGW can actually compile.
All I’ve built is the gcc driver, the cpp pre-processor, and the cc1 aka C backend.
D:\proj\gcc-3.0.4\gcc>xgcc -c -v hi.c
Using builtin specs.
Configured with:
Thread model: single
gcc version 3.0.4
cc1 -lang-c -v -iprefix ../lib/gcc-lib/i386-winnt35/3.0.4/ -D__GNUC__=3 -D__GNUC_MINOR__=0 -D__GNUC_PATCHLEVEL__=4 -Dunix -DWIN32 -D_WIN32 -DWINNT -D_M_IX86=300 -D_X86_=1 -D__STDC__=0 -DALMOST_STDC -D_MSC_VER=800 -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D_cdecl=__attribute__((__cdecl__)) -D__unix__ -D__WIN32__ -D_WIN32 -D__WINNT__ -D_M_IX86=300 -D_X86_=1 -D__STDC__=0 -D__ALMOST_STDC__ -D_MSC_VER=800 -D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__cdecl__=__attribute__((__cdecl__)) -D__unix -D__WIN32 -D__WINNT -D__ALMOST_STDC -D__cdecl=__attribute__((__cdecl__)) -Asystem=unix -Asystem=winnt -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i386__ hi.c -quiet -dumpbase hi.c -version -o C:\Users\jason\AppData\Local\Temp\ccpflisr.s
GNU CPP version 3.0.4 (cpplib) (80386, BSD syntax)
GNU C version 3.0.4 (i386-winnt35)
compiled by GNU C version 5.1.0.
ignoring nonexistent directory "../lib/gcc-lib/i386-winnt35/3.0.4/include"
ignoring nonexistent directory "../lib/gcc-lib/i386-winnt35/3.0.4/../../../../i386-winnt35/include"
ignoring nonexistent directory "D:/pcem/building/MinGW/msys/1.0/local/include"
ignoring nonexistent directory "NONE/include"
ignoring nonexistent directory "D:/pcem/building/MinGW/msys/1.0/local/lib/gcc-lib/i386-winnt35/3.0.4/include"
ignoring nonexistent directory "D:/pcem/building/MinGW/msys/1.0/local/lib/gcc-lib/i386-winnt35/3.0.4/../../../../i386-winnt35/include"
ignoring nonexistent directory "/usr/include"
#include "..." search starts here:
End of search list. : warning: "__STDC__" redefined : warning: this is the location of the previous definition : warning: "__STDC__" redefined : warning: this is the location of the previous definition
hi.c: In function `main':
hi.c:3: warning: return type of `main' is not `int'
as --traditional-format -o hi.o C:\Users\jason\AppData\Local\Temp\ccpflisr.s
D:\proj\gcc-3.0.4\gcc>gcc hi.o -o hi
D:\proj\gcc-3.0.4\gcc>hi
Hello from GCC 3.0.4
So there you go, mysterious internet user! Â Download my source dump with binaries in the tree because I’m lazy.
Windows NT 3.51 was significant in adding support for the PowerPC processor from IBM. Â Because this release was delayed for the PowerPC port, it was very stable when it came out as over a thousand bugs had been addressed in between 3.5 & 3.51 .
3.51 was released in May of 1995 right before the launch of Windows 95.  This made NT 3.51 feel somewhat dated as it still retained the program manager/file manager feel to them, while in August Windows 95 would feature the new explorer shell.
However after the launch of Windows 95, there was work to port the new UI to Windows NT in the form of newshell.
NT Starting to look like 95
Newshell only made it to Beta 2, and was never updated beyond that.
Excel 3.0a and 97 running on NT 3.51
One cool feature of NT 3.51 is that it was supported by Office 95 & 97. Â Combined with the newshell beta it gave NT 3.51 the feeling of being more modern than the dated program manager feeling NT 3.1-3.51 …
Of my test programs, they all continue to run flawlessly. Â Even SQL Server 4.21 happily runs as a service on NT 3.51.
I figured it was worth doing a quick video of what the new shell experience was like on NT.
By this time NT was starting to look and feel like a dated system because of the reliance on Program manager. Of course we all knew it would be addressed in the next version of NT, Windows NT 4.0
So I’ve been spending the last day fighting some Active directory, and Exchange 2010 fun. I suppose if I wanted to be all new and exciting I’d document that journey. Maybe I will. But after all that fun, it had me remembering the way things used to be done, and really wondering how much further we’ve either come, or maybe…. not come.
So for the sake of it, I’m going to build out a postoffice, and connect the bastardchild of IBM & Microsoft, OS/2 to it!
How you gonna do it? PS/2 it!
So first I need to establish a server to run my postoffice on. The cool thing about MS Mail is that it could run on all kinds of things, from Novell Netware, Lan Manager, or any other file sharing network out there that MS-DOS’s lock could work with. Originally the product was for Macintoshes, before Microsoft bought it! The bad part, buried in there is that there isn’t a dedicated IPC like server, it really is a flat, shared, database. A bunch of files.
Just like MS-Access.
Really.
As luck would have it, there is a copy of MS Mail 3.5 on one of my Exchange CD’s so looking at the date, Windows NT was out at the time. So I figured for the sake of the experiment, I’d use Windows NT 3.51 . While I’ve used Windows NT 3.1 a bunch, I figured I’d try 3.51 . 3.51 came to us at a time of mass transition, when everything was going forward to Chicago (Windows 95), and the old program manager/presentation manager world was going to finally slip away.
Looking back it’s so archaic, it’s hard to believe that anyone thought progman/fileman were good ideas.
I also wanted to use Microsoft OS/2 1.3 however installing the network client causes it to trap. It does work on real hardware but that wouldn’t be quite as virtual as I wanted. Another wrench is that I’m on my Sprint access card waiting for something, and if I try to do some fun networking it disconnects me.
However I do have a workaround for Sprint’s lameness. You see “SmartView” isn’t all that smart, and thankfully it doesn’t care about interfaces *without* TCP/IP. So we take a loopback network adapter, and *ONLY* bind the Virtual PC protocol to it, by unclicking everything else..
And now we can connect our VM’s to this loopback interface. Then we could, say install an OpenBSD firewall VM that has 2 NIC’s one configured for usermode NAT, and the other on that LoopBack interface. We can now VPN to our hearts content, and even have a virtual LAN. Hell I bet you could even connect a physical Ethernet, connect Virtual PC to that as well, and plug that into a WAP. I hate it when stupid software tries to limit us, but you know… There is always a way around.
So getting back to the experiment at hand, I setup Virtual PC 2007 sp1 (making sure to tag it to a single core, imagecfg doesn’t work for some reason) and I disabled the hardware virtualization. I know OS/2 does some weird stuff with it’s LDT that most things cannot dodge, and it seems that NT 3.51 doesn’t play nice either. But no problem, luckily we can disable it.
I installed Windows NT 3.51 by first generating the 3 needed boot floppies to kick off the install. While IDE CD-ROM’s are supported by NT 3.5 & 3.51, they El-torrio boot method is not, so you need to make the 3 diskettes under MS-DOS if you’ve lost them (WINNT /OX) then you can boot off of those, and install. I setup a 2GB IDE disk, and partitioned it 512 (NTFS for NT) for C, 256 for E (FAT to swap) and finally a 1.2GB F drive to install the post office to.
Yes, the installer really is MS-DOS based. So you could run this thing on anything modern today… I would imagine even the ‘share’ hack for DOSBox could work.
Naturally we’ll create a new post office.
As I had mentioned above, I’m going to store mine on the F: drive. Don’t forget that you end up sharing out the data directory, and everyone maps it to the M: drive… If you install to the M: drive bad things happen as it expects the mail directories to be in the root… Although I guess you could just slam it in the root, but it seems… wrong.
I’ll call my post office, POSTOFFICE for the theme.
And the corporation may as well be any given MEGACORP. This was semi popular in small corporations. But it being based on fileshares meant it didn’t scale all that well. You could use special MTA’s (Mail Transfer Agents) to transmit mail from one post office to another.. We’ll get into that later.
I’m going to install with MS sharing hooks… But look a MS product that supports NetWare! Embrace, Extend & Extinguish!
I’m going to install the admin tools & agents. I don’t plan on using a modem, so scratch that!
Let’s keep the admin tools away from the users!
And let’s support MS-DOS, Windows 3.0 & OS/2. That’s right the OS/2 / Windows option is the same, that is because of WLO. This makes this one of the handful of things that shipped with WLO, (Windows Libraries for OS/2. It is a ‘port’ of the Windows 3.0 API to OS/2 as an underpinning. This was the foundation of porting Windows to NT, into Win32. Or at least that is what showstopper mentions.)
And deploy the clients to the drive that I’ll share for mail.
Everything looks good, so let’s go!
Files are copying….
And we are done!
And for the heck of it, I’m going to install the big exciting thing for Windows NT at this point, the Microsoft Mail Multitasking MTA. And it was a big deal at the time, because, naturally almost *NONE* of the other agents were multitasking (ie supported OS/2 in OS/2 mode). In fact it wasn’t un common for people to try running this stuff on Windows/386 or Windows 3.0 / 3.1 in enhanced mode with multiple MS-DOS VM’s. It was not a thing of beauty and stability. And don’t forget prior to OS/2 2.0, OS/2 could only run a single MS-DOS session, and only when it was in the foreground.
Kicking off the install.
Point it towards the mail directory.
By default the admin account it ‘admin’ and the password is ‘password’. We haven’t had a chance to change it, but those are the defaults.
I’m going to put the agent in the mailexe directory. It creates sub directories so it’s no big deal.
This isn’t a preconfigured store, so overwrite it, I don’t care.
Files copy…
Pick a group…
And we are done!
So now I’ve gone over how Sprint’s modem access is limited, and presented a way using VM’s to get around it. It’s really needed if you want to use a VPN (Virtual private network) so it is relevant to other people. Then I’ve installed Windows NT 3.51, and MS Mail 3.5 along with the MMTA. This is getting long, but in part two, I’ll setup OS/2 2.0 on Virtual PC. In part three I’ll get the network working along with some information on running MS Mail 3.5 on OS/2.
