from the netbios-over-ipx-was-infact-a-thing dept.
So at it turns out, being cooped up due to COVID-19 causes your local resident NCommander to go on a retro computing spree. Last time, I dug into the nuts and bolts of Hello World for Windows 1.0.. Today, the Delorean is ready to take us to 1993 — the height of the "Network Wars" between Microsoft, Novell Netware, and many other companies competing to control your protocols — to take a closer look at one of Microsoft's offerings: Windows for Workgroups
As with the previous article, there's a YouTube video covering most of the content as well as: a live demonstration of Windows for Workgroups in action, my personal experiences, and the best startup chimes of the early 90s.
If the summary doesn't make you relive all those General Protection Faults, then slip past the fold to see what all the hubbub was about for Windows for Workgroups compared to its younger brother, Windows 3.1.
The Windows 3.1 Family Tree
The 16-bit family tree of Microsoft Windows can be a tangled beast, especially when we get to the topic of Windows for Workgroups. You may have noticed I haven't used it's more common version number: Windows 3.11. That's because there was, in fact, a free-standing Windows 3.11. In truth, the following all existed at one point or another:
- Windows 3.1
- Windows for Workgroups 3.1
- Windows 3.11
- Windows for Workgroups 3.11
For clarity sake, if I speak of Windows 3.1, I'm speaking of the original release, while Windows for Workgroups (WfW) refers to the final release unless I specify otherwise.
The versioning and numbering is extremely misleading. At the earliest end of the chart clocking in from 1992 is the basic Windows 3.1 that most users are more familiar with. Windows 3.1 required an 80286 or better, and had no integrated network stack (although one could be added). When people are talking about 16-bit Windows, this is generally the version most people are referring to. Operation on an 80386 would bring Enhanced Mode which brought better performance and the possibility of 32-bit applications to consumer Windows.
Windows for Workgroups 3.11 meanwhile emerged mid-1993 and supplanted the original release. Requiring an 80386, this version brought 32-bit driver access and boasted faster performance and better stability. In addition, Workgroups 3.11 came with built-in networking support in the form of Microsoft's homegrown Windows Socket implementation with IPX/SFX, NetBIOS, and ARCnet included on the installation disks. TCP/IP was available as a free add-on.
Having had to pop open the kernel debugger due to system crashes (also detailed below), I can tell that Windows for Workgroups 3.11 is far closer to Windows 95 than it might appear at first glance and many of the foundations of what would become the 9x series of Windows would be laid here instead of being introduced with Windows 95 as is commonly believed.
That leaves the two remaining versions, Windows 3.11, and Windows for Workgroups 3.1.
Windows 3.11 is something of a mystery to me. The freestanding upgrade has been archived, and I even went as far as to install it to examine differences. In short, I found one:
Notably, Windows 3.11 still supported the 80286 and Standard Mode, and still brands itself as Windows 3.1 on the installer and splash screen. As such, it's actually a distinct kernel than the later WfW 3.11. This, of course, leaves the last version on the list: Windows for Workgroups 3.1.
As for Windows for Workgroups 3.1, what I can tell you is it was a bundled copy of Microsoft Windows 3.1, and Microsoft Workgroups Add-on for Windows which still primarily depended on DOS for networking and notably also supported the 80286. This might not sound like a big deal, but Windows for Workgroups actually played a starring role in bringing both networking and eventually Internet connectivity as something we take for granted as a part of the operating system.
The Windows Socket API
Some broader context is needed to understand the implications here. As far back as PC-DOS 3.x, the need for networking support in the base operating system was well understood. PC-DOS 3.1 formally introduced the network redirector API, a mechanism where add-on software could attach network drives to DOS. The network redirector API was so well designed that it was later (ab)used for various non-network devices such as MSCDEX to provide CD-ROM support for DOS and Windows.
What DOS didn't provide however was a standard network API. Instead, Novell, IBM, Microsoft, Sun Microsystems, and many other companies provided their own packet interface and network stacks through a variety of APIs that were mutually incompatible. Microsoft itself has its own hat in the ring, its LAN Manager Server for OS/2, and Microsoft Workgroups Add-on for DOS.
Initially, this wasn't a problem. Most shops would have a single network (and of those, most commonly Novell NetWare) and set of programs. Windows 1.0 and 2.0 furthermore ran in real mode, which meant that Windows applications could simply talk to DOS APIs without a middle man. Problems began to emerge with Windows 286/386/3.0.
Internally, Microsoft was beginning to move towards Protected Mode. While the 80286 had a crippled ability to use memory above 1 MiB, 640 kilobytes was clearly becoming cramped. With OS/2 still struggling and Windows NT still far from shipping, Microsoft began to pivot on extending the useful lifespan of DOS-based Windows by embracing the then-new world of 32-bit computing. By having the core of the operating system running in Protected Mode, Windows could theoretically use up to 4 GiB of memory with each application having a 16 MiB chunk to itself.
Networking was also becoming more important in corporate environments. Ethernet (both in thicknet and thinnet), and Token Ring came out as front runners, and Novell's IPX/SFX competed with TCP/IP used on UNIX workstations. IBM and Microsoft meanwhile were backing NetBIOS for use on small LANs while supporting NetBIOS-over-IPX and NetBIOS-over-TCP in larger corporate networks.
Something was going to have to give, so Microsoft, in cooperation with Sun Microsystems and JSB Software, collaborated to write the Windows Socket API; it was later and more commonly known as Winsock. The intention of Winsock was to give Windows a standardized mechanism of interfacing with network cards (NDIS), network protocols, and programming interfaces. In short, the ability to embrace all the competing network technologies at once.
Windows 3.1 was the first version that could support a Winsock stack natively, but Microsoft didn't provide one in the box. Instead, Microsoft initially left this entire market to third-party developers, leading to one of the most pirated pieces of software of this era: Trumpet Winsock
Many other vendors and even ISPs shipped their own versions of Windows Sockets which powered the first Internet applications on Windows 3.1. For example, AOL for Windows became notable on the basis that it provided Winsock and gave those enjoying dial-up the ability to use applications like Netscape Navigator. This is in contrast to CompuServe and Prodigy Classic whom gave you their own walled gardens. CompuServe would eventually embrace the standard PPP protocol via the famous !go pppconnect to join the broader Internet.
Although most vendors simply shipped TCP/IP, a few vendors supported their own Layer 3 protocols, including DEC whose PATHWORKS product included full support for DECnet on Windows!
That state of affairs was going to change. With the famous Microsoft-IBM divorce of the 90s, OS/2 wasn't going to become the operating system of the future — the DOS-based versions of Windows got an unexpected stay of execution. Microsoft had developed its own version of Winsock which had premiered on Windows NT with support for IPX and NetBIOS standard, as well as a BSD STREAMS derived TCP/IP stack.
Windows for Workgroups 3.11 was Microsoft's first widely-distributed, network-enabled Windows. Although most home users had little use for it, it also would prove a widespread technological test. Windows for Workgroups 3.11 would mark the start of using 32-bit components in a fundamental way.
Compared to the rest of the system, the network stack was entirely 32-bit. Known as Shoebill, its internal implementation of the Windows Socket API was ported from Windows NT. Existing as a set of 386 VxD drivers and userland libraries, Shoebill would be the first version of Winsock shipped in the box for home and small office users. Internally, Shoebill provided the NDIS3 interface, a standardized model for writing network card drivers. NDIS has continued to be supported by Microsoft, and incidentally is the same technology used to allow Windows network drivers to be used by Linux and FreeBSD via ndiswrapper.
In the context of the era, Windows for Workgroups 3.11 was also an important stepping stone. More notably, it was the first major real-world test of thunking, a technology Microsoft used to support 16-bit and 32-bit Windows side by side for decades. While the home user may have not gotten much from Windows for Workgroups 3.11, it was an important milestone of what would become Chicago, and then Windows 95.
It would normally be at this point I'd start showing demonstrations of this cutting edge technology, but before we get there, I need to detour into the nightmare I had in actually getting Windows for Workgroups running.
Interlude: General Protection Hell
Under normal circumstances, I like to use VirtualBox for running older versions of Windows, DOS, and Linux as it has excellent compatibility with the especially oddball systems like Xenix. It also has the ability to do internal networking and NAT Networks which avoid the pain of having to setup and configure TAP.
Furthermore, VirtualBox emulates an AMD PCNet PCI card, and works correctly with Super VGA modes so I could easily get high resolution and networking support in one easy package. I also knew Windows for Workgroups ran successfully as I had used it for testing the Windows 1.x binaries.
One problem: Windows suffered an EIOIO error and bit the farm when I installed the networking stack.
In truth, I didn't actually even get that far initially. Windows would just crash to a flashing cursor, and creating a bootlog gave me an empty file. All I knew was I was going belly up very early in the startup process. Some googling suggested that this was a problem with VirtualBox 6.1 removing the ability to run without Intel VTx, which had shipped on Ubuntu 20.04. The problem was more subtle than that, but I initially accepted it and tried other emulators.
My next GOTO was QEMU, but I had more problems here initially. Instead of a PCnet card which needs an add-on, I choose to emulate the more common and compatible NE2000 card whose drivers were shipped on the Workgroup disks. This sorta worked, but I kept getting lockups in both DOS and Windows. I eventually traced the lockups to the fact that QEMU's NE2000 by default sits on IRQ 9. This is a sane default for ISA based machines, but any PC with PCI uses IRQ 9 for the PCI bus. As such, the network adapter and the emulated PCI backplane conflicted and lead to lockups.
Annoying, support for ISA mode in QEMU (-M isapc) appears to have bitrotted out of the codebase, and I couldn't convince QEMU to move the NE2K card to a different interrupt or iobase. QEMU does, however, support the RTL8189 and the PCNet card, the latter of which I eventually got to work successfully. Of course, it wasn't that simple. My initial full system hang was replaced with GDI packing it up.
Trial and error showed that this was a problem trying to run networking combined with more than 16 colors at the same time. I would eventually determine that by using a Super VGA 800x600 16 color driver partially solved the issue. I could get Windows usable, but I still had screen corruption artifacts on startup. I could, fortunately, get around these by forcing the screen to redraw.
At this point, I was getting rather frustrated, and so I resorted to desperate measures. How desperate?
Desperate enough to setup a DEBUG build of Windows which in and of itself was its own set of fails.
Throughout the 16-bit era, it wasn't uncommon to have to use two computers (or at least a serial terminal) to DEBUG crashes as it was common for a system crash to take out the entire operating system. I alluded to this in Windows 1.0, but I honestly didn't expect to go down the rabbit hole of trying to setup a debug build of Windows to check under the hood. My first stop was Visual C++ 1.52 which was the last 16-bit version and included the Windows 3.1 SDK.
Setting up a debug build of Windows is a bit of an experience. Replacement files for core system are shipped in the SDK in the aptly named DEBUG folder, and the scripts n2d and d2n can convert your release to Windows from RELEASE to DEBUG and back. Furthermore, there were WIN31 and WIN311 folders. Perfect. Or so I thought.
As it turns out, the debug Windows kernel, win386.exe is not included on the disk. Without it, I couldn't get any useful debug information out of Windows. Some Googling pointed me to the Windows 16-bit DDK. This had a version of the debug WIN386 but Windows tapped out saying it couldn't load VMM and VMD when I tried it. A quick look at the dates made it clear that this WIN386.EXE was for Windows 3.1, and not for Windows for Workgroups.
At this point, I decided to use my "Phone a Friend" lifeline and called Michal Necasek curitator of the OS/2 Museum. Long time readers of SoylentNews might remember him from my Xenix rebuild series. Michal was able to point out to me that the necessary bits I needed were shipped as part of the free-standing Windows 3.1 SDK.
Much more disk searching later, I finally got my hands on the DEBUG kernel, and I could boot to Program Manager with the /N switch. Setting up an emulated serial port gave me some basic debug messages, but didn't give a clear hint on why we were going belly up.
WARNING: Device failed to initialize (DDB = 80060800) VPD BAD FAULT 0000 from VMM! Client Frame: AX=00100000 CS=0028 IP=80299DFF FS=0030 BX=80481000 SS=0030 SP=000000B0 GS=0030 CX=00000000 DS=0030 SI=80402090 BP=8004CE78 DX=00000000 ES=0030 DI=54006001 FL=00010246 WARNING: About to crash VM 80481000. FATAL ERROR: Attempt to crash System VM Windows protection error. You need to restart your computer. Windows/386 kernel reentered 0000 times Critical section claim count = 000186A0 VM handle = 80481000 Client pointer = 8004CE78 VM Status = 00000000 Stopped while VM executing OOOOPPPPSSSS! V86 CS = 0000. Probably not valid! BAD FAULT 0008 from VMM! Client Frame: AX=00000000 CS=3202 IP=00000000 FS=0000 BX=00000000 SS=0030 SP=00002600 GS=0000 CX=00000000 DS=0000 SI=00000000 BP=00000000 DX=00000000 ES=0000 DI=00000000 FL=0000036A Setting VM specific error on 80481000, error already set GetSetDetailedVMError WARNING: About to crash VM 80481000. FATAL ERROR: Attempt to crash System VM
At this point, I needed to use the WDEB386 kernel debugger. Now, I've worked in software engineering for over a decade. I've dealt with crappy programs, shitty debuggers, and much more. I've had the dubious honor of having to run "gdb /usr/bin/gdb". I thought I was immune to "shitty vendor software" surprises.
I wasn't.
I feel like I need to quantify this. The previous "world's worst debugger" prize had belonged to GNU HURD's mach kernel debugger which was so terrible, I was more productive with putting inline assembly breakpoints and printf than actually using it to debug anything. WDEB386 stole the show.
The first part is WDEB386 is not well documented, and its built-in help is very bare-bones. What little documentation I could find related to using it on Windows 95. Almost every USENET post ended with a sentence like "Use SoftICE." This was an encouraging first sign. More warning signs cropped up when I had to apply a hex patch to run WDEB386 as it refers to Intel's removed tr6 and tr7 registers, which causes most vintage debuggers to tap out. Unlike most debuggers, symbol files have to be manually loaded one-by-one as line switches, and I ran into DOS's command-line limit. Even OS/2's debugger was less bad than this. In short, the amount of symbols isn't limited by memory, but how short your file paths are.
Secondly, WDEB386 wants a DOS PC or something very close to it on the other end. No amount of terminal fiddling could get it to properly recognize keypresses. PuTTY, which normally is "close enough" to work was better, but I still couldn't execute multicharacter commands.
At this point, I had already figured out a set of QEMU settings that worked to film my video. At this point, I should have realized I had already opened pandora's box. Instead, I doubled down.
This wasn't exactly an ideal solution to the problem, but it got the job done. I also managed to get actual crash messages, at which point WDEB386's terribleness struck further. I couldn't get a stack trace out of it, and I had trouble setting breakpoints.
Unlike most other debuggers, WDEB386 actually depends on the Windows kernel to give it hints of what modules are loaded and VxD operations. It's more of a command-line for the debug kernel. As such, most of the "extended" commands failed; I couldn't use .VM to see what, if any, drivers had loaded, and the message BAD FAULT 0000 sent me down another rabbit hole.
Through experimentation, Michal and I determined that Windows was tapping out somewhere in NDIS.SYS. My original theory was conflicts relating to the PCI bus, but I was able to reproduce the crash with the Remote Access Service Serial Driver and no network driver. Furthermore, forcing Windows to use a real mode driver also averted the crash.
Eventually Michal realized that BAD FAULT 0000 wasn't the debugger reporting a null pointer exception. Instead, it was an Intel processor exception code! What was the exception?
Divide by Zero.
Michal was able to isolate this to a timing loop that tries to determine the number of milliseconds between operations. As it turned out, my desktop runs so fast that when combined with VT-x, the whole thing goes *bang*. We haven't worked out a binary patch for the issue, but at least we know where and what the root cause is, and it shouldn't be THAT hard to fix for someone with a version of IDA that can disassemble linear executables.
The lesson that needs to be taken away from this is that while Intel platforms have outstanding backwards compatibility, a lot of legacy software has bugs when running on hardware tenfold faster than what they were designed for. A lot of full PC emulators like PCem have limited support for emulating network cards, and it's becoming harder and harder to document these legacies of the past.
Anyway, having segfaulted my way back to the original topic, let's actually get down and dirty with Windows for Workgroups 3.11!
The First Click of Your Networking Experience
Now, if you were lucky, you didn't have to install the debug build to actually experience Windows Networking. Assuming you're one of the anointed few, the network setup application is your key to the best of early 90s networking. Simply click the icon, insert your floppy disks, and away you go.
What isn't obvious though what's missing. The first quirk comes from the fact that TCP/IP (as previously noted) is nowhere to be found. This actually wasn't a big deal back in 1993. At the time neither RFC1918 network space nor DHCP existed, so (properly) setting up TCP/IP networking involved calling ARIN/RIPE/etc. and getting a Class C network or three. IPX is instead used as the default transport, primarily because it's both plug and play, and almost all network equipment of the era could easily route it. For those who needed it, TCP/IP was available as a download on ftp.microsoft.com free of charge.
Secondly, Shoebill had almost no support for dial-up networking. As such, the Network group would be an oddity for most home users. We'll come back to that later though.
The next step was getting QEMU TAP networking sorted. I'll spare you my pain and misery and just leave a Wireshark trace showing that we were infact talking on the network, complete with NetBIOS over IPX.
After Network Setup does its thing, we're left with a Network group with a lot of icons, and some additional functionality throughout the operating system.
Your Network Aware Windows 3.1 Applications
Network Setup actually does quite a bit under the hood. First, it sets up PROTOCOL.INI and sets up the "For Workgroups" product to be able to run under DOS. One thing that isn't well documented is that you could actually run the networking parts of Windows independent of Windows. This still uses real mode drivers, and I suspect is identical to Workgroups for DOS.
Once setup though, many applications gained a large variety of network aware options that were previously hidden. File Manager gained file sharing and network drive functionality that is very close to what shipped in Windows 95. Print Manager likewise got the same upgrade. A few less obvious ones were that Clipbook Viewer now allowed you to share Clipbooks between users. This used NetDDE and essentially acted liked a shared network database. It only worked while the application was open, however.
Hearts, which also appeared in this version of Windows, could be played with three other players over the network. The application was called "The Microsoft Hearts Network" to emphasis this fact.
Most of this functionality persisted across multiple Windows versions, although as of Windows 10, only the file and printer sharing has more or less survived as-is. Of course, though, we still have a large suite of applications to look at though. As a note, because I was working across multiple machines and some of these screen shots are from my original Twitter thread, the colors vary depending on which machine I was using at a given time.
Microsoft Mail
Microsoft Mail itself is an interesting topic that it will likely get its own video and article at a later point. As the name suggests, it is a simple mail client application capable of LAN email. Originally, Microsoft Mail was an independent product for DOS, Windows, Mac, and OS/2. The version shipped in Windows for Workgroups 3.11 was a stripdown version that only supported Windows, and the entire product itself would eventually morph into Exchange. As a bit of trivia, this is why the first version of Exchange was 4, as the previous Mail release was 3.2.
On a fresh installation, Microsoft Mail asks if you wish to create a Workgroup Postoffice. This is a shared mail database written to the file system. The idea is that the postoffice is shared across the network, and clients could directly read and write to the post office. That also meant Mail could be used with a NetWare server, or any product that could map network drive.
That being said, since that functionality was included in the default install, inter-office mail was entirely possible with just Windows for Workgroups 3.11 by itself with no additional add-on software. For communication with other systems, a daemon called EXTERNAL was available for OS/2 which could bridge Mail to UUCP networks and more standard SMTP. This was not tested for this article.
Rather notably, passwords are shown in the clear. In truth, there's no actual security in this product as any user could access the shared mailbox directory and download all the mail on the server. Preferences also have an interesting radio box for selecting your security level:
I leave it to the readers to comment on why this is such an inane switch!
Moving on, user mailboxes could be stored locally or on the backend server, and the Mail client easily allows one to move from place to place. This is especially important if multiple users were using one computer as they all end up sharing a single MMF mailbox on a local disk.
Once setup, the software is simple enough to use, although it's slightly quirky compared to modern clients as mail is only sent and received on timed intervals and I sometimes had to close and re-open the client to get it to actually work. Setup on a client machine is equally straight forward, with one simply needing to select the network share the WGPO folder was shared on.
A global address book and mailing lists are also available. All this functionality was also integrated into our next program, Schedule+. Finally, once setup, Mail would add an icon to File Manager's toolbar, allowing you to easily attach files. (The toolbar itself was also added in this version of File Manager).
Schedule+
Rather hilariously, Schedule+ suffers from a Y2020 problem, so I had to turn back the system clock to use it at all.
Once reality had been suitably rewritten, Schedule+ fired up without issue. Integration with Mail is quickly apparent as it immediately prompts to log into your Mail account, although it is possible to use Schedule+ in a local-only mode.
Schedule+ supported creating invites and had an integrated messaging function that worked off the Network Postoffice. Notably, these messages weren't showed in Mail at all, making meeting invites a bit haphazard. Other users' schedules could be shared and loaded off the postoffice, suitable for secretaries to be able to manage and manipulate their boss's schedule.
For a product of this time, Schedule+ has a fairly elaborate access control function. I've heard rumors that Microsoft used Schedule+ pretty extensively in-house, so this feature probably existed to help prevent developers from deleting meetings they didn't want to attend.
Beyond that, I really don't have much to say. It's a scheduling app. As a standalone application, it was included until Office 97 entirely absorbed it into Outlook.
The Other Bits
Remote Access
Remote Access is the only application I can't actually demostrate as it requires a working modem. In short, it let you dial into a LAN Manager, Windows NT, or Windows 95 server and run NetBIOS applications between the two machines. Note that I didn't say network applications. Remote Access only supported the NetBIOS protocol, so it was useless for accessing the Internet even if a TCP/IP stack is installed.
Net Watcher
NetWatcher, as the name suggests, gave you a look at the network stack on your machine. It could show whoever was connected to your PC, as well any files they had an exclusive lock on. If enabled in the control panel, the Event Log could also be viewed here to see who had accessed your machine as well as a record of last startups and shutdowns.
Log On/Off
I don't even have a good screenshot for this one. Log On/Off was the dedicated utility for signing in and out of the network; this is the login asked for by Windows at startup and not shared with Mail or Schedule+. Windows Network logins were primarily used by WinPopup and also were used for accessing authenticated shares on LAN Manager and Windows NT machines (Windows 3.1 only supported a global password for sharing).
WinPopup
Ah, the great annoyance of the 90s and early 2000s. WinPopup is a simple broadcast message facility, that could send a message to a user, computer, or an entire workgroup all at once. This feature survived in one form or another until Windows XP, when the then-named "Messager Service" was disabled by default, and removed entirely with Vista.
Compared to later versions, this version comes with a GUI interface and also does not run by default. It has to be enabled to do so in the Network control panel.
Chat
Chat on the other hand is a keyboard to keyboard chat application. It acts more like a TTY device or the old school UNIX talk application that keyboard input is relayed in real-time. Like other programs, it needs to be open to actually work on both computers.
WinMeter
WinMeter finally tops out our collection of Windows for Workgroups 3.11 applications with simple performance statistics.
In Conclusion
Windows for Workgroups provides a fascinating look at the dawn of the office network. While Windows wouldn't wrest control of the market from Novell for several more years, a lot of what we take for granted first appeared here, and many of the core technologies of Windows 95 first debuted in this oft-forgotten page of Windows history.
Windows for Workgroups was also one of the major instances of Microsoft beginning to incorporate the functionality of its competitors directly into the base product. Just like DR-DOS and MS-DOS, Windows for Workgroups gave you everything Personal NetWare did for no added charge. This behavior would eventually lead to the anti-trust suits of the later 90s, albeit over the inclusion of Internet Explorer instead of network and file-sharing capabilities.
As my emulation stories show, we're also beginning to lose the ability to virtualize and run these ancient versions of Windows (and other software) due to emulation bugs and the onward march of technology This emphasizes the importance of documenting this technology while we still can. There's still plenty to cover, so if you liked this article, give my video a like, subscribe (either to my channel or SoylentNews, both are appreciated!), and let me know your thoughts below!
I've got another topic in the works, so I'll leave you with this teaser screenshot to tide you over until the next time!
73 de NCommander
P.S.: Since recording the video and doing this write-up, I've come to learn that Windows for Workgroups 3.1 (not 3.11) actually has some notable changes. This is likely due to being based on the Microsoft Workgroup Add-on for Windows instead of the NT based Shoebill. I may come back to this topic and re-address it, especially if I can get my hands on the add-on.
Related Stories
One of my favorite hobbies is both retrocomputing projects, and the slightly more arcane field of software archeology; the process of restoring and understanding lost or damaged pieces of history. Quite a while ago, I came across the excellent OS/2 Museum, run by Michal Necasek which helps categorize many of the more obscure bits of PC history, including a series of articles about Xenix, Microsoft’s version of SVR2 UNIX.
What caught my attention were two articles talking about Xenix 386 2.2.3c, a virtually undocumented release that isn’t mentioned in much if any of the Santa Cruz Operation's (SCO, but see footnote) surviving literature of the time. Michal documented [1], [2] his efforts at the time, and ultimately concluded that the media was badly corrupted. Not knowing when to give up, I decided to give it a try and see if anything could be salvaged. As of this writing, and working with Michal, we’ve managed to achieve approximately 98% restoration of the product as it would have existed at the time.
I’m going to write up the rather long and interesting quest of rebuilding this piece of history. I apologize in advance about the images in this article, but we only recently got serial functionality working again, and even then, early boot and installation has to be done over the console.
* - SCO in this case refers to the original Santa Cruz Operation, and not the later SCO Group who bought the name and started the SCO/Linux lawsuits.
Read more past the fold.
For those who've been long-time readers of SoylentNews, it's not exactly a secret that I have a personal interest in retro computing and documenting the history and evolution of the Personal Computer. About three years ago, I ran a series of articles about restoring Xenix 2.2.3c, and I'm far overdue on writing a new one. For those who do programming work of any sort, you'll also be familiar with "Hello World", the first program most, if not all, programmers write in their careers.
A sample hello world program might look like the following:
#include <stdio.h>
int main() {
printf("Hello world\n");
return 0;
}
Recently, I was inspired to investigate the original HELLO.C for Windows 1.0, a 125 line behemoth that was talked about in hush tones. To that end, I recorded a video on YouTube that provides a look into the world of programming for Windows 1.0, and then testing the backward compatibility of Windows through to Windows 10.
For those less inclined to watch a video, my write-up of the experience is past the fold and an annotated version of the file is available on GitHub
On what is becoming a running theme here on SoylentNews, we're reliving the early 90s, and picking up right where I left off from Windows for Workgroups, it was time to look at the 800-pound gorilla: Novell NetWare.
Unlike early Mac, UNIX and Windows, I didn't actually have any personal experience with NetWare back in the day. Instead, my hands were first guided on a stream of my weekly show, HACK-ALT-NCOMMANDER, hosted as part of DEFCON 201, combined with a binge reading marathon of some very hefty manuals. In that vein, this is more of my impressions of what NetWare user and administration is like, especially compared to the tools of the day.
Ultimately, I found NetWare a very strange experience, and there were a lot of pluses and minuses to cover, so as usual, here's the tl;dr video summary, followed by more in-depth write-up.
If you haven't ABENDed your copy of server.exe, click below the fold to learn what all the hubbub was about!
As promised, here's the round-table discussion post that I said on Wednesday was coming. We have a long history at SoylentNews of listening and responding to our community; I genuinely hope that never changes. I also recognize that I may have ruffled some feathers in the last few weeks with original content postings so here's the best place to get this all out.
I am mindful of the community's support and goodwill; I don't want to squander any of it. Yes, there are times where my hand may be forced (e.g., DCMA takedowns). Still, I'm always a bit hesitant whenever I post on the main site for anything that isn't site update news or similar. I may be the de facto site leader, but I want my submissions to be treated like anyone else's — I want no favoritism. The editorial team does review my stories and signs off before they go live (unless it's an "emergency" situation such as the last time we blew up the site). However, as the saying goes, the buck stops with me.
SoylentNews accepts original content. I'm also aware that I've probably submitted the most original content so far (See "Previously", below for some examples). I'm grateful for the community's apparent acceptance of my submissions and the positive responses to them. What I don't know is if there is an undercurrent of displeasure with these. Maybe everyone thinks these are all fine. Then again, maybe somebody has an issue with them. Rather than assume anything, let's get it all out in the open.
What I want to cover in this round-table discussion is original content and having images in posts as well as topics such as yesterday's Live Show on Improving Your Security -- Wednesday June 3rd, 2020.
So, contributors and commenters to SoylentNews, get that Reply button hot and let me hear your feedback. As usual, either a member of staff or I will respond to your comments below,
73 de NCommander
Previously:
(2020-06-03) Live Show on Improving Your Security -- Wednesday June 3rd, 2020
(2020-05-24) Retrotech: The Novell NetWare Experience
(2020-05-14) Exploring Windows for Workgroups 3.11 - Early 90s Networking
(2020-05-10) Examining Windows 1.0 HELLO.C - 35 Years of Backwards Compatibility
(2020-05-15) Meta: Having a Chat about SoylentNews' Internet Relay Chat
(2018-10-25) My Time as an ICANN Fellow
(2017-10-09) soylentnews.org experiencing DNSSEC issues
(2017-04-20) Soylentnews.org is Moving to Gentoo...
(2017-04-17) SN Security Updates: CAA, LogJam, HTTP Method Disable, and 3DES
(2017-03-13) Xenix 2.2.3c Restoration: Xrossing The X (Part 4)
(Score: 4, Funny) by Snotnose on Tuesday May 26 2020, @03:08PM (17 children)
At the time I was sysadmin for a network of Suns, with disk partitions NFS mounted willy nilly with no issues. My Windows counterpart spent hours trying to network the Windows boxes only to teach me new ways to swear.
Fun times.
When the dust settled America realized it was saved by a porn star.
(Score: 4, Insightful) by NCommander on Tuesday May 26 2020, @03:16PM (11 children)
What's sorta sad is the Sun set the standard for UNIX filesharing by porting NFS to everyone, and never really profitted from it. The fact that Oracle bought the corpse of Sun Microsystems was just insult to injury.
Still always moving
(Score: 2) by RamiK on Tuesday May 26 2020, @06:08PM (8 children)
Don't get too sympathetic with Sun. They and the rest of the UNIX wars critters were gouging prices and screwing everyone over to the point they made Microsoft and Apple look like the good guys: https://books.google.com/books?id=TcSgWR-qLh8C&pg=PP56 [google.com]
On the technical side, it hardly benefited UNIX standardizing on a piece of big-server legacy tech at an era when NetWare Lite was doing P2P storage in '91 while Plan 9 first edition came out in '92 doing distributed everything. In fact, it's the sort of crap that won Microsoft the desktop.
compiling...
(Score: 3, Interesting) by NotSanguine on Tuesday May 26 2020, @07:10PM (7 children)
As I recall, Sun/SGI/IBM/HP/DEC all had expensive UNIX workstations that couldn't compete on price with commodity ISA hardware.
While SCO/MS (XENIX) and other commercial vendors were selling X86-based UNIX for that same commodity hardware. Not to mention the fairly weak (at the time) Linux distros (Yggdrasil, Slackware, etc.) as well as FreeBSD.and BSD/386.
Given the mediocre (if at all) X11 GUIs (and the extra cost) on the X86-based Unices, it's not surprising that Windows was the consumer/office desktop of choice.
Novell had the chance to to maintain their server side dominance for several years, as WFW/NT3.1/3.5/4.0 networking continued to lag in performance and interoperability. And NDS (1993) was a functional directory service in production more than six years before Microsoft released Active Directory.
Microsoft saw their chance and put together a large team whose *only* task was to make Windows file sharing faster than Netware. This was confirmed to me directly by a working developer on the Windows team.
What's more, developers preferred the Windows platform as they could develop on the same platform their code ran on.
This was not the case for Netware. Developing NLMs for Netware was both more complicated and required significant additional infrastructure for development, testing and deployment.
Had Novell ported Netware/NDS to Unix starting in 1993 when they bought Unix Systems Labs, they could have continued to own the server market, and Unix would likely have been the server platform of choice, with Windows relegated to the desktop -- although at the time, Windows on the desktop might not have been assured either.
In the end, Novell failed to execute and gave Microsoft the time to get near enough to in terms of functionality and performance (but definitely don't discount the ability to develop on the hosting platform -- that made a huge difference for the growing application server ecosystem) to make Novell an also-ran.
Novell's missteps hurt all of us, sticking us with crappy networking, poor manageability and poor reliability.
By the mid 1990s, Unix was mature, with a stable, scalable (unlike LANMAN) networking stack, strong management via NDS and a mature, stable development platform.
Novell's failure to capitalize on this handed Microsoft the dominant position they held in the server market, dooming other superior products like WordPerfect as well.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by RamiK on Tuesday May 26 2020, @09:50PM (1 child)
The '89 news piece I've linked specifically discusses the sun386i workstations that were introduced following Sun's failure with MIPS boxes back in '89. To spoil the 30yr/old punch line, it was priced at $8-12k.
Nah. Servers aren't iPhones. The demand for high-end mature servers selling at a premium just wasn't there. Otherwise some other players would have filled in the market niche where they didn't.
compiling...
(Score: 2) by NotSanguine on Tuesday May 26 2020, @11:13PM
Absolutely. In fact, Isn't that what I said?
That was true for M68000, SPARC *and* x86 Sun boxen.
In fact, I had a Computerworld subscription at the time. I don't remember that particular article (it was 30 years ago), but I do remember Sun's x86 offerings and didn't understand what the market for it might be.
I was also herding M68000 and SPARC-1 boxes (running SunOs 4.0.x as I recall) at the time too.
No. In fact, *Netware* ran on the same hardware that Windows server did, starting with NT 3.1/3.51/4.0/2000 Server. Or rather I should say that when Microsoft released a "server" OS, it ran on the same hardware that Netware did. That was the demand for those servers then. Well, that and OS/2 server and cc:Mail and Lotus Notes and database servers (often running as NLMs on, you guessed it, Netware).
Netware, as I stated was the dominant player there, and it wasn't until late NT 3.51 and 4.0 that Microsoft even got a whiff of success with that, and they didn't have real success in that market segment until Windows 2000 Server (1999).
Uhhh...I just said that too. Microsoft (for a variety of reasons which I clearly specified) filled that niche when Novell couldn't or wouldn't execute on creating a true application server by porting Netware/NDS to *UNIX*.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by NCommander on Wednesday May 27 2020, @12:23AM (4 children)
I don't normally call bullshit, but I need to this in this case. NetWare is a steaming turd both architecturally, and Novell lost the market because they declared their product "feature complete" in the 80s, and it wasn't until NT 3.5 was already on the market that Novell Directory Services came out with an inflating price tag. NDS pain was compounded that it couldn't interop well with Bindery; you had to basically copy the old bindery to a new server, disable the old one, and pray to go it worked with xcopy.
NetWare itself by design runs in Ring 0 plus all NLMs. Now I'll admit, NetWare in and of itself was stable. Add-on NLMs, not so much, and when one of those crashed, it took the server with it. Added points that isolation didn't come until NetWare 5 I think (they still ran in ring 0 however). NetWare's administration and user experience is just flat out miserable. Microsoft won this primarily by having a product that their sysadmins didn't entirely despise. I'll save the rest for the next article.
Still always moving
(Score: 2) by NCommander on Wednesday May 27 2020, @12:24AM
(I need to note that up to that point, bindery was per server; its more like local workstation user accounts, and not what domains and trusts give, even in the pre-AD era)
Still always moving
(Score: 2) by TheRaven on Wednesday May 27 2020, @09:20AM (2 children)
I don't think that is true. NetWare was about the only OS to use rings 1 and 2[1]. Back in 2007, I spoke to several Novell engineers at the XenSummit (Novell was heavily invested in Xen then) who were investigating porting NetWare to Xen. The fact that paravirtualised Xen consumed ring 0 for itself and ran everything else in ring 3 was a problem for them because they used all four rings. I don't think they managed a port before VT-x came along and made it obsolete.
[1] VMS on VAX used four protection rings and (allegedly) DEC told Intel they would nor port VMS to a system that did not have four. Intel shipped the 386... and then DEC released the Alpha with only two rings and ported VMS there instead. VMS did make it to x86 eventually, but only after the switch to x86-64, where it only uses rings 0 and 3.
sudo mod me up
(Score: 2) by NCommander on Wednesday May 27 2020, @10:19AM (1 child)
You're thinking OS/2 which used all four rings throughout it's entire life. Later NetWare's may have supported running NLMs in rings 1-3, but NetWare 3.x was a Ring 0 affair. I'd have to switch to the desktop to fire up the VM to actually dump the GDT, but the InfoWorld article directly references this: Google Books link [bit.ly]
Novell's documentation of the era has turned into cinders, although it's indirectly referenced in here: https://www.novell.com/coolsolutions/feature/15281.html. [novell.com]
Ring 1 and 2 was also used by RMX.
Still always moving
(Score: 2) by NCommander on Wednesday May 27 2020, @10:20AM
To clarify, NetWare 3.1x was what was contemporary with this era. I can't find any mention of NLMs or protection existing until NetWare 5, and even then, NetWare never had pre-emptive multitasking.
Still always moving
(Score: 0) by Anonymous Coward on Wednesday May 27 2020, @10:44PM (1 child)
Which was actually a thing. I got a Beta copy of it when M$ was foisting them on everybody at Intel to test out.
The namespace driver allowed you to mount SMB partitions directly in DOS without windows active and then switch between file systems. It was actually much faster and more reliable than the WFW 3.11 version, in my experience, but as far as I know it never got released as a boxed product itself.
(Score: 2) by NCommander on Friday May 29 2020, @11:19AM
It actually was and the network stack of Windows for Workgroups can be launched without windows itself although it uses a real mode driver to do so. If you've still got it, it would be nice to get that archived.
Still always moving
(Score: 3, Interesting) by JoeMerchant on Tuesday May 26 2020, @03:31PM
I believe we used Netware (was it the P2P solution du-jour?) I remember coax cables, 50ohm terminators, and users who couldn't fathom why they would possibly want their computer to be on a network. One application was to shuttle data across a hospital (to replace a tape drive+sneaker net solution) - the hospital had their own network system, but our doc didn't want to deal with their red tape so he just requisitioned a coax cable to be run through the ceiling from his ward to his office (about 200 yards). Every time the IT guys were in the ceiling working on their own stuff, they made sure to "accidentally" cut off his cable - happened about twice a year.
🌻🌻 [google.com]
(Score: 2) by TheRaven on Tuesday May 26 2020, @05:37PM (2 children)
Windows 3.11 was released in 1992. It run happily on a 16MHz 386 with 4MiB of RAM, the fasted machine you could buy had a 486 DX2 66, probably with 16-32MiB of RAM. The SPARCstation 2, from a couple of years earlier, ran at 40MHz or 80MHz and supported 64MiB of RAM on the mainboard and 128MiB on an expansion. A high-end PC cost $2000. The SparcStation 10 was the only one I could find a price for. It was launched in 1993 at US$33,745.
So, it's true the Sun's were more capable, but they were also 10-20 times more expensive. To me, this actually reflects pretty well on Windows 3.11: it did this almost as well, for a fraction of the cost.
The comparison that makes this look at lot worse is the Acorn Archimedes and later machines with RiscOS and ECONET. These cost as much as a low to mid-end PC, had 1-4MiB of RAM, were trivial to join in a network, and ran a GUI with preemptive multitasking.
sudo mod me up
(Score: 1, Informative) by Anonymous Coward on Tuesday May 26 2020, @06:45PM
That's a detail that a lot of people either forget or are too young to know about. Computers had been around for years before they started to come in variants that could be used at home. None of the home computers were competitive with the more expensive ones being used for business purposes, but the ones being used for business purposes were also much more expensive and often times larger. A "Minicomputer" wasn't very mini by modern standards and not likely something you'd want to have at home, even if you could afford it.
I personally had some NextCubes back about 20 years ago and while expensive at the time, it was still a largely functional computer system even though it was 10 years old at the time and hardware during the '90s was getting fast at a remarkably fast pace. The black and white display was somewhat primitive, but super high res by standards of the day and not that far behind the pixel count of the computers available 20 years ago.
(Score: 0) by Anonymous Coward on Wednesday May 27 2020, @11:05PM
32+ megs of ram didn't really become common until the Pentium Era (maybe even the LATE pentium era).
386 was generally 4, with 8 as an upgrade (I think 16 was the max for most systems), early 486 was 16-32 max, with either 128 or 512 max on some of the later clone chipsets (ULi, ALI, Via, etc.), Pentium era ranged from 128-512, with supposedly a 768-1gig max on some of the later boards, especially the VIA chipsets. For reference, videocards during this period were 2,4,8,16 meg affairs, with 32 meg becoming the standard around 99-2000, 64-128 during the RV100-RV200 (The last of which had bank switched(?) 256 meg DDR), then R300 went to 128-256 where it hung around, at least in the consumer space, until the Tesla/R600 generation when memory started steadily moving up towards the 8-16gig of GDDR6/HBM we have today (32-64 gig on the Workstation boards now?)
That said, 440FX->815 era only supported 1gig->768 meg (Yes, it got lower for multiple years!) in the consumer market, Intel supported up to 3gig of SDRAM/DDR on the 845 chipset, then moved up to 4-8 gig on their workstation chipsets where it hovered until the X48/G45/etc and finally moved up to 16+ gigs on the Nehalem/Westmere hardware where it's effectively hung until DDR4 came out and bumped it to 64GB. Until the IMC in Socket 9xx(AMD) and Socket 1366/115x(Intel), the chipset was often the limiting factor in maximum memory, and certain 3rd party chipsets exceeded these limits pretty dramatically (VIA for instance having 512-1gig capable chipsets in the mid 90s for the Pentium, and later 2-4 gig chipsets for the P4->Core 2 era hardware.)
(Score: 0) by Anonymous Coward on Thursday June 04 2020, @02:49PM
Only for systemd to make a mess of itself when paired with NFS mounts...
(Score: 1, Interesting) by Anonymous Coward on Tuesday May 26 2020, @03:31PM (5 children)
I moved to a new project based on Windows 3.11 from UNIX, and ran into this daily crash hell that Windows 3.11 was. At least once a day, and usually one day a week was two crashes. On one hand it was good that it crashed so often that we saved early and often. We didn't have backups of the PC's we ran, so we routinely made copies of key files to a network drive. Source code was checked in often (agile before agile), so not much risk there. This saved me when my hard drive crashed one day. Windows 95 only crashed once a week, so it was a huge improvement over Windows 3.11.
(Score: 2) by turgid on Tuesday May 26 2020, @03:57PM (3 children)
I used to work at a place in the second half of the 1990s that was running MS-DOS/Windows 3.11 on Pentium II machines. The network was Token Ring ("Ethernet is unreliable" they insisted). We used WordPerfect for editing documents and Lotus 1-2-3 for spreadsheets. DOS/Windows would crash left, right and centre. I sneaked in my Slackware CD and installed it on the spare partition on my PC (yes, the IT department left about 120MB unused...) and ran the Linux port of WordPerfect so that I could actually get something done. Then I'd reboot into Windows when the boss came past.
The network was an unmitigated disaster. It used to crash two or three times a week. Apparently the servers were running OS/2 with LANManager. The Token Ring would die to a strange clucking sound from the PC ("network chickens") at which point you knew everything was about to die. Then there would be an announcement on the Tannoy, "Attention all staff! Attention all staff! The network has crashed. Would you please log off..."
My father the previous decade had run a large LAN for an oil company with several Netware servers and two (redundant) thin ethernets. It never crashed. I once saw a 386 running Netware transmit its 1,000,000,000th IPX/SPX packet.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Tuesday May 26 2020, @05:28PM (1 child)
"Then I'd reboot into Windows when the boss came past"
Was he crippled? How did you have time to bout into windows, didn't it take like 5 minutes.
(Score: 5, Touché) by turgid on Tuesday May 26 2020, @05:43PM
Since it was always crashing, everyone was always rebooting.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Informative) by Muad'Dave on Wednesday May 27 2020, @12:22PM
Wow. As an American, the only reason I know what that word means is that I heard Ian Wallace say it on an old broadcast of 'My Music' from the BBC and looked it up.
(Score: 3, Interesting) by PartTimeZombie on Tuesday May 26 2020, @08:43PM
At that time I was using a Mac for pre-press work. At one point people called it desktop publishing.
We had exactly the same problems. I would reboot my Mac everytime I went to get coffee, or to go to the gentleman's room, otherwise it would crash of its own accord.
We thought we were better than those PC using types, because Macs were "better". In reality they were just as flakey.
(Score: 3, Insightful) by Thexalon on Tuesday May 26 2020, @03:48PM (10 children)
Man, this is bringing back nightmares. GPFs, BSODs, and just everything constantly falling apart. It was so bad that Windows 95 was a substantial improvement, which is saying something.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 3, Interesting) by turgid on Tuesday May 26 2020, @04:13PM (1 child)
It's pretty dreadful when you compare it with the QNX Floppy Demo. That was a 1.44MB floppy boot disk which contained a 32-bit protected mode realtime POSIX OS and GUI with networking stack and a web browser. It could use your modem to go onlne and go surfing. I've still got it somewhere.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Informative) by FatPhil on Wednesday May 27 2020, @06:39PM
The preemptive multitasking realtime kernel I wrote back in 1992 was only 3K in size, so there was plenty of room for a few drivers and some graphics equally compactly coded.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 1) by khallow on Tuesday May 26 2020, @06:13PM
(Score: 0) by Anonymous Coward on Tuesday May 26 2020, @06:48PM
I remember back when I got my first computer, sometimes DOS or Win would just hang and you wouldn't know that it had hung until you got impatient and gave up on the program only to find that nothing shy of powercycling the computer would cause a response. At least Windows 95 usually threw up a BSoD rather than just freezing in place.
(Score: 2) by Gaaark on Tuesday May 26 2020, @09:08PM
It was, finally, Win 95/98 that pushed me to Linux: constant reboots and IE crashes made me look at options.
Found Redhat 5.0(? If I recall correctly) and never looked back. A "substantial improvement"! :)
--- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
(Score: 2) by Revek on Tuesday May 26 2020, @11:40PM (3 children)
Ah windows 3.11 vs 95. Windows 95 was sorta an improvement over 3.11 but it really threw the old dos techs for a loop. The second version of 95 was a vast improvement. When 95/OSR2(had to look that up) came out I was working for a local computer shop. Our company got the contract to install thousands of computers in the all of the public schools in a ten country area. At one such school I installed thirty machines and networked them using internet hubs. All of the old machines had windows 3.11 on them with a coax network. We get a call the next day that the machines were failing and since I was at a neighboring school they called to go and have a look. When I get there the local computer store owner was using a tape drive with the old 3.11 backup on it to install all of the programs they used at the school. Of course they were dos images formatted with fat16 and the windows 95 version we installed used fat32. He insisted that he wasn't the cause of them failing but while I stood there with the principal he broke computer after computer. The principal refused to stop him saying that their guy knew what he was doing. I went to their office and the principal refused to let me use the phone. The superintendent though allowed me to contact my boss who promptly showed up and after a meeting that evening they agreed that their computer guy could not touch any of the machines we installed for six months. I ran into that guy a few times a year and he was always trying to convince me that he didn't do anything wrong never understating that things had changed.
This page was generated by a Swarm of Roaming Elephants
(Score: 2) by NCommander on Wednesday May 27 2020, @12:27AM (2 children)
The problem with OSR2 (and later) was it was a stealth upgrade. It was never formally sold, and instead was a stopgap until Win98 actually shipped. So you'd have software that worked with one Windows 95 box, but not another. I don't even remember offhand if the version string changed from "Windows 95" to Win95 OSR2" or similar.
Still always moving
(Score: 2) by TheRaven on Wednesday May 27 2020, @09:24AM (1 child)
sudo mod me up
(Score: 2) by NCommander on Wednesday May 27 2020, @10:12AM
It was actually possible to do an upgrade, abiet it was kinda screwy. The "New PC"/"Upgrade" thing is controlled through oemsetup.inf so you could convert from one to the other if you knew where to look. I also believe if the setup was launched from DOS, it would also allow you to upgrade in place.
In-place upgrades survived through most of the Chicago builds, although I can't remember if OSR2 actually identified as a seperate version for OEMSETUP to do the upgrade. I'd actually have to try it to know for sure.
Still always moving
(Score: 0) by Anonymous Coward on Wednesday May 27 2020, @03:46AM
i don't even have enough lotion to keep up with this anal intrusion.
(Score: 5, Informative) by istartedi on Tuesday May 26 2020, @04:04PM (2 children)
The Winsock.DLLs paid a good portion of my salary when I was in support. Bugs involving incompatible versions were common, and users, even in dial-up days found ways to get multiple versions installed. We'd rename them (never delete, company policy for obvious reasons) until we were left with just the one that we had installed, then re-boot the machine. Most of the time this was the fix, but sometimes they really did have two networking programs that needed the two different incompatible versions. Then, sadly, it was not our problem to make sure that each program loaded its own DLL at the appropriate time. They were referred to the other vendor and gotten off our phones, because call times mattered.
Appended to the end of comments you post. Max: 120 chars.
(Score: 3, Interesting) by NCommander on Tuesday May 26 2020, @04:44PM (1 child)
It's funny you should mention that because I ran into exactly that sorta pain on the follow up ...
Still always moving
(Score: 0) by Anonymous Coward on Tuesday May 26 2020, @05:15PM
eXoDOS is running into this same sort of issue for the eXoWIN stack he has made to play games.
I pretty much came to the same conclusion he did 1 copy of win3.x for 1 program. The interactions between programs and the way they would randomly install things was a sight to behold. Back then it was wild west windows. By XP it was sorta straightened it out. But win3.x was a monster. Everyone who knew anything about windows would dig around in the shell/kernel/user internals and do just about whatever they wanted. That MS kinda got it sorta to work better in win9x must have been quite an interesting technical challenge. My rule of thumb was anything that installed either Adobe Acrobat or anything from Apple was pretty much a one way ticket to a screwed up windows install.
(Score: 3, Informative) by bzipitidoo on Tuesday May 26 2020, @04:34PM
Holy crap, NCommander, that's way more pain than I ever subjected myself to, for commercial software. I sometimes went that far to crack a game I liked. Mostly what I did was, if it didn't work, and it was commercial, and the debugger wasn't included but was an extra cost, I moved on to something else. I was very disappointed that an equivalent to DOS DEBUG.EXE was not included in later versions of Windows. Think it was Windows 2000 in which DEBUG.EXE was dropped.
I used DEBUG from DOS on occasion. Cracked Lemmings that way. I also cracked Ultima IV on an Apple II, using a boot tracing and DOS swapping technique. Made their custom DOS read the copy protected disk, then switched to plain vanilla Apple DOS to write the data out in the standard format to another disk. Ultima III is one of many games that doesn't work well on emulators that don't or can't slow things down. One of the game elements is a whirlpool that moves around independently of player activity, sinking any ships it encounters. But on the emulator, the whirlpool moves about way too fast, sinking every ship in a matter of minutes. Forces the player to play the game a little differently. The worst was Earth Orbit Station. What I thought was some copy protection was actually a bug that took a lot of digging to reach.
For commercial business software, I fixed a Y2K bug in some accounting software. Made in 1994, DOS text based, and broke when the year hit 2000. Somehow, 2000 became 1910. I thought 1900 was a more logical failure, and wondered how they hit 1910. Found out. They took the year, subtracted 1900, then copied the 2 digits. But 2000-1900 leaves 3 digits, 100, and the software just grabbed the first 2. The last 0 overflowed the variable space, which may have caused problems elsewhere. I never did find out what was being overwritten, if anything, as I made it moot. Changed the computation to do year % 100. This changed the date from 1910 to 1900, better, stopped the overflow prob if any, but not fixed. Searched the executable for the string "19", and found it. Changed it to "20", and viola, fixed! The customer didn't care that that then broke 19xx dates, what mattered was 20xx being correct. So it's good until 2100, and I rather expect by then, most of us, including the customer, will be dead, nor will that software still be in use.
(Score: 2) by SomeGuy on Tuesday May 26 2020, @04:37PM (6 children)
Built in peer to peer networking was a big game changer.
Before WFWG, if you wanted to share files, you had to have an expensive dedicated machine running a file server. And back then, you paid for server software through the nose. All of a sudden, people could share files directly between machines without having to bow down to some centrally controlled, sometimes underpowered, machine. For no real extra cost!
I think people these days don't really understand how awesome UNC names were. You no longer had to map a drive before running an application. For example, you could just start Paint, draw a picture, click Save As, and type something like \\server\share\myfile.bmp. At most you might have to type a password, but with an NT Server share and domain login it already knew if you had access or not.
Although, WFWG was not really quite that common. At least where I was, most users stayed on plain old 3.1x until they got Windows 95. Of course, once you added this built in networking goodness with a nice macintosh-like icon/drag and drop folder desktop, you really had something very slick. From 95, if you wanted to get to that network file, just browse Network Neighborhood, Server, Share, and then double click Myfile.bmp!.
Similarly, it was a big boon for network printing. It was suddenly possible to share cheap parallel port printers connected to user's computers as long as the machine was on.
(Score: 3, Informative) by NCommander on Tuesday May 26 2020, @04:46PM
I actually remember it more than base 3.1 and was more common throughout the later half of '93 to '95 due to the fact it had 32-bit disk support so it's quite a bit speeder than base 3.1 even without the network improvements.
Still always moving
(Score: 2) by JoeMerchant on Tuesday May 26 2020, @05:30PM (2 children)
We gladly installed cards and paid for Netware (or whatever it was) to get P2P networking in the mid '90s - it was so so much better (for us) than having to stand up a server and maintain that, too.
🌻🌻 [google.com]
(Score: 2) by NCommander on Wednesday May 27 2020, @12:30AM (1 child)
That was either NetWare Lite or Personal NetWare depending on the vintage which basically gave you NetWare NCP ontop of DOS and without the access controls bit. NetWare's P2P product wasn't super great from what I can tell, and IBM basically decided to go from PC Net to LAN Server and exited that market.
Still always moving
(Score: 2) by JoeMerchant on Wednesday May 27 2020, @01:29AM
Whatever it was, it covered our use cases easily and we didn't have complaints at all. Maybe it was insecure, maybe it didn't scale well, for 8 or less computers on a network it was fine for everything we did.
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Tuesday May 26 2020, @07:59PM (1 child)
I got started in PC networking just in time to join the very last of the 3Com 3+Open SIG meetings in the bay area. The very next meeting we had was after Microsoft "Borg'd" the work that 3Com had done and incorporated them into LanManager. We renamed the SIG to the Microsoft Networking group (or somehting like that) and at least one of the 3Com guys I had worked with moved over to Microsoft. He eventually went to work on MS's new product they had changed from being named "Portable OS/2" to "Windows NT" (I even had my NT server crash on me - only once and only due to a hard drive error - and the error it threw started with "OS/2 error...")
(Score: 2) by NCommander on Wednesday May 27 2020, @07:14AM
I'd *love* to show 3COM networking stuff off, but nearly all of it is lost to time like 3+Share, or the hardware just vanished. Any insight into 3COM, especially early 3COM would be amazing.
Still always moving
(Score: 2) by number6x on Tuesday May 26 2020, @04:44PM (24 children)
This was the last version of Windows that I developed software for. Mid-1990's I was supporting applications written in MicroFocus COBOL and developing new code in Borland's Delphi.
Windows never seemed to get a foot hold as a platform for development, outside of a few niche areas. Oh, and games. If you played or wrote games, Windows was king.
(Score: 0) by Anonymous Coward on Tuesday May 26 2020, @05:21PM (23 children)
Windows never seemed to get a foot hold as a platform for development, outside of a few niche areas
Wha? That is like the exact opposite of what happened.
Pretty much any CRUD app was written with windows in mind. VB6 changed the world. VS6 did too. VS2002 and Vista ended it. Everyone ran the other way for anything that was better. By that time though the web was gaining traction. IIS was easily 50% or more of web installs at one point.
Fast forward to now... These days no one would start a CRUD app in windows unless 'reasons'. It would be some JS stack with either a java backend or JS.
There was a point in my career where putting MFC/WIN32 C++ pretty much guaranteed a 100k+ job.
(Score: 2) by JoeMerchant on Tuesday May 26 2020, @05:33PM (15 children)
Java, and most of its derivatives, is and always has been the malformed spawn of evil - one of the few environments I like less than Windows.
🌻🌻 [google.com]
(Score: 2) by DannyB on Tuesday May 26 2020, @08:00PM (14 children)
<no-sarcasm>
I can only say that Java must have done something right to hold the top #1 and sometimes #2 spot in language popularity for 15 YEARS.
Recently Python has beat out Java pushing it to #3 in the first time in a very very long time.
I did write a journal entry [soylentnews.org] detailing some of the sophistication of the Java runtime platform.
In Java 15 (this year), the memory limit for Java will be raised to 16 Terabytes of heap size. GC pause times still under 1 ms.
Call me when your Python, Node.js, Perl, or anything else can do that!
</no-sarcasm>
I think the current max Java heap size is restricted to only 4 Terabytes, which limits what can be done in a Java "Hello World" program. [github.com]
The lower I set my standards the more accomplishments I have.
(Score: 2) by JoeMerchant on Tuesday May 26 2020, @08:43PM (6 children)
no sarcasm:
Java 15, the 15 is a prima-facie explanation of my major complaint against Java: which Java are you running, which Java does your target machine have installed, what changes between versions? Quite a lot - enough that even sub-version variations have caused me non-functional issues a shockingly high percentage of the time I was forced to work with Java. Not to mention the more than occasional desire to simultaneously run applications that need different Java versions, yes you can do it, but should you have to manage this mess?
Most popular, like Windows? I don't think that most popular is any relief from the epitaph: malformed spawn of evil.
Since it is so popular, I have fairly often been face to face with the task of "take this non-functional piece of java that used to work great last year and figure out how to make it work again in our updated box." There have been times where "recode it in Qt" was not only less maintenance into the future, but also less work at the moment.
Python? I won't label Python as malformed or evil, but I will call it ill-conceived. Unless you're just slapping together pieces from the approved widget toolbox, then Python is great. But, therein lies the rub: you graft all these toolboxes together, and you create a configuration management nightmare. Also, when you try to do anything original that involves any significant amount of data manipulation (loop over a million pixels, for instance?), you're out of Python and writing in C++ or something similar to get that work done - so why didn't we just do it in C++ to start with? And, yes, there are whole tool systems to manage the Python ball-of-snakes dependency hell. Remind me again how C++ is "just too hard" and Python is "easier"? What I've seen Python programmers do again and again is "make something quick" and paint themselves into a corner where the only way to expand the application is basically to throw out the existing code and start over - that's a pretty rare occurrence in my C/C++ and even Fortran, BASIC and assembler travels.
I will say, I like the typical deployment model of node.js, and I'm actually looking into adding an http server on our C++ apps to do something very similar - the ultimate cross platform interface: a dynamic web server. Too bad that tech like WebSockets is such a pain.
🌻🌻 [google.com]
(Score: 2) by DannyB on Tuesday May 26 2020, @10:13PM (4 children)
Excellent point.
I was a classic Mac developer during the days described by this article. And I did consider Microsoft and Windows to be every bit as evil as you describe.
I suppose like Windows developers back in the day, I work with Java, it makes money, so I don't complain about its warts.
The lower I set my standards the more accomplishments I have.
(Score: 2) by JoeMerchant on Tuesday May 26 2020, @11:40PM (3 children)
I bought an Atari 800 with my life savings in 1982 - used it through college but had to use DOS machines as well. Later got a 16 bit Atari (every bit a Mac-equivalent in hardware performance) that was really only useful as a dumb terminal into the college mainframes due to the rather dead-end nature of its software ecosystem.
"Real work" toyed with the idea of implementing on Macs in the 90s, but the reality was that all our customers already had Windows PCs, so we really weren't going to convince our customers to give up another 3 cubic feet of desk volume to another computer just to run our software. My only form of effective protest was using PharLap 32 bit environment for DOS, and later the Borland API for Windows95. Even that, when our product got bought out, the first thing the buyers did was spend 3 man years re-coding everything from Borland into the Windows API, because they felt more comfortable sourcing programmers from the open market for the more common API.
Every time I fired up the Microsoft development environment back then, I found myself spinning my wheels taking hours to do something trivial and of little value - competitors tools tended to make the worthless stuff flash past much more quickly, and not produce code with so much boilerplate.
Today, I've got .net developers in my team, when they make a trivial change to their code there's vomit all over 40 files in the repository - they call it source code but it's more like checking in binary that's only interpretable by the proprietary tools. I have a bit of the same with xml .ui files in QtCreator, but that's fairly self contained - the .net guys seem to never be able to make a one-line code change that does anything.
🌻🌻 [google.com]
(Score: 2) by DannyB on Wednesday May 27 2020, @03:34PM (2 children)
One thing you pointed out about Java, is "which Java?"
That is a good point. But I would mention that it is not like the Python 2 vs 3. Java has moved heaven and earth to maintain backward compatibility.
Companies who are "stuck" on Java 8, can get paid support until 2030, at minimum. For everyone else, you can upgrade to the LTS versions every five years, or keep up to date with the new Java versions -- which in practice I have found zero difficulties with.
The biggest thing that is a problem is if you have a very old code base using deprecated features that have finally at long last started to be removed after java 8. Or if you use libraries with such features. Due to the widespread use of Java (remember top language) all modern libraries are reasonably up to date.
Another point about "which java" is that this is only an issue if you use it to deliver software to an end user. Java is widely used on big systems for enterprise use where development is internal, and deployment is on systems entirely controlled by the organization which developed them.
"Which Java" is not as bad as "which std C lib" some years back on Linux. Or possibly which Python.
A new thing in Java is ahead of time compilation where you generate a statically compiled executable, as you would with C. This is still very new, but I even have seen articles about using GraalVM to build static executable GUI applications.
The lower I set my standards the more accomplishments I have.
(Score: 2) by JoeMerchant on Wednesday May 27 2020, @04:34PM (1 child)
As soon as you mention money, support agreements, etc. that brings in whole other departments that I, frankly, prefer not to deal with. The lawyers that get concerned about LGPL and similar every 5-10 years are much easier to deal with than the rest of the bean counting machine - even when our company is relatively free with the money, there are still critics in no less than 4 silos who love to snipe at anything that costs a dollar.
I've got a fairly skewed set of rose colored glasses for Qt, since I started with it around 2006 - just after the 3.x -> 4.x transition pain had subsided, and the 4.x -> 5.x transition didn't start until ~2012-2013, and the 5.x -> 6.x transition is just getting started, so a ~7 year pain cycle - not too bad, and my experience has only been with one transition so far, and even that is usually a 10 minute touch-up to get a large-ish 4.x app running in 5.x. Compatibility within the major revisions has been excellent, though they did (finally) add a random number class in 5.10 that I like using and so hit problems with Ubuntu 18.04 which comes standard with 5.9.5... but, anything written for 5.0 onwards will work 99.999999+% trouble free on 5.15, they don't seem to be killing themselves to make it happen - it just does. On the other hand, Qt on anything other than Windows/OS-X/Linux has a ways to go - you can do it, but it starts to remind me of other, less trouble free dev environments when you get to Qt on Android or embedded (haven't even tried iOS yet.) Then, starting from a C++ base, you have the option to bring in all sorts of 3rd party libraries when needed, but rarely will a project need more than a couple - unlike my Python experience where you have 4+ external libraries loaded before you start to do anything, and I have seen that number rise over 12 fairly easily...
I seem to recall byte code processing silicon and similar promises being implied 20+ years ago... Of note: Ubuntu 20.04 desktop (claims to have) sped up their responsiveness significantly by getting Java out of the mouse pointer handler - my question is: what idiot thought it was O.K. to put it in there in the first place? but... apparently it does make a noticeable difference.
🌻🌻 [google.com]
(Score: 2) by DannyB on Wednesday May 27 2020, @05:50PM
Yep. Me too. I'm sure I could get that if I needed it. But I don't. Open JDK is perfect.
We are big enough that we already have more open source than we probably know, and we have management buy in on that, but we pay attention to being sure we're complying with license terms.
Considering how much .NET stuff we have, and how the entire .NET world is vendors with their hand held out for money, I feel miserly using Java. Everything I use is open source. My development tools. My language, compilers, runtime, 3rd party libraries, Apache Tomcat, etc.
I often wondered back in the early 2000s what Qt development would be like.
About C++, in the mid late 1990s I was looking hard at C++ for our next generation products, which I believed would be desktop. But things were not 'stable' enough (and I don't mean runtime, but language and compilers). Especially on Mac. Different vendors implemented different subsets of the language. Notably Microsoft. (As I seem to remember it) Also not a lot of cross platform GUI frameworks. We did something else. A few years later I looked at Java, for desktop GUIs, and liked it at that point. It was stable and cross platform. Then I looked at it for Web development and went with it for that. That was a good move because everyone else in the same industry/business did pretty much the same thing, Java.
I remember that. Nothing ever came of that. But Java compilation to native code has become state of the art in compilers. If you see the journal article I linked, I describe how Java bytecode is loaded on the runtime, then compiled quickly by a C1 compiler, and later compiled slowly and with heavy optimization by a C2 compiler. Yet there is dynamic class reloading. But I won't go into the rest of that journal article here.
Java is great for workloads that run for long periods of time with lots of memory and cpu cores. Don't write a simple command line program in Java. Do write a gigantic server project in java. And by gigantic, I mean something you wouldn't even consider writing in a dynamic language. Especially if you need to maintain it for at least ten years or more.
The lower I set my standards the more accomplishments I have.
(Score: 0) by Anonymous Coward on Wednesday May 27 2020, @11:18PM
9/10ths of Java/Python work at this point (As well as C/C++, given the rapid changes they have been making since 2010) seem inclined to breaking existing code, especially ABIs leaving to all kinds of undocumented regressions some of which may cause your 'mission critical' code to go from 'working' to 'failing in subtle not clearly defined ways'. Another recent one is the migration to 64 bit int timestamps on 32 bit linux to 'solve' the t_time problem there. Only problem is, this will cause old apps to fail when it wraps around and just puts off the problem to the next group of suckers in the future rather than solving the issue elegantly (have some reasonable length of time in seconds for the timestamp, and then separate the values into say a decade or centennial counter that throws an exception upon overflow then increments a separate year or epoch structure, which the app itself shouldn't need to know, allowing the application to run for between a decade and 100 years (most won't run this long, but those that do need a robust way to keep going no matter what.) Given that the epoch counter will automatically wrap around before it his the maximum value your program will already take into account time exception events, and even if it somehow gets used in an era where the epoch is uncountable it can have the OS handle return any 'special event' triggers it needs to act on, like daylight savings, leap year, leap second, etc without having to take any of those first year programming shortcuts of including them in your code (making it brittle and well nigh unmaintainable going into the future.)
(Score: 2) by FatPhil on Wednesday May 27 2020, @06:43PM (6 children)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 3, Interesting) by DannyB on Wednesday May 27 2020, @07:07PM (5 children)
COBOL has been around far longer than Java and most modern languages. But COBOL hasn't been near the top spot for a very long time.
In the following animated chart, COBOL (starting in 1965) was in the #2 spot until it dropped to #3 in 1977, then dropped lower from there.
Most Popular Programming Languages 1965 - 2019 [youtube.com]
The lower I set my standards the more accomplishments I have.
(Score: 2) by FatPhil on Wednesday May 27 2020, @07:26PM (4 children)
I'd forgotten that for the majority of computing way back that Fortran would be dominant, and of course that long predates the start of that animation, so probably does give Java's spell a run for its money.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by DannyB on Wednesday May 27 2020, @08:54PM (3 children)
That animation also echos my experience.
In the 80's Pascal took off until near the end of that decade as C/C++ gained traction.
Java came on the scene, and then about 15 years ago held the top spot, occasionally dropping to number 2, but mostly number 1 for the last 15 years. I know people don't seem to like that. But it is a fact, and also echos my experience. About the time I picked Java, everyone else in the same business was also picking it. And for reasons.
But no language is perfect. And no language is ideal for all uses. If one language was perfect, then we would all be using it.
In fact, among programming languages, the very thing that can make a language great for some purposes makes it unsuitable for other purposes. It's worse than those "pick any two" kinds of llists:
Pick any 2 for your speaker:
1. Good strong Bass
2. Efficiency
3. Small enclosure
The lower I set my standards the more accomplishments I have.
(Score: 2) by FatPhil on Thursday May 28 2020, @08:49AM (2 children)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by DannyB on Friday May 29 2020, @04:48PM (1 child)
A 48 inch or 60 inch model?
The lower I set my standards the more accomplishments I have.
(Score: 2) by FatPhil on Monday June 01 2020, @09:06AM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 5, Informative) by DannyB on Tuesday May 26 2020, @07:50PM (6 children)
As my failing memory seems to recall . . . I and everyone else on the green site religiously looked at Netcraft. IIS always was way behind Apache. Until . . . Microsoft did a deal with someone, um, VeriSlime, or Network Solutions, to park unused domain names on IIS. Then suddenly, overnight, NetCraft showed IIS way ahead of Apache.
Yep . . . IIS the #1 web server -- for unused domain names not doing anything.
Apache . . . the long time #1 web server actually used to get things done.
Once NetCraft changed their methodology to count active vs
microsoftinactive sites, the outlook changed back to Apache's favor again.The lower I set my standards the more accomplishments I have.
(Score: 3, Informative) by bzipitidoo on Tuesday May 26 2020, @09:25PM (1 child)
Whoa, didn't know about that particular little slimy MS trick. But it sure fits their M.O. Have to add it to my list of MS crimes-- the license key DRM misfeature added in XP, the bribery, bullying, and lying they pulled around OOXML to ram that "standard" through the standards body, the Plays For Sure assault on every other audio codec and file format so that portable music players would play only WMA and MP3, and never Vorbis, the DRMed to death debacle that they made of Vista, the embrace, extend, exterminate attempt they made upon Java that was eventually renamed J, and much the same attack on the web with IE, the levy on every new PC whether or not it came with Windows or DOS, and the BSA raids upon many businesses that they backed. Ought to write it all down in a more organized fashion. But surely someone has already done that.
(Score: 2) by TheRaven on Wednesday May 27 2020, @09:36AM
While I agree on most of the other points, have you actually read the OOXML and ODF specs? Both were awful and neither one deserved to be standardised. Microsoft's reaction here was justified: competitors are pushing through an unimplementable 'open' standard and lobbing to require government procurement to be directed only to office suites that implement these standards, so what do you do? You don't have time to get a real standard through because of aggressive lobbying to get ODF passed, so you push a competing crappy standard.
To give an example of how bad ODF was (it may have improved now, I only read the original standard version), the spreadsheet file format did not tell you what a formula is. It told you how to store a grid in XML, but told you absolutely nothing about the formula language. The only way to infer that was to reverse engineer OpenOffice (which some other open source spreadsheet projects did).
OOXML was criticised for things like the 'typeset like Word 97' flag (which was marked as legacy compatibility and not for new documents), but ODF didn't describe any of the typesetting algorithms either. How should you do line breaking in a paragraph in an ODF document if you want to render ODF in a compatible way? Go look at what OpenOffice does and copy that. Compare that to TeX, where all of the layout algorithms are documented in excruciating detail and it's possible to do a compatible clean-room reimplementation.
ODF was a massive missed opportunity. We could have had a well-written gold standard for office document formats if the ODF advocates had been willing to spend a couple of years taking feedback onboard. Instead, ODF was rushed through with no serious oversight and was used to justify pushing OOXML through with a similar lack of review. We ended up with two crappy standards.
sudo mod me up
(Score: 2) by FatPhil on Wednesday May 27 2020, @06:44PM (3 children)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by DannyB on Wednesday May 27 2020, @07:01PM (2 children)
It could be, I don't remember. For some reason, I want to think it was Network Solutions. But Godaddy might actually be correct. Don't know.
The lower I set my standards the more accomplishments I have.
(Score: 2) by FatPhil on Wednesday May 27 2020, @07:17PM (1 child)
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by DannyB on Wednesday May 27 2020, @08:45PM
Informative.
Great link. I wish I had a mod point.
The lower I set my standards the more accomplishments I have.
(Score: 2, Interesting) by throckmorten on Tuesday May 26 2020, @04:52PM (4 children)
Wow, wouldn't life be a lot easier if you invested in a couple of junker 486s from ebay?
Glad you got it working in the end though.
(Score: 2) by epitaxial on Tuesday May 26 2020, @10:27PM (1 child)
Then comes the joys of working with floppy drives. No thanks. I'm never touching those again.
(Score: 2) by jmorris on Tuesday May 26 2020, @11:21PM
They make a floppy emulator. It fits in a floppy bay, accepts a flash card and has a display where you change which floppy image is visible on the floppy interface pins. Lots of misc hardware with a floppy drive that is otherwise useful, musical things especially. But floppy drives and discs that are good for more than one read / write cycle are no longer manufactured. So somebody innovated a solution.
(Score: 2) by NCommander on Wednesday May 27 2020, @12:14AM
It's more that I really don't have the room to have such a setup; I was supposed to move to a new apartment in April, but with COVID-19, everything got turned topsy turby so at the moment I'm staying with family. I did manage to get my ThinkPad 380D retrieved from storage, and that's going to show up on a later post/video.
The other headache is a lot of Ethernet adapters that work with Windows are thicknet. It's not that hard to convert to coax, but it's more little bits I need to acquire and track down.
Still always moving
(Score: 0) by Anonymous Coward on Wednesday May 27 2020, @12:34AM
I found that instead of QEMU, BOCHS is a bit more configuration-friendly when it comes to testing retro software and emulating old PCs closely. And currently for reasons I just don't understand these 486 mainboards with leaking batteries get enormous prices.
(Score: 2) by Debvgger on Tuesday May 26 2020, @09:43PM
Thank you very much for taking the time needed for researching this and sharing it with us.
(Score: -1, Troll) by Anonymous Coward on Wednesday May 27 2020, @12:25AM (2 children)
Back in those days I had mastered Pascal and I was learning C++ and all the deceitful lying Boomers were lying to me about how I could apply my programming skills to a high paying job that all the lying deceitful Boomers said existed in the real world. Of course the jobs didn't exist. Of course the jobs never existed. Of course the Boomers were lying to me. But I didn't know that at the time. No. I was naive enough to believe there were skilled jobs for skilled programmers who got paid more than zero dollars. I was naive enough to write software for Windows 3.1 in C++ and move on to Linux. I was naive enough to learn sockets and TCP/IP on Linux. I was naive enough to write networking tools for Linux and move on to MacOS. I was naive enough to write network drivers for MacOS and move on to web development. I was naive enough to learn Perl and Python and PHP and write dynamic web sites. I was naive enough to write tiny web servers in Bash. I was naive enough to learn JavaScript and write web apps.
And all the while there were zero jobs. There are still zero jobs. There never were any jobs. Because the Boomers lied to me. The Boomers lied to everyone. The Boomers are pathological liars.
Fuck MDC
(Score: -1, Troll) by Anonymous Coward on Wednesday May 27 2020, @12:37AM (1 child)
First the Boomers lie to you, then the Boomers mock you, then the Boomers mod you Troll.
Fuck MDC
(Score: 0) by Anonymous Coward on Wednesday May 27 2020, @01:05AM
Done, done, and, done! You are very welcome!
(Score: 0) by Anonymous Coward on Wednesday May 27 2020, @01:07AM (1 child)
Am I the only one horrified to open up SN, and see a giant Windows icon? Are we doing pop-up autoplay vids, next?
(Score: 0) by Anonymous Coward on Thursday May 28 2020, @06:09PM
Nope. I too am horrified when I open up SN, and see a story on Neanderthal women.
(Score: 3, Interesting) by daver!west!fmc on Wednesday May 27 2020, @01:25AM (2 children)
All that stuff about Windows vs. Workgroups and 3.1 vs. 3.11 and you didn't get to the real big news in Windows for Workgroups 3.11: it had its own FAT filesystem code in a ring 0 (VxD) driver, so it didn't need to call down to real mode MS-DOS for disk I/O, which broke some of the MS-DOS-based redirectors.
Indeed, there was no TCP/IP stack by default and that you could get one from Microsoft was not well known and if you did know it you might not be satisfied with it.
I was the guy at The Wollongong Group who ported the PathWay Runtime TCP/IP stack from an MS-DOS TSR to a Windows VxD in 1994. That project involved working over its Winsock DLL too and I did that too because I had learned it could be more BSD-sockets-like, and let me tell you, Winsock 1.0/1.1 DLLs were all tied to the underlying TCP/IP stack and its lower-level (and vendor-peculiar) API. (For TWG, most of the BSD-sockets flavoring was in the Winsock DLL; the packet buffers and TCP connection state were in the TSR or VxD and the DLL did most of what was needed to present the situation in a sockets-flavored way.) It wasn't until Winsock 2 that you had some notion of other-than-IP protocols in Winsock and multiple transport providers.
My development system was a DECpc 486/66. 66MHz. For some notion of clock speed, I think we're at about 500x now, never mind 10x. That development system also had a monochrome display adapter installed with a monochrome monitor attached, for Numega's Soft-ICE/W debugger, which came in handy as a debugging aid for VxDs.
(Score: 2) by NCommander on Wednesday May 27 2020, @07:12AM (1 child)
*sigh*
You're absolutely right on 32-bit disk access. That was actually in the original script for the video, and it got left on the cutting room floor as I focused on the networking bit more in-depth. I allude to it in the write up but don't actually call it out. I'd love to hear more, as finding actual people involved with early Windows and especially Winsock stack development are few and far between.
I do hope I didn't mangle history too badly!
Still always moving
(Score: 3, Interesting) by daver!west!fmc on Sunday May 31 2020, @04:42AM
I was also the WIN/TCP for MPE/V guy, read I came to it from an HP3000 background, but was familiar with TCP/IP and C and Unix and x86 assembly. I had been drafted to fix bugs in the released MS-DOS TSR stack and Winsock (while other folks worked on the to-be-last release of it) and had been doing that work on an 80386/16 that no-one wanted to use. That was my introduction to the product's internals (I had some years previously had occasion to holler at a previous MS-DOS stack "architect" for doing as much as possible to reduce its RAM footprint to the point of interoperability and performance problems, which were particularly nasty with the HP3000 where I had no ability to modify the TCP/IP stack as that was HP's). Then it came time to think about what to do next, and it turned out I was welcomed by the PC development team. Some reviewer had called TWG out for having old MS-DOS-based technology and somebody had the idea that if we had a VxD it would look more modern than NetManage's DLL. I suggested that if we were looking at a 32-bit environment we should perhaps look at starting fresh with a port from 4.4BSD. The other folks thought that was "risky" and we should base it on the MS-DOS TSR. So that's what we did, but it really was a port from TSR to VxD. First, a way to call the VxD from ring 3, then the packet buffer code, then enough of IP and ICMP that I could send myself a ping. Another person was working on the NDIS support, and then we worked on getting it able to ping another host. Then UDP and TCP, and more of the API, and then Winsock. Note that we made no attempt to support the TSR API, the VxD API was conceptually similar but some API functions went away, new ones were added, and I made no attempt to keep the request codes the same and no-one cared.
(Score: 3, Informative) by toddestan on Wednesday May 27 2020, @03:23AM (1 child)
The issue with the timing loop sounds like a similar or possibly the same problem that cropped up in Windows 95. Windows 95 would crash with a similar message when you tried to boot it up on a faster CPU, which at the time faster meant something like 300 MHz. For some reason I seem to remember this affected AMD CPUs like the K6 more so than Intel CPUs like the Pentium II.
Microsoft released a patch to fix this, but in their brilliance you had to boot up Windows to apply the patch, which left you in a catch-22 situation if Windows wouldn't boot. Since it was a timing thing, if the CPU was on the cusp, you could just keep trying and eventually you'd get luck past the error. But for something like the K6-III 450 MHz I had that wasn't going to work because it was just too fast. I finally figured out I could extract the files from the patch, boot into DOS, and manually copy them into the Windows directory and the PC would boot into Windows. It wasn't completely happy about this and would still throw some errors at me, but it was enough to get into Windows proper and then I could run the patch installer and all was well. The other option, of course, was to crack the case and re-jumper the motherboard so it was something like a K6-III 200MHz, apply the patch, then jumper it back to original speed.
(Score: 2) by NCommander on Wednesday May 27 2020, @10:26AM
I actually looked a bit closer, and found this: https://msfn.org/board/topic/141402-windows-95-21ghz-cpu-limit-broken/ [msfn.org]
The crash is in NDIS.SYS in 95, so probably the same bug. NT uses a different driver model implementation so dodged that bullet. FIXCPU95 might even work on WfW 3.11 as it should be relatively close but who knows?
Still always moving
(Score: 2) by Muad'Dave on Wednesday May 27 2020, @12:37PM
the Crynwyr Drivers [crynwr.com]? IIRC it's pronounced 'crunnew' - they put out sound files [crynwr.com] with someone saying it. Anyway, those free drivers were the cat's meow for getting dos and windows machines talking back in the dark ages.