It appears that up until just now we did not have archived copy of MS Word 6.0 for PPC. There were copies floating for Alpha and MIPS, for example https://archive.org/details/ms-word60-nt. However PPC version was nowhere to be found…

Until Term24 pointed me to this eBay auction:

Since it clearly said PowerPC on the box I got it… and here it is:

Now thanks to Rairii you can enjoy it on a PowerMac or WII!

Download ISO or RAR

From Rairii:

load the registry hive setupreg.hiv from i386 folder
in ControlSet001\Services\setupdd
default registry value
at offset 8, replace the value thats there (probably 00) with 20, ie decimal 32
then when reinstalling it should set up the registry to allow 32 cpus

I didn’t want to bother trying to make a ‘correct’ NT 4 CD, so I just did the dos bootable disk image thing, and the old school “winnt /b” setup from within DOS on VMWare Workstation 17, and yeah behold!

Although I should add that it’s not all sunshine and rainbows, it fails to boot about 50% of the time with a stop 0x00000078 PHASE0_EXCEPTION. I don’t know what is up with that, if it’s my AMD processor, something with VMware…

Sadly, for anyone wondering, it didn’t help my use case. The fundamental issue being that AltaVista tries to actually use filters to interpret the data, and Microsoft Word documents with the .txt extension, or anything with 90’s L337 ascii art just straight up trip up the indexer halting all progress.

Obviously, this is building up to something else, something I think is kind of exciting, but even as a ‘distraction’ adding more cores to NT 4.0 Workstation is always a good thing!

First, I have to say it works incredibly well!

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.

For anyone wanting to follow along, I put the CD-ROM Image on archive.org:

https://archive.org/details/nt40wks-en_grackle_0.05

Along with everything needed for dingusppc:

https://archive.org/details/dingusppc

And I run it simply run it as:

dingusppc.exe -r -m imacg3 -b imacboot.u3 --rambank1_size=128 --hdd_img=2000.disk --cdr_img=nt40wks-en_grackle_0.05.iso

I did add some quality-of-life updates including:

• Service Pack 2 for Windows NT
• Internet Explorer 3.0
• Wx86 (run limited x86 binaries on PowerPC)
• Info Zip/Unzip
• Neko 98
• DooM
• Neko Project II 
• Command line Visual C++ 4.0

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:

Windows NT 3.51 Workstation for PowerPC with maciNTosh/grackle 0.05

Installation is about the same, just use the 3.x framebuffer driver.

Patreon

I also want to give a huge thanks to the fine folks over on my Patreon for helping to finance stuff like this:

With any luck, it’ll get me to a native experience, and allow for some debugging!

With all the excitement of PowerPC NT being runnable under emulation, I thought I’d try to do something fun, and port Alexander Batalov‘s fallout1-re, to Visual C++ 4.0.

The ‘problem’ is that it’s written using a more modern C that allows C++ style variables in the code. In traditional C, the declaration of variables has to be at the start of each function, however C++ allows you to place them wherever you want in the code.

The ‘fix’ is quite simple, you just have to separate the creation of variables in the code, and place them on top, as simple as!

You can see in this case the deletions in red, and the additions in green.

115 changed files with 21,455 additions and 4,437 deletions.

It was a LOT of changes. It took me 3 days to go through the code. But with a lot of work I was able to get it to compile first with Visual C++ 2003. I then created a Makefile allowing me to compile with Visual C++ 4.0

I have to admit, I was kind of surprised that it actually compiled for the PowerPC. And instantly saddened that it doesn’t actually work. Maybe some code amputations may get around the running part, but that’s just speculation right now.

Shockingly the opening animations play fine, the menus load, however you get about one frame in the game, and it goes unresponsive.

I don’t know why but Visual C++ 2003 won’t debug it correctly. I’m not sure why it won’t set the working directory correctly. Attaching to the process seems to produce different results, where it’s stuck in some loop that I can’t peg down.

Obviously, I did screw something up, the ‘solution’ is to install a newer version of Visual Studio and ‘blend’ the files, to try to rule out where or what went wrong.

The annoying thing is that even if I go through the required steps to get the VC4 version working, it won’t matter as at best this would only be relevant for the currently unemulated Dec Alpha.

Oh well, sometimes you eat the bar, sometimes the bar eats you.(yes I know it’s BEAR).

This has been a rush of excitement! Rairii published their port of the ARC & Drivers needed to get NT 4.0 working on commodity PowerMac hardware over on github. And what about running it under emulation? Once more again Rairii provided a custom fork of dingusppc, again over on github!

A custom CD-ROM worked best (for me?!) for installation, combining the ARC & Drivers, along with a copy of Windows NT Workstation onto a single disc. Rairii provided the magical recipie for creating the ISO:

genisoimage -joliet-long -r -V 'NT_arcfw' -o ../jj.iso --iso-level 4 --netatalk -hfs -probe -map ../hfs.map -hfs-parms MAX_XTCSIZE=2656248 -part -no-desktop -hfs-bless ./System -hfs-volid NT/ppc_arcfw .

And the needed hfs.map:

# ext.  xlate  creator  type    comment
.hqx    Ascii  'BnHx'   'TEXT'  "BinHex file"
.sit    Raw    'SIT!'   'SITD'  "StuffIT Expander"
.mov    Raw    'TVOD'   'MooV'  "QuickTime Movie"
.deb    Raw    'Debn'   'bina'  "Debian package"
.bin    Raw    'ddsk'   'DDim'  "Floppy or ramdisk image"
.img    Raw    'ddsk'   'DDim'  "Floppy or ramdisk image"
.b      Raw    'UNIX'   'tbxi'  "bootstrap"
BootX   Raw    'UNIX'   'tbxi'  "bootstrap"
yaboot  Raw    'UNIX'   'boot'  "bootstrap"
vmlinux Raw    'UNIX'   'boot'  "bootstrap"
.conf   Raw    'UNIX'   'conf'  "bootstrap"
*       Ascii  '????'   '????'  "Text file"

I went ahead and made the image, and added in Service Pack 2, Internet Explorer 3 and IIS3 onto the same CD-ROM to make things easier for me to deal with. It’s on archive.org.

On Discord and impromptu porting session broke, out and we got NP21 up and running!

Unfortunately, it is very slow. I have no idea how it performs on real hardware, it’s entirely possible that it really is unplayable. It’s still pretty amazing that the OS booted up and I could actually compile something!

Even the usual fun text mode stuff from Phoon, Infocom’87, F2C, compiled!

But will it run DooM?

Of course, it runs! I’m using the 32bit C code from Sydney (ChatGPT), which runs just great.

Into 3D space

I was able to compile GLuT on the way to try to build ssystem but there is two textured OpenGL calls missing, meaning that the more fun OpenGL stuff simply will not work.

Setting expectations

As a matter of fact, lots of weird stuff doesn’t work, the install is very touchy so don’t expect a rock-solid experience, but instead it was incredibly fun to try to get a bunch of stuff up and running.

Thanks again to @Rairii for all their hard work! This is beyond amazing!

— it’s 3am and I’m exhausted, but I had to share this out some how some way!

NT ON PowerPC! It’s happening!

When the AXP64 build tools for Windows 2000 were discovered back in May 2023, there was a crucial problem. Not only was it difficult to test the compiled applications since you needed an exotic and rare DEC Alpha machine running a leaked version of Windows, it was also difficult to even compile the programs, since you needed the same DEC Alpha machine to run the compiler; there was no cross-compiler.

As a result, I began writing a program conceptually similar to WOW64 on Itanium (or WX86, or FX-32), only in reverse, to allow RISC Win32 programs to run on x86.

The PE/COFF file format is surprisingly simple once you get the hang of it, so loading a basic Win32 EXE that I assembled with NASM  was pretty simple – just map the appropriate sections to the appropriate areas, fix up import tables, and start executing.

To start, I wrote a basic 386 emulator core. To complement it, I wrote my own set of Windows NT system DLLs (USER32, KERNEL32, GDI32) that execute inside of the emulator and then use an interrupt to signal a system call  which is trapped by the emulator and thunked up to execute the API call on the host.

For example, up above, you can see that the emulated app calls MessageBoxA inside of the emulated USER32, which puts 0 in EAX (the API call number for MessageBoxA) and then does the syscall interrupt (int 0x80 in my case), which causes the emulator to grab the arguments off of the stack and call MessageBoxA.

To ease communication between the host’s Win32 environment and the emulated Win32 environment, I ran the emulated CPU inside of the host’s memory space, which means that to run applications written for a 32-bit version of Windows NT, you need a 32-bit version of win32emu (or a 64-bit version with /LARGEADDRESSAWARE:NO passed to the linker) to avoid pointer truncation issues, to prevent Windows from mapping memory addresses inaccessible by the emulated CPU.

To get “real” apps working, a lot of single-stepping through the CRT was required, but eventually I did get Reversi – one of the basic Win32 SDK samples – to work, albeit with some bugs at first. Calling a window procedure essentially requires a thunk in reverse, so I inserted a thunk window procedure on the host side that calls the emulated window procedure and returns the result.

After this, I got to work on getting more complicated applications to work. Several failed due to lack of floating-point support, some failed due to unsupported DLLs, but I was able to get FreeCell and WinMine to work (with some bugs) after adding SHELL32. I was able to run the real SHELL32.DLL from Windows NT 3.51 under this environment.

One might wonder why I put all this work into running x86 programs on x86, but the reason is that there’s the most information about, and I’m most proficient with, Windows on the 386. Not only does Windows on other CPUs use other CPUs, but also there’s different calling conventions and a lot of other stuff I didn’t want to mess with at first. But this was at least a proof-of-concept to build a framework where I could swap the CPU core for an emulator for MIPS or PPC or Alpha or whatever I wanted and get stuff running.

Astute readers might be wondering why I didn’t take the approach taken by WOW64. For those who don’t know, most system DLLs on WOW64 are the same as those in 32-bit Windows, the only ones that are different are ones with system call stubs that call down to the kernel (NTDLL, GDI32, and USER32, the first of which calls to NTOSKRNL and the latter two calling to WIN32K.SYS). WOW64 instead calls a function with a system call dispatch number, which does essentially the same thing. The reason for this is that the system call numbers are undocumented and change between versions of Windows. WOW64, being an integrated component of Windows, can stay up to date. If I took this approach, I’d either have to stay locked to one emulated set of DLLs (i.e. from NT 4.0) and use their system call numbers on the emulated side, or write my own emulated DLLs and stick to a fixed set of numbers, but either way I’d somehow have to map them to whatever syscall numbers are being used on the host.

As I went on, I should probably also mention that what I said earlier about loading Win32 apps being easy was wrong. Loading a PE image is pretty straightforward, but once you get into populating the TEB and PEB (many of whose fields are undocumented), it quickly gets gnarly, and my PEB emulation is incomplete.

Adding MIPS support wasn’t too much of a hassle, since the MIPS ISA (ignoring delay slots, which gave me no shortage of trouble) is pretty clean and writing  an emulator wasn’t difficult. The VirtuallyFun Discord pointed me to Embedded Visual C++ 4.0, which was invaluable to me during development, since it included a MIPS assembler and disassembler, which I haven’t seen elsewhere. After writing a set of MIPS thunk DLLs and doing some more debugging, I finally got Reversi working.

There’s still some DLL relocation/rebasing issues, but Reversi is finally working in this homebrewed WOW!

I’d encourage someone to write a CPU module for the DEC Alpha AXP (or even PowerPC if anyone for some reason wants that). The API isn’t too complicated, and the i386 emulator is available for reference to see how the CPU emulator interfaces with the Win32 thunking side. An Alpha backend for the thunk compiler can definitely be written without too much trouble. Obviously, the AXP presents the challenge that fewer people are familiar with its instruction set than MIPS or 386, but this approach does free one from having to emulate all of the intricate hardware connections in actual Alpha applications while still running applications designed for it, and I’ve heard the Alpha is actually quite nice and clean. MAME’s Digital Alpha core could be a good place to start, but it’ll need some adaptation to work in this codebase. Remember that while being a 64-bit CPU with 64-bit registers and operations, the Alpha still runs Windows with 32-bit pointers, so it should run in a 32-bit address space (i.e. pass /LARGEADDRESSAWARE:NO to the linker).

Theoretically, recompiling the application to support the full address space should enable emulation of AXP64 applications, since the Alpha’s 64-bit pointers will allow it to address the host’s 64-bit address space, but I’m not sure if my emulator is totally 64-bit clean, or if the AXP64’s calling convention is materially different from that on the AXP32 in such a way that would require substantial changes. In either case, most of the code should still be transferable.

I also want to get more “useful” applications running, like development tools (i.e. the MSVC command line utilities – CL, MAKE, LINK, etc.) and CMD. Most of that probably involves implementing more thunks and potentially fixing CPU bugs.

This project is obviously still in a quite early stage, but I’m hoping to see it grow and become something useful for those in the hobby.

For those who want to play along at home, you can download the binary snapshot here: w32emu.zip

A more complete version of the writeup is available here: https://bhty.github.io/og/win32emu_VirtuallyFun_Post.htm and you can find the project here https://github.com/BHTY/Win32Emu/.

Preparing for Windows NT RISC Exhibition for VCFW 2023, I wanted to have Windows NT running on an IBM RS/6000. This was previously covered in this excellent article by Shoutmon as well in this a video by NCommander. However both are missing some crucial information that I had to go through and learn myself the hard way. I hope it will help someone in the future.

Windows NT PowerPC was designed to run on PReP machines. Which of the RS/6000 models are REeP is coincidentally answered by NetBSD/prep supported system models.

Firstly there are “IBM PC” Power Series. Yes IBM PC but with PowerPC CPU, and not to be confused with RS/6000 which is a different IBM product. However the IBM Power Series have equivalent RS/6000 “counterpart” models. WTF IBM.

IBM PC Power Series 440 6015 == IBM RS/6000 Model 7020 40P
IBM PC Power Series 830 6050 == IBM RS/6000 Model 7248 43P
IBM PC Power Series 850 6070 == IBM RS/6000 Model 7248 43P

There are also other models mentioned by Windows NT 4.0 HCL, namely E20, E30 and F30, and PowerPC ThinkPads. To summarize here is a more definitive list of IBM RS/6000 models supported by Windows NT 4.0:

Model 7020 40P
Model 7248 43P
Model 7043 43P-140 (with a big asterisk)
Model 7024 E20 and E30
Model 7025 F30
ThinkPad 820, 850
ThinkPad 860 (with a big asterisk)

Important: 7043 43P-150 is CHRP and will NOT run NT!
43P-140 = PREP NT OK
43P-150 = CHRP NO NT

If you could pick any RS/6000 machine, the 40P would probably be the most recommended. 40P can also run OS/2 PowerPC, if you are in to this thing.

Unfortunately all I had on hand was 43P-140, which is PReP, but it’s not Power Series based and not supported by NT out of the box. WTF IBM. Also WTF is 7248-43P and 7043-43P. Chances are that you will run in to this as well as 7043 43P-140 are way more popular and easier to acquire than any other hardware listed above. 43P-140 semi regularly pop up on eBay for decent prices.

The main trouble with 43P-140 is that the onboard GPU and NIC will not work with ARC and NT. Yes, you can hack in some generic S3 card. It will work in ARC/NT but not for PROM and AIX. I wasn’t happy. Upon some collaboration with Shoutmon and NCcommander and my own research, I was able to find the one and only graphics card that will work in both the RS/6000 PROM as well as ARC BIOS, AIX and Windows NT. The lucky winner is:

IBM FRU 40H5838 aka GTX110P

Update: It’s been tried, tested and verified to use IBM ROM with a regular/stock S3 Trio64V+. You can download it here and program yourself. It will work with both AIX and NT.

Also I have came across FRU 93H7983 for GTX110P. Not verified.

As for the NIC, there are way more options as it’s not used by PROM, ARC or AIX, just NT. In my case I opted for a standard Etherlink III card.

Windows NT Installation

Once you have the correct hardware bits, NT installation is pretty straightforward with some caveats. You start by booting the ARC 1.51 floppy disk. Then you need to go to Installation and Setup Services, Advanced Installation and then Disk Partition Management Services.

There are 3 types of partitions. Confusing, skipping on creating or trying to merge them in to one partition will not get you far.

• Boot (ARC) Partition – aka PowerPC Boot partition. This is where ARC loader will be copied from the floppy, so you can boot ARC directly from HDD without the floppy disk. Has nothing to do with Windows NT.
• System Partition is a small FAT partition where \os\winnt\osloader.exe will reside.
• OS Partition is a large FAT or NTFS partition that will have \WINNT folder.

First you create the Boot (ARC) Partition and copy data from ARC floppy disk to the ARC Partition on the hard disk. This will allow booting ARC firmware directly from HDD. At this point you may want to remove the floppy disk, reboot, get to SMS and change boot device to HDD.

Secondly go to FAT Data or System Partition. Make it small like 5MB, then answer Yes to System Partition. This will create the partition for osloader.exe. This is an equivalent of arcinst.exe on Alpha and MIPS. Arcinst is not present on PPC.

Note that OSLOADER is on SYSTEMPARTITION. The OSLOADPARTITION is where \WINNT folder is located.

Or you can just select Standard Setup which will do everything for you.

Lastly go back to the main menu and select Run Maintenance Program. Then type cd:\ppc\setupldr. Once Windows NT setup boots, you will have an unpartitioned space left. create the Windows NT partition, preferably as NTFS and continue with install as normal.

Installation on PowerPC ThinkPads, specifically the 860 is covered here.

I hosted a Porting Party last where where I setup my Dec Alpha as a terminal server allowing people from all over the world to connect in and cross compile software for the 64bit version of Windows for the Dec Alpha. While many problems were overcome, and many more remain, I have to say the most annoying thing was joining a domain hosted by a SAMBA server.

In my mind, I though the easiest way to get files in & out of the Alpha was not to use something like IIS/FTP where it would probably lead to end-less issues with text/binary/active/passive modes, but rather I should rent a VPS, install the OS default SAMBA and just map drives. The benefit of the VPS is that it has a public address, so no NAT is required. The VPS had an option for either CentOS (no) or Debian 10. I went with the Debian, and did an in place upgrade to 11, then 12. Nothing special.

I’d never actually used SAMBA as a domain controller before, but I thought this would be a fun experiment. So the idea is then that the VPS running SAMBA is the Domain Controller, and my Alpha joins it as a member server. Everyone else can use Windows or any SAMBA client and map drives, and then copy files to the VPS, and then copy back and forth from the Alpha to the VPS. This part worked fine.

What didn’t work was SAMBA version 4.

I had come up with this config, based on the fragments of the default config, and and hints from samba.org.

[global]
    netbios name = PDC
    passdb backend = tdbsam
    server max protocol = NT1
    username map = /usr/local/samba/etc/username.map
    workgroup = ALPHAPARTY
    server string = Samba Server
    security = user
    hosts allow = 127.0.0.1, <<<peoples networks...>>>
    load printers = yes
    log file = /usr/local/samba/var/log.%m
    max log size = 50
    passdb backend = tdbsam
    local master = yes
    os level = 33
    domain master = yes
    preferred master = yes
    domain logons = yes
    wins support = yes
    dns proxy = no
    add user script = /usr/sbin/useradd %u
    add group script = /usr/sbin/groupadd %g
    add machine script = /usr/sbin/adduser -n -g machines -c Machine -d /dev/null -s /bin/false %u
    delete user script = /usr/sbin/userdel %u
    delete user from group script = /usr/sbin/deluser %u %g
    delete group script = /usr/sbin/groupdel %g
[homes]
    comment = Home Directories
    browseable = no
    writable = yes
[printers]
    comment = All Printers
    path = /usr/spool/samba
    browseable = no
    guest ok = no
    writable = no
    printable = yes
[public]
    comment = share for everyone
    path = /public
    public = yes
    writable = yes
    printable = no
    creaet mask = 0777

I had endless issues with the machine account not being either created correctly or not being authenticated. I tried manually creating it, to no avail. No matter what I tried it didn’t work.

Working with NT 4.0 must be depreciated or something but no matter what I tried IT JUST DIDN’T WORK.

Feeling outraged, I purged the old Samba, downloaded the source code to 3.6.25, built that, and using the same configuration I had tried to put together, it just worked.

Adding users was somewhat straight forward:

useradd -M -s /bin/bash neozeed
passwd neozeed
/usr/local/samba/bin/smbpasswd -a neozeed
/usr/local/samba/bin/smbpasswd -e neozeed
mkdir /home/neozeed
chown neozeed /home/neozeed/

Creating both a Linux user & directory, and the SAMBA credentials. On the terminal server, all that remains was assigning a local home directory & profile directories, as you really don’t want those over the WAN.

I have no idea if this is a warning to others, or whatever the larger issue is.

Porting Party II

At any rate I’ll be running another porting party this coming weekend. I can host cross compiling fine, but we need people with the 64bit Whistler beta installed to test. The best way to get details is over on discord. Lately the IRC bridge is down more than it’s up, and I can’t effectively send out passwords & get your network block to allow access to the RDP, since I’m not going to open up worldwide access to a Windows NT 4.0 SP5 machine.

So for anyone interested in porting their C/C++ to either the 32bit Alpha Windows, or 64bit Alpha Windows come join us on discord!

I’ll fire up the Alpha on Friday afternoon GMT and expect the event to run all weekend!

I want to have an internet server that people can map drives to, for copying data in/out for the upcoming Dec Alpha AXP64 building extravaganza! I wan tot use my Dec Alpha for building since it’s got a gigabyte of RAM. One of the hard parts is that NT 4 is beyond obsolete, and twice as much on the DEC Alpha. I was figuring renting a VPS, and using it as a SAMBA server so people can simply map a drive from home, copy files to the VPS, terminal server to the Alpha, and copy files to & from the internet. Easy right?!

I was non stop getting this error:

System error 1326 has occurred.

Login failure: unknown user name or bad password.

Except I knew the username & password was correct.

The key part involved a few parameters to get it working. Although many people reported success by simply setting the protocol level, for me I had to set that and the lanman/ntlm auth to yes. Trying to enable NT4 compatible encryption didn’t work either.

[global]
   workgroup = WORKGROUP
   server min protocol = NT1
   client min protocol = NT1
   lanman auth=yes
   ntlm auth=yes

I’m not sure if it’s all that helpful to the world at large, or if it’s just super common knowledge, but I haven’t setup SAMBA in like forever. I guess I could go one further and join it to the domain but that doesn’t seem like it’s all that needed or all that smart.

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!

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:

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.

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.

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.

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.

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?