Thanks to the recent warez mega dump, another long lost gem has come to light: NetWare 386, also known as NetWare 3.0.
In September 1989, Novell released NetWare 386 V3.0, the first in a long line of 32-bit network operating systems. At the time, Novell’s mainstay was NetWare 2.15, a system designed to run on 286-based machines.
NetWare 386, as the name suggests, required at least a 386 processor. It was a major redesign of the NetWare OS intended to take advantage of (then) high end 32-bit hardware. Whereas NetWare 2.x was linked from object modules during installation (much like commercial UNIX implementations), NetWare 386 utilized modules (NLMs, or NetWare Loadable Modules) which could be loaded and unloaded at run-time.
Disk drivers, network drivers, protocols, and all sorts of added functionality were implemented as NLMs in NetWare 386. This made NetWare 3.0 installation and maintenance far simpler compared to NetWare 2.x. The NetWare 2.x kernel had to be linked during installation (a lengthy process), and any change of a disk or network driver required the OS to be re-generated again. In NetWare 3.0, all it took was copying a new driver and changing a configuration file.
NetWare 3.0 was in some ways a limited release, although at the same time it was a fully functioning file server which could support up to 250 users (compared to the 100 user maximum of NetWare 2.x). That was reflected in the pricing—$7,995. NetWare 3.0 was Novell’s flagship product, even though it didn’t fully realize the NetWare 386 vision. Only the IPX protocol was supported, the set of available disk and network drivers was quite limited, and third-party NLMs were more or less nonexistent.
When NetWare 3.0 was released, the NLM development kit was not yet available. That is likely also the reason why NetWare 3.0 did not ship with CLIB.NLM, MATHLIB.NLM, and a few other NLMs. These NLMs became available a few months after the NetWare 3.0 release though, together with the development kit.
Installing NetWare 3.0 is not fundamentally different from installing later 3.x releases. The installation procedure is completely different from installing NetWare 2.x. Rather than configuring and linking the OS kernel first, it is initiated by booting the NetWare 3.0 OS, and all requisite drivers are dynamically loaded as separate modules.
For reasons that are not entirely clear, NetWare 2.x could boot directly from hard disk (using so called “cold boot loader”) but NetWare 3.x cannot. NetWare 3.x requires DOS to be loaded first, and then SERVER.EXE must be run. Unlike NetWare 2.x, it is possible to completely shut down NetWare 3.x and return back to DOS. For that reason, NetWare 3.x requires either a small bootable DOS partition or a bootable DOS floppy.
To install NetWare 3.0, one simply runs SERVER.EXE, loads the appropriate disk driver, and then loads INSTALL.NLM. While NetWare 2.x required a separate external installer, NetWare 3.0 is installed from a running NetWare system.
NetWare 3.0 is old enough that it didn’t ship with ODI-based client drivers and used the old monolithic shell. It’s also of course old enough that it only supports DOS 3.x and 4.0 clients. But it has no trouble talking to newer clients running ODI and PC DOS 2000, for example.
Original NetWare 3.0 disks are yet to be found. It is possible that only a few thousand copies were ever sold, and since they would have been sold primarily to large corporations (given the eight thousand dollar price tag), the vast majority of the extant copies were no doubt destroyed.
And yet, thanks to software pirates of 1990, NetWare 3.0 can run again after 35 years.
> Rather than configuring and linking the OS kernel, it is
I think you forgot the rest of the sentence…
That said, one thing that struck me reading your articles on NetWare was how much Novell kept tweaking the deployment story. They seemed very unsure if it should be booting from DOS or not.
Nice, that was my first real job, writing NLMs, for netware 2, 3 and 4 over the years.
Thanks, I’m not sure what happened there.
willem : what NLM’s did you wrote?
Is anything survived?
I wonder what would have happened if “Portable Netware” was ported to AMD64 or IA64.
At some point, Novell had plans to run on all kinds of architectures, including PA-RISC – that’s about as close to Itanium as Netware probably ever got. It seemed every major operating system vendor was busy trying to port their OS to all kinds of architectures, most of which utterly flopped (NT on SPARC, OS/2 on PowerPC, HP-UX on x86, SCO on Itanium, and on and on).
@Josh Rodd:
HP and Novell eventually ported NetWare 3 to HP-UX on PA-RISC… It didn’t sell well, though.
@Yuhong Bao:
Such a product couldn’t exist, for several reasons. For starters, NetWare 3 is from 1990, while both Itanium and Opteron were only making their first steps in the beginning of 2000s… The difference in generations would be too great Also, several companies (including HP) did port NetWare 3 to their Unix systems, to lackluster customer interest. HP already had NetWare ported to HP-UX on PA-RISC without much success, why should they try again with HP-UX on Itanium? As for AMD, it was hardly considered a serious vendor, and they didn’t have an Unix, plus NetWare for 386 existed and it hardly had any drawbacks compared to a hypothetical NetWare AMD64.
Yes. What is interesting is that NetWare 2.x can be started from DOS, by running NET$OS.EXE. But a bootable NetWare partition seems to be the default.
If I had to guess: In NW 3.0 things got more complicated, since loading SERVER.EXE wasn’t enough — it was also necessary to load the disk driver and potentially a number of other files early in the boot, before the SYS volume could be accessed. Novell probably didn’t bother writing a mini file system driver for the boot loader, and just relied on DOS for early file access.
(Yes, I am well aware NetWare eventually supported PAE)
NetWare would have run on Itanium with Project Modesto – which is also kind of unhinged if you look into it further. I think it’s got SLS, virtualization, etc. going on – a lot more than just a straightforward NetWare port!
I wounder if HP and Novell actually envisioned a real customer / use case for Novell under HP-UX?
Like either the clients would be “Netware-orientend”, just using file shares and whatnot, and then a regular PC would be a better choice as a Netware server.
Or the clients would be “Unix-orientend”, running some TCP/IP stack, and then a NFS client would probably had made more sense.
Are any copies of netware for HP-UX still available? It would be interesting to know if they did any cool integration between the Netware and UNIX world (except for obviously I assume using the file system of the UNIX host). Thinking about things like running typical “TCP/IP applications” over IPX.
Side track: A factor not mentioned enough, that probably killed the market for anything like that, was Windows for Workgroups. Not thinking about that the built in network stack itself killed a lot of competition, but the fact that any network protocols could run in 386 protected mode killed any need for “smart” stacks that preserved memory for DOS applications. Afaik Novells main selling point was how little RAM the client used. (Compare with for example the horrendous crimes against humanity like the Microsoft DOS TCP/IP stacks in their two different DOS SMB clients š )
Btw if HP and Novell would had wanted Netware 3 to be ported to newer versions of HP Unix, it would likely mostly had been a matter of recompiling it.
The likelihood of source code surviving and also surfacing is probably next to zero, but if the source code could be found it would probably not take that much work to port Netware 3 for HP-UX so it would compile and run on for example modern Linux.
You talk a lot about NetWare 2, 3 and 4 – which leaves the obvious question of NetWare 1. Did it ever exist? Has any of it (e.g. NetWare 86, 68, Advanced NetWare 1.x…) ever resurfaced?
There was supposedly Advanced NetWare 1.0 in 1985. It was preceded by NetWare 4.61. Yes, really.
NetWare 2.0a has been seen in various incarnations, but nothing older as far as I know. A few years back there were NW 4.61 floppies on eBay but I have no idea what became of them.
Is that an instance of the classic “let’s start at a high version number
so customers think we’re not wet behind the ears” trick…?
There mat have been Netware 1,2,3 etc. before that 4.61… 1980’s Netware was rather obscure and its early history might be lost.
Correction: “there might have been Netware 1,2,3…”
There were numerous NetWare 4.x releases prior to 1985 or 1986, likely including v4.0 circa 1984. 4.61 was the last (actually 4.61b perhaps), but there was also 4.6, 4.54, 4.53, 4.52, 4.51, and 4.5. Confirmed from old Novell tech notes. I believe 4.13 or so was also mentioned.
The upshot is that these releases must have been extremely short lived (1985 already saw Advanced NetWare 1.0) and probably shipped in minuscule amounts. Finding these mentioned in contemporary press is next to impossible; NW 4.61 is the only release that’s mentioned a handful of times. I believe the predecessor to the old NW 4.x was ShareNet 3.x.
By 1992, Novell more or less completely disowned NetWare versions older than 2.0. Likewise NetWare books from that era didn’t cover versions before NW 2.0.
Which also reminds me of NetWare 68 vs 86.
(NetWare 68 was designed around special 68000-based server hardware)
Damn, the early 80s was weird. ShareNet goes back to version 1.0 or is it not known? These all must have come out in just a two or three year period, and networking hardware of any type was rare in the PC industry in 1983 to 1985 so these may have only sold in tens or hundreds of units.
I have not seen versions of ShareNet other than 3.x mentioned… but that doesn’t mean much. At the same time, the guys who created ShareNet (that is, SuperSet Software) weren’t starting from scratch at Novell, so it’s possible 3.x was a more or less natural version number.
And yes, this all happened circa 1983-1985, LANs were exotic beasts, and the numbers sold had to be tiny.
Were these early ShareNet 3.x and NetWare 4.x for the MC68000 file server or for the PC, though? Is there any info on that?
The Wikipedia article on NetWare seems to suggest that the SuperSet guys started working on ShareNet for Motorola in 1981, but by 1983 they switched to the PC.
I’m not sure about ShareNet. I believe NetWare 4.x was for both 8086 and 68000, which continued until Advanced NetWare 2.1 or so.
I’ll also add that in 1981, SuperSet was not yet working for Novell.
The book “Accidental Empires” from Robert X. Cringely is a fun read but not exactly rigorous, I see it like what he saw and heard when he worked at InfoWorld, including rumors and tales, so is not lying, but it’s not rigorous history. I haven’t encountered something that validates this. This is part of what he said about Novell:
The company that absolutely controls the PC networking business is headquartered at the foot of a mountain range in Provo, Utah, just down the street from Brigham Young University. Novell Inc. runs the networking business today as completely as IBM ran the PC business in 1983. A lot of Novell’s success has to do with the technical skills of those programmers who come to work straight out of BYU and who have no idea how much money they could be making in Silicon Valley. And a certain amount of its success can be traced directly to the company’s darkest moment, when it was lucky enough to nearly go out of business in 1981.
Novell Data Systems, as it was called then, was a struggling maker of not very good CP/M computers. The failing company threw the last of its money behind a scheme to link its computers together so they could share a single hard disk drive. Hard disks were expensive then, and a California company, Corvus Systems, had already made a fortune linking Apple IIs together in a similar fashion. Novell hoped to do for CP/M computers what Corvus had done for the Apple II.
In September 1981, Novell hired three contract programmers to devise the new network hardware and software. Drew Major, Dale Neibaur, and Kyle Powell were techies who liked to work together and hired out as a unit under the name Superset. Supersetāthree guys who weren’t even Novell employeesā invented Novell’s networking technology and still direct its development today. They still aren’t Novell employees.
In 1981, networking meant sharing a hard disk drive but not sharing data between microcomputers. Sure, your Apple II and my Apple II could be linked to the same Corvus 10-megabyte hard drive, but your data would be invisible to my computer. This was a safety feature, because the microcomputer operating systems of the time couldn’t handle the concept of shared data.
What CP/M lacked was a facility for directory locking, which would allow only one user at a time to change a file.
The guys from Superset added directory locking to CP/M, they improved CP/M’s mechanism for searching the disk directory, and they moved all of these functions from the networked microcomputer up to a specialized processor that was at the hard disk drive. By November 1981, they’d turned what was supposed to have been a disk server like Corvus’s into a file server where users could share data. Novell’s Data Management Computer could support twelve simultaneous users at the same performance level as a single-user CP/M system.
Superset, not Novell, decided to network the new IBM PC. The three hackers bought one of the first PCs in Utah and built the first PC network card. They did it all on their own and against the wishes of Novell, which just then finally ran out of money. The venture capitalists whose money it was that Novell had used up came to Utah looking for salvageable technology and found only Superset’s work worth continuing. While Novell was dismantled around them, the three contractors kept working and kept getting paid. They worked in isolation for two years, developing whole generations of product that were never sold to anyone. The early versions of most software are so bad that good programmers usually want to throw them away but can’t because ship dates have to be met. But Novell wasn’t shipping anything in 1982-1983, so early versions of its network software were thrown away and started over again. Novell was able take the time needed to come up with the correct architecture, a rare luxury for a startup, and subsequently the company’s greatest advantage. Going broke turned out to have been very good for Novell.
By this time Novell had a new leader in Ray Noorda, who’d bumped through a number of engineering, then later marketing and sales, jobs in the minicomputer business. Noorda saw that Novell’s value lay in its software. By making wiring a non issue, with Novell’s softwareānow called Netwareāable to run on any type of networking scheme.
AFAIK 1983 is when the PC/XT was released that supported a hard drive.
Elsewhere I read that it was Noorda (who’d been brought in to save the company and turn it around) deciding to go with networking and ditching the hardware.
This seems reasonably well researched: https://www.abortretry.fail/p/the-history-of-novell
@Yuhong Bao:
Yes, but there were already PC clones with hard disks before that; plus, the IBM PC itself (IBM 5150) could be modded to support a hard disk, even in a way supported by IBM.
I read somewhere that the SuperSet guys met Noorda at COMDEX 1982, and impressed him enough with their work so he decided to join the failing company.
@Yuhong Bao:
In particular the important part was being able to connect to a file server, not add additional disks. I.E for the most part hard disk support in the PC and DOS was irrelevant (on the client side). Not sure when diskless booting became a thing for Novell but that could had been implemented by emulating floppies rather than hard disks. Not that that would had made much difference, but still. (The major thing lacking in the original PC BIOS was afaik not supporting automatically running option card BIOSes).
=============================
I wounder if and when Novel realized that they wouldn’t last much longer?
Like the thing they did and did good was writing a file system that allowed multiple access, something that most or perhaps all single process operating systems lacked at the time. Soon regular operating systems for desktop computers started having that. The only thing left they really had was a great reputation and a directory service thingie. When did they realize that they were doomed?
@MiaM, on loading option ROMs: medidn’t know the original IBM PC didn’t
detect them. That does strengthen me theory that such “ROM”s used to be
loaded from floppy during development.
Yet the release of IBM PC/XT was important for NetWare as a target where the server system could be installed. I can imagine that after their first attempt with the 68000 server machine, they decided to no longer use proprietary hardware designs.
IMHO, NetWare never lost their file server crown. Microsoft’s OS/2 1.x could do file server, but was generally inferior to contemporary NetWare. Windows for Workgroups 3.11 and Windows 95 were so pathetic, that MS promoted them as “peer to peer networking”. Windows NT was much hyped, and we at our shop decided to replace a couple of installs of NetWare 3.x and NetWare 4.x with Windows NT 4. A big mistake! Regardless of all our attempts to optimize it, the Windows server was just sloooow, if reliable. I later conducted similar tests with Windows 2000 and XP, to no better results And with Vista and beyond to file server performance of Windows only deteriorated further. NetWare remained the eternal king of the file servers.
What killed NetWare IMHO, was the industry’s shift to application servers. While NetWare could do application servers, using NLMs and whatnot, NetWare was at its core a file server, and application servers were an afterthought, while Windows NT and Linux were optimized for them since day one. And the cooperative multitasking of NetWare processes didn’t help, either. NetWare struggled for a time, but the writing was on the wall.
@vbdasc
Windows 3.x and Windows 4.x (95, 98, ME) networking never ever was meant to be used to serve file or printer service, but as a meant to share files and hardware on very small peer networks, similar to Apple’s AppleShare. That’s was the vision BillG had as part of the initiative “Windows Everywhere” ™. Not only it is limited in the number of concurrent user/connection count, but also all the permission stuff is designed to look and behave like Apple’s. It is even written as ad in the resource kit books of these OSs.
About Netware’s file/printer sharing performance, well… That’s what happens when you run every module (protocols, disk and FS drivers) at ring0, in cooperative multitasking mode. But more important than that, is using SPX/IPX as the backbone of their protocol stack. It is very lightweight and basically designed for fast raw data packet transmission (as opposed to a roaming world-wide application servicing packet
stack like TCP/IP), with the drawback it is mostly un-routable. That’s why back then you had 2-tier staggered intranets managed by cisco hardware. SPX/IPX is the core of the speed of Netware, and if you move it to TCP/IP, it looses almost half of the speed you get in a full classic Netware configuration. That’s why Novell Services on Linux didn’t saved Novell and Netware from falling. And this is why today, when you need full networking speed for raw data transmission (like file or even logical data block transmissions) you try to ditch specific TCP/IP layers or the whole protocol altogether, as with Infiniband or X-over-ethernet style (and sometimes propietary) smaller protocol stacks.
I believe it was NetBEUI that was unroutable.
@Yuhong Bao:
Yes, the NetBEUI (properly named NBF) is a simple and unroutable protocol. Its unroutability stems from the fact that a NBF frame itself holds no address information except some NetBIOS names, which are unresolvable across broadcast domains (but resolvable within a broadcast domain, using, of course, broadcasts). Yet even such a simple protocol with almost no overhead didn’t help my NT 4 machines compete against Netware speed. A NT 4 network with NetBEUI was a couple of percents faster than with TCP/IP, that’s all.
The IPX/SPX protocol is “routable” with more address info and routing protocols defined, although in most cases, Netware servers play the role of actual routers.
The TCP/IP is the most easily and naturally routable.
When Novell nearly went bankrupt in the early 1980s, they decided to get away from making hardware and focus on software. They did make detours into hardware, like the NE1000/NE2000, but even that was something Novell didn’t actually manufacture themselves. Novell actually continued to make 286-based and I think even 386-based file servers for a while, but it was likely also rebadged hardware made by someone else.
Agree that application servers (especially web servers) killed NetWare. It’s not that NetWare can’t do it, but everything is just a bit too different on NW.
@raijinkai:
Well, Windows for Workgroups 3.11 could more or less max the performance of a 3C509 network card on a tired 386SX computer, so I wouldn’t say that the performance was bad.
The reason for lack of access control and whatnot was probably twofold. For one Microsoft wanted customers to pay much more for NT. But also the access control on the file server part of NT relies on the operating systems built in account management and the file systems access control. I would think that they more or less just ported the file+printer server part from NT to Windows for Workgroups and later then 95/98/ME series, and added the absolute minimum (one user name + one access mode per share) to make it usable.
I wounder if it might even had partially been a skunkworks project to some extent? I.E. they would anyway had wanted to port the NT network client to Windows for Workgroups, and then someone might had realized that it wasn’t much more work to also port the server? The existence of “Windows for Workgroups for DOS” speaks against this though.
re Novell on Linux: Interestingly there were/are IPX/Novell compatible server thingies for Linux IIRC, but I don’t know how good/bad they are.
re performance of TCP/IP: Sure TCP has some overhead, but UDP has more or less zero overhead as compared to simpler protocols and thus using IP can’t really explain loss of performance.
@vbdasc:
It’s interesting that it seems like noone made any attempts at “routing” NetBEUI. Like Netbios names could had been treated the same way as MAC addresses are treated by network switches, kind of. I.E. make some sort of netbios name cache that would only let the broadcasts through everywhere if it didn’t already know which MAC address a certain netbios name was on.
=============
@all:
A) I’ve brought this up over and over, but still: It would be really nice for the vintage PC / DOS / Windows community if someone had a real go at bringing the NetBIOS patches to SAMBA going either on any SAMBA version or preferable on a modern version of SAMBA.
B) I think that a major problem with application servers on Netware was that they most likely charged an arm and a leg for everything needed to develop such servers. Meanwhile you could at least learn a lot of the needed skills for developing Windows application servers using cheaper tools (i.e. any C compiler and really any version of Windows although NT would be preferable). And on Linux all tools and documentation is/was free (and the source code available for most things, acting as great examples).
Sure, some application servers were made by large corporations but they would kind of have to have their developers learn making Netware application servers in-house while for most other platforms it would had been easy to hire people who already had most skills.
You’ve got that quite backwards. Nobody was porting the NT file sharing to DOS. Microsoft had DOS based file and print sharing since 1984-85, in the form of MS-NET. That evolved into the LAN Manager client and later the Microsoft Network Client. And MS-NET never had any kind of fancy user or rights management.
The IBM PC LAN Program (first released in 1985) already allowed DOS machines to share files, and AFAIK MS-NET could do the same. WfW was absolutely nothing new.
What kind of NetBIOS patches to Samba do you have in mind?
@MiaM:
About “routing” NetBEUI: Yes, such an “auto-routing” scheme would be possible in principle, if not for one big flaw of NetBIOS names , which is absent in their counterparts, the IP and IPX addresses: They can’t be guaranteed to be unique. An administrator must ensure that there are no conflicting names on the network. This is not scalable and generally not workable.
The IPX address contains the MAC address and the “subnet number” as subfields. This ensures uniqueness and allows reasonable “auto-routing” by Netware servers and large IPX networks without broadcast storms. The NetBEUI protocol was never designed for that.
NetBIOS machines also can have multiple names, including group names. In the NetBIOS usage, names are really meant to identify services, not machines.
Interesting enough, most of the NTLanman code, if not all of it, comes from 3com’s own SMB implementation. Leaked sources show 3com copyright notices sparkled all over the place in the SMB kernel modules and their corresponding usermode libraries (RDR, SRV, WKSSVC and SRVSVC).
As the ice of the cake, MS also bought from them the DHCP/PXE stuff. Don’t remember if the DNS server also comes from 3com.
@Michal:
Sure, they had DOS network software long before NT. (For some weird reason they even had two different SMB clients for DOS, of which one can do TCP/IP on any PC while TCP/IP requires at least as 286 on the other client).
But afaik with the right configuration of Windows for Workgroups (at least 3.11) every part of the networking runs as 32-bit code, which makes me think that that code is (partially) shared with NT rather than the older DOS networking software. (Sure, the instealler really wants to start some DOS stuff in autoexec.bat but that can be commented out and the networking will work great in Windows anyways)
Btw are there any known source code leaks or similar for Windows 3.x or even 9x/ME?
@raijinkai:
Interesting.
Side track anecdote: practical studies show that if you connect an old 3Com 3server3 (i.e. the older one before the 386 based servers) to a network that also has a Windows 2000 computer running NetBEUI, the 3server3 will access it’s hard disk constantly for a while, and then end up in a non-bootable state. Ooops…
@MiaM:
There were more than two SMB clients for DOS from Microsoft; some of them had also server capabilities
http://www.jacco2.dds.nl/samba/dos.html
Windows 3.11 for Workgroups almost certainly shares networking code with Windows 9x, but with Windows NT… unlikely. If I’m not mistaken, VxDs were written in assembly language, and the 32-bit WfWG3.11 networking code was in the form of VxDs, while Windows NT was written in C, to be portable across architectures.
@vbdasc:
For some reason it seems like that site is currently down. Shortcut to archive . org for anyone else who want to take a look:
https://web.archive.org/web/20240514062833/jacco2.dds.nl/samba/dos.html
That is a really great site btw!
Anyways, what I meant to write is that Microsoft made two clients for DOS, while there were several others too.
Good point about C v.s. Assembler. So it’s not that likely that the code was shared. But anyways it was most likely new code for WfWG3.11 rather than reused DOS code. Also it’s at least not totally unlikely that either of the WfWG3.11 or NT code was written by looking at the other of those two, even though one of them was written in C and the other in assembler. Also as a rule of thumb you can do almost everything in C that you can do i assembler, except that depending on the compiler and architecture you might need some glue written in assembler if the calling convention don’t match what the C compiler is set up for.
@Michal:
Forgot this while writing my last comment:
I’m thinking about the NetBEUI patch to Samba that some company made and published as least-possible-effort-open-source, i.e. just the changes/add-ons to the source code without much of hints on which version of Samba and whatnot is required to apply the patches and make it build a working binary.
They have been around for perhaps 25 years or so, and it seems like no-one with enough skills has made any effort to make it work. I’ve had a look at it one or two times over the years but came to the conclusion that it’s a bit too much for me to take on.
Sure it’s perhaps not the 100% coolest thing in the world to be able to share files (and printers) using NetBEUI from a modern Linux computer to vintage computers, but it would be cool as iirc the SMB clients are a bit less memory hungry and a bit faster on slower computers when using NetBEUI than TCP/IP.
(I remember getting an abysmal 30-40kbyte/s or so on a 4.77MHz 8088 using the one of the Microsoft clients that can do TCP/IP on an 8088)
@MiaM:
“Iām thinking about the NetBEUI patch to Samba that some company made”
The company is named Procom (www.procom.com) and it published NetBEUI patches to Linux kernel and Samba in 2001, but thanks to the hare-brained way of distributing them, even the Web Archive is of no help for obtaining them (you want to download the NetBEUI patches, if I’ve understood correctly). They have surely been downloaded many times and are languishing on people’s hard disks, but this doesn’t help. All in all, it seems that many people talk about these NetBEUI patches, with they’re rather hard to find.
However, it seems that a kernel developer, Arnaldo Carvalho de Melo, a.k.a. ACME, took an interest in NetBEUI for a time, and as a result, his page at kernel.org contains some patches that might work for an old kernel and old Samba:
https://cdn.kernel.org/pub/linux/kernel/people/acme/old/netbeui%2Bllc/
Just install an old Linux in a virtual machine, apply these patches and serve you Dos clients š
But if virtual machines are to be used, you might be better off with a Windows XP install in the VM instead (it still supports NetBEUI, with some light hack)
IIRC in NT4 NetBEUI was fully supported, in W2K you had to hunt for it in some extra directory on the install CD, and in XP you could still install the one from W2K.
I agree that running old NT is far less complicated and far more likely to work well than patching some antique Linux.
@vbdasc:
Cool project!
Don’t know how much the Linux kernel has changed, but it can’t be that hard to either apply those patches to the kernel, or possibly do some user mode stuff (can’t remember if root is allowed to send arbitrary network packages – root is for sure allowed to listen to anything as otherwise tcpdump and whatnot wouldn’t work).
The beauty of running it on a Linux computer (or for that sake any computer that you use for “modern” stuff) is that the shared files can exist within your “normal” file system.
Not sure what NT, W2k or XP allows but using them in a virtual machine would really need a setup where they act as a SMB client over TCP/IP to the host (or use some trick within the virtualization to access host files directly) and share them over NetBEUI.
Thanks for the pointer to Procom. Btw I wounder what would happen if somone contacts them and say that they have their product that uses their code, and request a copy of the code. Maybe they will charge a gazillion or send it out on the most uncommon storage format ever, or maybe they might just send an email.
Either way, maybe @Michal could put those files in the “wanted” section on this blog?
P.S. I’m perhaps extra weird among all weird people who are into vintage computers, but I kind of enjoy the thought of using unusual setups for networks and whatnot, like netBEUI under Linux. As a side track to this side track, a cool but not that useful addition to Samba would be to make it able to use DECNET.
Side track on this side track:
Seems like DECNET support was finally dropped in the Linux kernel only two years ago. I remember that it has been suggested to remove it several times before but that was due to “no development” and an assumption that no-one uses it, but people complained as people used it and the Kernel part didn’t need any updates for many years as it just worked.
Feels a bit weird that they removed that part that at least is actually easy to verify that it works, while probably keeping support for various weird hardware that no-one has any proof of that the drivers still works for. š
Another side track:
Seems like IPX nowadays is a separate module for Linux. It would be somewhat cool if Samba would support that too š
https://github.com/pasis/ipx
https://www.theregister.com/2022/08/03/linux_may_soon_lose_support/
Nothing is ever that hard as long as someone else does it š
It was XP that got rid of NetBEUI by default.