Stories
Slash Boxes
Comments

SoylentNews is people

posted by NCommander on Tuesday May 26 2020, @02:54PM   Printer-friendly
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.

Exploring Windows for Workgroups 3.11

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:

Windows 3.11 About

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.

Workgroup Add-On

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

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.

Windows General Protection Fault

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.

GDI Crash

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?

Windows Debug About

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.

Visual C++ 1.52

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.

Network Setup

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.

NET on 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.

File Manager

Print Manager

ClipBook Sharing

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.

Hearts

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

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.

Mail First Start

Create first user

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:

The GREATEST Security switch ever!

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.

Y2020 problem

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+ in 1994

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.

Schedule+ ACLs

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

RAS

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 UI

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

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

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

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!

NetWare MONITOR

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.

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by JoeMerchant on Tuesday May 26 2020, @11:40PM (3 children)

    by JoeMerchant (3937) on Tuesday May 26 2020, @11:40PM (#999416)

    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]
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by DannyB on Wednesday May 27 2020, @03:34PM (2 children)

    by DannyB (5839) Subscriber Badge on Wednesday May 27 2020, @03:34PM (#999698) Journal

    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.

    --
    People today are educated enough to repeat what they are taught but not to question what they are taught.
    • (Score: 2) by JoeMerchant on Wednesday May 27 2020, @04:34PM (1 child)

      by JoeMerchant (3937) on Wednesday May 27 2020, @04:34PM (#999755)

      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.

      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...

      A new thing in Java is ahead of time compilation where you generate a statically compiled executable

      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

        by DannyB (5839) Subscriber Badge on Wednesday May 27 2020, @05:50PM (#999789) Journal

        As soon as you mention money, support agreements, etc. that brings in whole other departments that I, frankly, prefer not to deal with.

        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.

        even when our company is relatively free with the money

        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.

        rose colored glasses for Qt

        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 seem to recall byte code processing silicon and similar promises being implied 20+ years ago

        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.

        --
        People today are educated enough to repeat what they are taught but not to question what they are taught.