Sometimes I have the following problem to deal with: An OS/2 system uses NetBIOS over TCP/IP (aka TCPBEUI) and should communicate with a SMB server (likewise using TCPBEUI) on a different subnet. This does not work on OS/2 out of the box without a little bit of help.
History and Technology
NETBIOS (originally literally the ROM BIOS on the 1984 IBM PC Network adapter) was designed to work on a LAN, specifically a single LAN segment. There is no need for centralized infrastructure, workstations can come and go. This makes using ad hoc networks very easy and does not require additional dedicated infrastructure and administration.
When NETBIOS (or NetBIOS) moved to Ethernet, there were initially many different ways of implementing it. Eventually the world settled on NetBIOS Frames aka NBF.
But in the 1980s, there was also a parallel effort to move NetBIOS on top of TCP/IP, eventually standardized as RFC 1001 and RFC 1002 (both dated March 1987). This effort was originally driven by non-PC platforms, but soon enough DOS-based (e.g. HP ARPA Services circa 1990, PC/FTP likely earlier) and OS/2-based (MS LAN Manager 2.1 in 1991) implementations of NetBIOS over TCP/IP became available.
As mentioned above, classic NETBEUI (whether using the original IBM PC Network Adapter, Token Ring NETBEUI, the NBF protocol, or some other variant of NetBIOS over Ethernet) always resolves names using broadcasts. When a workstation (i.e. a NetBIOS application running on that workstation) looks for a NetBIOS “name”, it uses a broadcast to find out the network address of the machine which owns that name; this is not unlike ARP.
Note that NetBIOS names are labels for various resources or “objects”. A workstation or a server has a NetBIOS name, a logged-on user has a NetBIOS name, a workgroup or a domain has a NetBIOS name.
When a client machine wants to use the resources of a server, it needs to resolve the NetBIOS name. With NetBIOS over TCP/IP, broadcasts can also be used. A so-called B-Node (Broadcast Node) is a machine with an IP address which resolves NetBIOS names purely using broadcasts. Just like the original NetBIOS, such a network is limited to a single LAN, or more specifically a single IP subnet.
Another kind of node defined in RFC 1001 is a M-Node, or Mixed Node, which can use broadcasts to communicate with NetBIOS applications on the same subnet, but also use NetBIOS Name Servers (NBNS) and NetBIOS Datagram Distribution Servers (NBDD) to extend the reach across multiple subnets. This obviously requires additional infrastructure in the form of NBNS and NBDD servers.
The NBNS architecture solves much the same problem as DNS. An NBNS implementation can be centrally controlled, but it can also be loose and allow NetBIOS names to be registered and unregistered freely.
There are also P-Nodes (Point-to-point Nodes) designed for dial-up connections; these are no longer relevant.
As a side note, RFC 1001 also defines the concept of a NetBIOS scope. This is not often used, but a NetBIOS scope allows separate logical NetBIOS networks to exist on a single TCP/IP network. Only machines with the same NetBIOS scope identifier can “see” each other. This is handled on the NetBIOS over TCP/IP protocol level and is transparent to NetBIOS applications.
While NBNS allows NetBIOS over TCP/IP to function across large networks, it doesn’t work with B-Nodes, requires additional infrastructure, and therefore users may wish to avoid it. More about that later.
From NETBEUI to TCPBEUI
In the PC space, Microsoft drove the switch from the NetBIOS Frames protocol to NetBIOS over TCP/IP. In Windows XP, NBF support took extra effort to install and in Windows Vista it was dropped altogether.
On the OS/2 side, NetBIOS for TCP/IP was initially available with Microsoft’s LAN Manager. When IBM took over OS/2 networking, things were initially rather complicated. IBM’s LAN Server and the LAN Server clients only supported the NBF protocol out of the box. However, IBM’s separate TCP/IP product offered an add-on NetBIOS kit. With the kit in place, a LAN Server client could use the classic NETBEUI, or NetBIOS over TCP/IP, or both.
LAN Server 4.0 integrated NetBIOS over TCP/IP support. Instead of requiring a separate IBM TCP/IP product with an add-on NetBIOS kit, a new implementation called TCPBEUI was now part of the Multi-Protocol Network Support (MPTS), alongside the classic NETBEUI.
Starting with OS/2 Warp Connect, the LAN Server client, TCP/IP, and TCPBEUI support were all shipped with the OS. When using the advanced install path of Warp Connect, users were confronted with the following dialog:
Note that the radio buttons are misleading because selecting NetBIOS over TCP/IP results in both NETBEUI and TCPBEUI installed.
The IBM OS/2 TCPBEUI support consists of two core components, TCPBEUI.OS2 and NBTCP.EXE. TCPBEUI.OS2 is an NDIS driver which plugs into the NDIS Protocol Manager (PROTMAN.OS2) and handles most of the NetBIOS protocol. It is configured through the PROTOCOL.INI file, which is typically located in the C:\IBMCOM directory.
The NBTCP.EXE component is a daemon which implements the actual NetBIOS over TCP/IP protocol and handles the TCP/IP configuration and name resolution. Both are required for TCPBEUI to function.
Helping TCPBEUI with Name Resolution
From the earliest days, there have always been some methods to assist the NetBIOS over TCP/IP name resolution. If all you need is connecting to one or two machines on a different TCP/IP subnet, then setting up NBNS is probably an overkill.
Note that the following screenshots are from OS/2 Warp Connect. It is assumed that the Warp Connect system has TCPBEUI installed and that TCP/IP is functional.
The IBM TCPBEUI offers a way to define NetBIOS name to TCP/IP address mapping. There is a GUI method accessible through the MPTS/LAPS configuration interface. To change the configuration, the user needs to select the IBM OS/2 NETBIOS OVER TCP/IP protocol and hit the Edit button:
This leads to a fork in the road:
The Names list interface allows adding the actual names:
The NetBIOS names may need to be entered in all caps to be safe. Each NetBIOS name must correspond to either an IP address or a host name resolvable through DNS.
Note: As the dialog hints, the name entered by the user is a NetBIOS name prefix. This is because NetBIOS names that need resolving often have a one-byte binary suffix. The prefix is meant to act as a kind of wildcard and match NetBIOS names regardless of the suffix. This avoids the need to enter all the required permutations of a NetBIOS name, which are far from obvious.
On the TCP/IP side of things, the name may be resolvable through a DNS server, but it can also be configured locally in the HOSTS file (usually in C:\MPTN\ETC\HOSTS). Or, as noted above, an IP address can be used directly instead of a host name.
The NetBIOS name to host machine mappings are stored in a file called RFCNAMES.LST, normally stored in the C:\IBMCOM directory. Note that RFCNAMES.LST is a standard text file and can be edited with a text editor. If the file is changed, the rfcaddr.exe utility (also in C:\IBMCOM) must be run to update the running NBTCP.EXE instance. NBTCP.EXE also reads RFCNAMES.LST on startup.
Setting up this configuration comes with a big caveat. For whatever reason, IBM left a nice trap for the unwary. By default, NBTCP.EXE allocates enough space for zero RFCNAMES.LST entries. In other words, RFCNAMES.LST will be silently ignored.
To avoid this problem, it is necessary to change the “Maximum number of name-ip address pairs in names file” in the MPTS configuration interface to some reasonable non-zero value:
The setting is stored in PROTOCOL.INI. Instead of using the configuration GUI, users can also edit PROTOCOL.INI directly, changing the value of the NAMESFILE keyword in the [tcpbeui_nif] section. Changing the setting requires a reboot, because PROTOCOL.INI is only processed on startup.
NetBIOS Names as DNS Names
Most versions of the IBM protocol stack support an alternative method of NetBIOS name resolution which could be attractive in some setups but is extremely cumbersome. It is possible to use DNS to resolve RFC-encoded NetBIOS names.
A NetBIOS names is a sequence of 16 bytes (all bits are significant, hence the names need not be printable). RFC 1001 defines a method for converting a 16-byte NetBIOS name into a string of 32 ASCII characters. The ASCII encoding can be converted back to a 16-byte NetBIOS name. The ASCII name is defined such that it is also a valid domain name.
Using the example from RFC 1001, the NetBIOS name ‘FRED’ will be encoded as ‘EGFCEFEECACACACACACACACACACACACA’ — which, although extremely ugly, is a valid DNS name.
It is possible to set up DNS alias records which map these RFC-encoded names to IP addresses. When TCPBEUI tries to resolve NetBIOS names, it can RFC-encode them and then use standard TCP/IP name resolution. The downside of this scheme is that it requires control of DNS, and that for every machine several NetBIOS names with different last bytes must be registered. For example, for a SMB domain server, four RFC-encoded DNS entries would be needed.
Newer Windows versions support a radically simpler scheme, where the NetBIOS name is resolved as a DNS name without any encoding. This is not a generalized scheme, because NetBIOS names are not necessarily valid DNS names. However, if the OS only accepts machine names that are valid DNS names and at the same time valid NetBIOS names, this scheme works.
This scheme was introduced in Windows NT 4.0 (but not enabled by default; the details are complicated) and was used by default on Windows 2000 and later. IBM implemented it in Convenience Package 2 (MCP2/ACP2); it is detailed in README.ADD on the installation CD-ROM, in a section titled “TCPBEUI Unencoded Name Lookup on Domain Name Server”.
For whatever reason this capability is not enabled by default on OS/2. It is controlled by the ENABLEDNS keyword in the [tcpbeui_nif] section of the PROTOCOL.INI file. Also note that unlike Windows NT 4.0 and later, OS/2 does not support using IP addresses in place of machine names.
When ENABLEDNS = 1, TCPBEUI first tries to resolve RFC-encoded names, then DNS names. When ENABLEDNS = 2, TCPBEUI tries to resolve DNS names first, then RFC-encoded names. By default, ENABLEDNS = 0 and no unencoded name resolution takes place.
Worse yet, there is yet another catch. Setting ENABLEDNS to a non-zero value is not enough to enable DNS lookup. The capability is firmly tied to the lookup of RFC-encoded names (because that will be done either before or after looking up RFC-unencoded names). And lookup of RFC-encoded names is enabled by setting the “NetBIOS Domain Scope String”, which corresponds to the DOMAINSCOPE keyword in the [tcpbeui_nif] section of PROTOCOL.INI.
Note: The “NetBIOS Domain Scope String” is a DNS suffix. If a server has a domain name mysmb.domain.net, then the domain scope string should be ‘domain.net. When TCPBEUI looks up the NetBIOS name “MYSMB”, it will automatically add a ‘.domain.net’ suffix before resolving the name. The “Local NetBIOS Name Scope String” is completely unrelated—it has nothing to do with DNS and it enables the creation of multiple logically separate NetBIOS networks on top of a single TCP/IP network (as defined by the RFCs). The local NetBIOS scope is almost always empty; if you don’t know exactly what to set it to, you need to not set it.
The unencoded DNS name lookup fairly similar to what Windows does. The difference is that on Windows, no manual configuration is usually required; Windows (specifically Windows 2000 and later) performs the unencoded name lookup by default, and queries the DNS suffix through DHCP.
On OS/2, there is no built-in capability to set the TCPBEUI NetBIOS Domain Scope String based on DHCP options, although it is possible to write custom scripts to get the options from DHCP, rewrite PROTOCOL.INI, and reboot the machine. Such an approach in outlined in the Beyond DHCP Redbook.
Debugging
In TCPBEUI shipped with OS/2 Warp 4 and later, it is possible to get limited debug output from NBTCP.EXE by adding a DEBUGNBTCP = “YES” keyword in the [tcpbeui_nif] section of PROTOCOL.INI. This causes NBTCP.EXE to print debugging information to the screen. For this capability to be useful, NBTCP.EXE must be started after the OS boots up and not through a RUN= statement in CONFIG.SYS. This is no problem as long as NBTCP.EXE starts before the LAN Requester.
Note that NBTCP.EXE can also be started with the /d parameter to enable debugging, but the debug setting is soon overridden by the DEBUGNBTCP value from PROTOCOL.INI… which defaults to disabled. And which itself appears to be deleted when the MPTS configuration GUI is used.
Summary
There are two ways of configuring OS/2 TCPBEUI to find servers on a separate TCP/IP subnet in the absence of a dedicated NetBIOS name server. The first method works on OS/2 Warp Connect and later and requires the following:
- Add a NetBIOS name and hostname (or IP address) pair for each machine to the \IBMCOM\RFCNAMES.LST file, either using a text editor or the MPTS GUI interface
- Set the maximum number of entries in the names file to a sufficiently large non-zero value, either by using the MPTS GUI interface or modifying the
NAMESFILEkeyword in the [tcpbeui_nif] section of PROTOCOL.INI
The advantage of this method is that it works with old versions of TCPBEUI. The names list can also be dynamically updated with the help of rfcaddr.exe. The disadvantage is that every machine on a different subnet must be manually added to RFCNAMES.LST.
The alternative method only works on Convenience Package 2 and requires the following:
- Enable unencoded DNS name lookup, either in the MPTS GUI interface or by setting the
ENABLEDNSkeyword in the [tcpbeui_nif] section of PROTOCOL.INI to 2 (or, in an unlikely case, to 1) - Enable DNS name lookup by setting the NetBIOS Domain Scope String, either in the MPTS GUI interface or by setting
DOMAINSCOPE = "my.domain.net"(as appropriate) in the [tcpbeui_nif] section of PROTOCOL.INI
This newer method has the advantage that machine names do not need to be added manually, but the name resolution only works as long as all machines have the same domain name suffix. And, obviously, the DNS names must match NetBIOS names, although that is typically the case already.
Addendum: IBM TCP/IP 2.0 NetBIOS Kit
As mentioned previously, things looked a little different before LAN Server 4.0 and Warp Connect. The standard LAN Server 2.0/3.0 client only supported NETBEUI, and to get NetBIOS over TCP/IP support, one had to acquire the IBM TCP/IP base kit (1.2.x or 2.0) as well as an add-on NetBIOS kit. It is described in some detail in an IBM Redbook, TCP/IP 2.0 for OS/2 Installation and Interoperability. The Redbook refers to the older implementation as TCP/NetBIOS; this convention will be adopted here to distinguish between TCP/NetBIOS and TCPBEUI.
The old TCP/NetBIOS implementation was structured differently from TCPBEUI; there was only a small kernel driver (NBDRIVER.SYS) and almost everything else (notably all interfacing with TCP/IP) was done in the NBTCP.EXE process. This necessitated relatively high context switch overhead and IBM claimed that the newer TCPBEUI was about twice as fast as TCP/NetBIOS.
TCP/NetBIOS also took over NetBIOS functionality completely. Although the LAN Requester/Server could use dual NETBEUI and TCP/NetBIOS protocol stacks, NetBIOS applications had to use TCP/NetBIOS only.
Although TCP/NetBIOS had much the same capabilities as TCPBEUI, it was configured quite differently. It was not configurable through the MPTS interface at all; instead, command line parameters had to be passed to NBTCP.EXE. Additionally, NBTCP.EXE was not started from CONFIG.SYS but rather from STARTUP.CMD or possibly some other script executed after TCP/IP was brought up; therefore the TCP/NetBIOS configuration effectively resided in that script file.
TCP/NetBIOS supported much the same names and broadcast list files as TCPBEUI, but the locations and names of the files were not predefined. The full pathname was simply passed to NBTCP.EXE through the -n (names file) and -b (broadcast file) arguments.
The syntax was also slightly different—TCP/NetBIOS does not expect NetBIOS names to be enclosed in double quotes.
NBCP.EXE might be started as follows, after TCP/IP is already running:
START NBTCP -n C:\NAMES.LST 10.0.2.15 255.255.255.0
Note: The old NBTCP.EXE has a -d (debug) switch which does not match documentation. Or at least in the version of NBTCP.EXE shipped with CSD UN09313 it doesn’t. The -d switch expects an argument which appears to be a mask of debug flags controlling what gets written into an nbtcp.trc file. Passing -d ALL to NBTCP.EXE should log all possible messages.
And one more caveat: If the old NBTCP.EXE is not passed the local machine’s IP address correctly, the LAN Requester may fail to start with “duplicate network name” errors. However, when it is configured properly, TCP/NetBIOS plus the LAN Requester from LAN Server 3.0 can connect to SMB servers using NetBIOS over TCP/IP.
“When NETBIOS (or NetBIOS) moved to Ethernet, there were initially many different ways of encapsulating it. Eventually the world settled on NetBIOS Frames aka NBF.”
I’m sorry for possibly derailing the discussion, but does anybody know what were these different ways? I mean, after IBM introduced NetBEUI for Token Ring in 1985, which used the standard NBF over 802.2 LLC and the IEEE 802.3 standard for Ethernet was published the same year, mandating 802.2 framing, there was only one obvious way to implement NETBIOS over the Ethernet without assistance of a transport protocol, and it was NBF.
Add to this the schemes where NETBIOS was piggybacked on IPX/SPX or TCP/IP, and we get the triad of standard network transports capable of carrying SMB which were the available choices in Lan Manager, MS Network Client for DOS, Windows 95, Windows NT, network-enabled versions of OS/2 Warp etc. – NBF (mislabeled as NetBEUI), TCPBEUI and NBX.
Were there others? I guess, NETBIOS can be carried over raw DIX Ethernet frames (there are assigned EtherTypes for it), but I doubt somebody really implemented that.
At least one other major implementation was NetBIOS over 3Com’s XNS. And Microsoft used to support NetBIOS on top of DLC.
Why so many variants… beats me. However, one factor was almost certainly the fact that in those times (1986-ish) IBM did not really support Ethernet. If IBM rolled out NBF on top of Token Ring and Ethernet right away, there would probably be no question. But that’s not at all what happened, IBM really dragged their feet on Ethernet support, which meant that companies like 3Com or Ungermann-Bass had to come up with something. And there was probably no strong technical reason for them to pick 802.2 LLC over whatever other approaches they could come up with.
Well, 3+Share XNS NETBIOS is piggybacked on XNS, so it’s just like NETBIOS over IPX/SPX. The existence of piggybacked implementations of NETBIOS is completely logical – if you have some transport protocol and want to support NETBIOS, you piggyback it.
This MS DLC has always baffled me. IMHO, It is probably some modified version of 802.2 LLC, enhanced in some aspects (full HDLC support or SDLC compatibility?, vehicle of SNA) and restricted in others (incapable of carrying SMB), and promoted to a protocol (802.2 LLC isn’t considered a protocol without its NETBIOS layer). Of course, I could be completely wrong.
But yes, I suppose MS DLC NETBIOS could probably be considered a form of “NETBIOS over raw Layer 2 Ethernet”, just like NBF. Although the two implementations were probably very close (my guess). The strange term “NETBIOS over raw Ethernet” means NETBIOS not piggybacked on any Layer 3+ protocol.
Banyan VINES supported NetBIOS over VINES-IP, which worked on any VINES supported NIC (or even a PC connected via a dial-up link). The DOS client required an additional TSR to add NetBIOS support, whilst OS/2 used extra drivers.
Name resolution was performed by a NetBIOS Naming Service which mapped NetBIOS names to VINES-IP addresses. More than one NetBIOS Naming Service could be created per server, allowing mutliple NetBIOS networks. A command in the user profile, SETNETB, denoted which naming service to use.
This meant that users on different LAN segments (or even different locations) could communicate via NetBIOS.
Interesting history and whatnot!
I didn’t know that the initial 1984 IBM PC Network adapter used it’s own standard, not compatible with either Token Ring or Ethernet (or any of the other standards like Arcnet).
“This effort was originally driven by non-PC platform” <- Which non-PC platforms were interested in NetBIOS at all? Or do you consider for example the 3Com server hardware a "non-PC platform"? (Technically that is correct, but I would call it an "almost-PC platform" as it can even boot DOS (IIRC) but uses an interesting remote console protocol where the remote console is not only used for keyboard/screen but also as a remote floppy drive). I doubt that the workstation/UNIX market and whatnot were interested in NetBIOS, or?
Btw, re methods to transport NetBIOS – the one method not mentioned in this discussion is over DECNET.
It's okey if you all think that I'm weird, but I think that NetBIOS over DECNET gets too little love from the vintage computing/networking enthusiasts.
@MiaM:
Well the PC Network adapter indeed was neither Ethernet, nor Token Ring, nor any other networking standard. It had unique physical layer (although it came in several variants) and an unique data link layer. Sadly, it doesn’t seem that much documentation about it has survived, although at least the frame format is more or less described in some IBM documents.
Back then, NETBIOS was needed to implement SMB, and I believe on the Unix side at least HP was interested in implementing SMB (and hence, NETBIOS over TCP/IP).
I also believe that DEC too was interested in implementing SMB (and eventually they created PATHWORKS), and that’s the reason for NETBIOS over DECNET.
I wouldn’t consider 3Com servers “non-PC”. The actual RFC offers the following rationale:
NetBIOS has generally been confined to personal computers to date. However, since larger computers are often well suited to run certain NetBIOS applications, such as file servers, this specification has been designed to allow an implementation to be built on virtually any type of system where the TCP/IP protocol suite is available.
That of course doesn’t tell the whole story. Were the “larger computers” unable to communicate using some form of raw NetBIOS? Were the PCs intended to run TCP/IP instead?
There were definitely several UNIX-based LAN Manager implementations (LM/X). And one of the companies behind the RFCs was Excelan, which offered things like this: https://www.techmonitor.ai/hardware/excelans_tcpip_package_for_xenix_allows_communication_with_alien_systems
DECNET is probably too dead, not unlike VINES. Never hugely widespread, gone for too long.
Thanks! I actually knew that VINES supported NetBIOS, but forgot. Now I wonder how widely VINES workstations also used NetBIOS, given that VINES-IP itself didn’t use or need it.
Yes, HP was one of the companies which offered UNIX-based LAN Manager servers and also provided a TCP/IP stack for DOS machines (HP ARPA Services). A subset of the HP TCP/IP stack for DOS was adopted by Microsoft for their NetBIOS over TCP/IP support on DOS.
Little extended topic:
SMB first implemented over NetBIOS, but later made to run over naked transport protocols (in Windows first IPX/SPX then TCP/IP AFAIK). Is OS/2 supported this in any version?
@SweetLow:
Well, SMB can run either over NBT (NetBIOS over TCP/IP, a.k.a. TCPBEUI using port 137/138/139) or directly on TCP (using port 445).
@Michal:
I had a look at Decnet for DOS/PC. The old product decnet for dos has nothing to do with NetBIOS, SMB and whatnot. Interestingly (and not that surprising) that DOS client can act as a file server using FAL (directly accessible from VMS) but not act as a client other than for a “ftp” style command line transfer utility, or attach to files on a server using them as an image to emulate a hard disk.
The newer (as in early 90’s rather than mid 80’s) Pathworks product though seems to be able to do a bunch of things. It can use DECs own protocol (LAST) for file/disk/printer sharing, but it can also use NetBIOS for Lan manager (i.e. SMB) style file/printer sharing. And it can use DECnet, or TCP/IP as a transport protocol.
And what might intrigue you is that it seems to be able to allow clients using Netbios over TCP/IP to access NetBIOS services on OS/2 computers, and also have OS/2 access other Netbios over TCP/IP servies. In other words, it seems to be usage as an alternative to the IBM software for doing this.
Also: It can use Decnet as a transport for NetBIOS between a DOS client and an OS/2 server, or in any direction between computers running OS/2.
Check out chapter 1 in the document called AA-PAF5C-TK_Pathworks_for_DOS_Overview_V4.1_Aug91.pdf on this server:
https://bitsavers.org/pdf/dec/decnet/pathworks_DOS/
It seems to support some cursed networking operations. How about connecting a Macintosh to an Ultrix server using Decnet over token ring? 🙂 🙂
LAN Manager/LAN Server and the client software can run on top of NetBIOS (at least on OS/2, there’s also a “fast path” LAN Manager specific interface). Back in the old days there were numerous NetBIOS over TCP/IP implementations, for example from Excelan or FTP Software, even from IBM. These could be paired with the standard IBM/MS SMB software.
I never looked at Pathworks very closely but it seems to have been very versatile networking software.
Very few VINES sites ran NetBIOS on top – due to extra memory contraints, at least under MS-DOS. I can recall a couple of sites using various NetBIOS based tools to allow clients to access obscure mainframe or mini platforms via a gateway PC. One was for terminal access on some weird ICL mainframe.
NetBIOS was required to run Windows 3.0 prior to the release of proper Windows drivers for VINES, due to the Windows using some int 2A calls with their generic network support. Banyan did produce a small TSR to use instead of full NetBIOS stack, which just provided the interrupt services needed by Windows 3.0
“When NETBIOS (or NetBIOS) moved to Ethernet, there were initially many different ways of encapsulating it. Eventually the world settled on NetBIOS Frames aka NBF.”
Terminology is here wrong. Nothing needs to be “encapsulate”. Point being is that
NETBIOS was an API for software. IBM PC Network used analogue signalling on the wire and proprietary Sytek networking protocol, so there was no “NETBIOS” on the wire. You don’t “encapsulate” an API to network frames.
Later, when IBM came out with the Token Ring, NETBIOS got enhanced to deal with the enlarged host count that Token Ring introduced – that was called NetBEUI – NetBios Extended User Interface, again just an API. At the same time, actual networking protocol, named NBF – NetBios Frames were introduced, for Token Ring. So it is important to distinguish here the software API and the actual networking protocol. You don’t “encapsulate” an API to network frames.
If you consider the original NETBIOS to be strictly an API and everything in between as magic, then there was no NETBIOS on the wire. If you consider that the bits had to move between stations somehow and be understood by both ends, then there had to be NETBIOS on the wire.
But I understand your point that whatever the PC Network did or didn’t send on the wire was not that relevant for the Ethernet implementations, and their goal was not to take an existing PC Network wire protocol and move it on top of Ethernet. So talking about encapsulation is wrong.
IBM extended the original NETBIOS API, so they needed a new wire protocol to support it. For the new Token Ring, they created a communication protocol, later called NBF, built upon 802.2 LLC framing. As the Ethernet standard IEEE 802.3 was published around the same time and it mandated 802.2 LLC framing, it meant that the IBM’s effort for Token Ring was directly applicable to Ethernet too… Actually, there is nothing in the new IBM NetBEUI API and wire standards that depends on Token Ring. So IBM collaterally created an NetBEUI/NBF for all IEEE 802 compliant networks (which by standard are obliged to carry 802.2 LLC)
Other companies should have used this gift since the beginning and create new NetBIOS wire protocol implementations only if they used frames from some other transport protocol (to provide routing support, for example). Microsoft definitely used that gift in Lan Manager.
By the way, I personally don’t consider NBF a “networking protocol” like TCP/IP, IPX/SPX etc. are. The true protocol here is 802.2 LLC, and the NBF is just a subset of specially crafted messages transferred through it. NBF is not general enough to be a networking protocol. It carries nothing but NETBIOS and some associated payloads built on top of ot, like SMB on NetBEUI.
Around 1995 I worked on a text based full screen user interface toolkit written in REXX which I called RXUI, and then someone else wrote some programs like an address book utility using that. (I lost the source code but I still have the RXUI.DLL lying around.) Had an option of either ANSI escape codes, Vio/Kbd calls, or early in its development Microsoft’s QuickC graphics/text mode library. The purpose was to replace older FSX_REXX based programs which only ran on REXX88 on DOS.
It immediately made sense to access this program over a network, so I made an implementation which simply sent all the commands over NetBIOS and had a client executable. This was surprisingly easy to do and worked well for years. I didn’t know much about TCP/IP back then and it was pointless anyway since any networked machine already was mounting drives via NetBIOS. I recall the machines used LAPS (later called MPTS) on top of OS/2 3.0.
Later as a lark I wrote a client for DOS (the original codebase started on DOS since it was a lot faster to develop , compile etc. in QuickC than in C Set/2 back then) that used the NetBIOS calls and to my surprise it worked fine the first try on contemporary Windows at the time (NT 3.51 or 95), Windows 3.11 for Workgroups, or the classic MS LANMAN for DOS client.
For reasons I never figured out our local setup was all over 802.2 frames. I have no idea why. The physical layer was 10Base-5. I think it was just a sensible looking default in LAPS.
My understanding is that some IBM products (like host comms?) required 802.2.
I had a similar experience with NetBIOS being pretty interoperable. But the programming interface was… reeeally weird.
Josh:
That’s really cool!
I’ve always wondered why the typical PC networks rarely had support for anything else than file and printer sharing, Sure, with single user machines it would be hard to do anything interactive, but still. Technically it would be possible to run all the classic TCP/IP use cases over NetBIOS, i.e. smtp/pop3/imap and whatnot.
I always wondered why Microsoft Mail only used “file communication”, and actually also how it managed to get any sense of security and whatnot. But I’ve never wondered hard enough to try some more advanced setup of it.
@MiaM
NETBIOS can be used for various client-server purposes, although real examples are indeed rare. Maybe it’s because proper network transports like IPX/SPX also have session support, are easier to use than NETBIOS, and are reasonably ubiquitous on DOS. For example, DOOM and other games preferred using IPX/SPX for network play, although I can remember reading somewhere in an ID Software document that they also planned to enable network play using NETBIOS… something that, AFAIK, never actually materialized. Maybe IPX/SPX was just too good.
@vbdasc:
Yea, the fact that most systems had either Novell Netware or TCP/IP installed, and Microsoft LAN Manager/NetBIOS wasn’t guaranteed to be installed on networked computers, probably killed any selling points for using NetBIOS for anything else than priter/file sharing, and obviously also for Microsoft specific products. (Not sure but I would guess that their SQL Server could use NetBIOS, perhaps?).
Kind of reminds me of Digitals networking protocols. I assume that some third party applications used DECnet as a transport, but I’ve never heard of any third party usage of LAT, MOP and whatnot.
Re Doom: Since it’s open source nowadays, a weird project would be to add support for network gaming over NetBIOS 🙂 🙂
Ah yes, the SQL Server. Thank you for mentioning that. It seems my memory is fuzzy about it… But I believe that yes, it represents a major use case for NETBIOS. It used an IPC feature of Windows NT (and possibly OS/2, Lan Manager?) called “named pipes” for communication. And Named Pipes can work transparently over the network by using at least NETBIOS session and name resolution support. (Apparently later versions of MS SQL Server started also allowing direct TCP/IP communication). Microsoft/IBM apparently had a bunch of NETBIOS-based technologies for OS/2 and Windows NT (not counting SMB) like named pipes, mailslots, message queues, which were used in major products and shouldn’t be forgotten. Note however, that after Windows 2000 and Active Directory, some of these uses of NETBIOS were supplanted by TCP/IP.
And not to forget, MS built a whole RPC API on top of NETBIOS too.
And last, but by no means least, the MS Hearts game in Windows for Workgroups also was based on NETBIOS 🙂
Just a guess — the bits required for DOOM IPX/SPX support were free and easy enough to find. I’m not sure if the LAN Manager client was free in those days, and I’m pretty sure it wasn’t trivial to install just the networking bits without the client.
Also the Novell stuff was all TSRs which was IMHO a huge plus.
When I read (paraphrasing) “but no one ever used NetBIOS anyway” my first thought was, didn’t pretty much all the database products use it? I am almost certain that just about everything from dBase to DB2 ran over NetBIOS. Over time everything was replaced by TCP/IP, but on the PCs in 1990, who wanted all the crap and huge overhead that was required to even get TCP/IP off the ground?
dBase is probably not a good example for a database using NETBIOS. At least until the times when raw TCP/IP started to displace NETBIOS, dBase was file server-based, not client-server. And so were its clones like FoxPro and Clipper.
Good point – whatever IPX stuff was needed to run LAN games like Doom was probably free.
Named pipes has always seemed like a weird way of communicating. It feels partially like something batch oriented mainframe style thing, and partially something you would end up with if you want to create a way for applications to communicate over a network and you don’t really know what you are doing, kind of.
I know that some people don’t agree, but arguably a lot of the PC software manufacturers didn’t really know what they were doing. Like everything Microsoft did before hiring David Cutler (from Digital) has an aura of 8-bit home computers.
Btw, I took the time to read some of the Pathworks documents that I linked to in an earlier comment. Although the documents are decent, they give a feeling that the author was paid by amount of characters/words rather than being good at writing. Things are repeated, it’s written using a very bureaucratic language and whatnot.
I honestly don’t know about IPX/SPX being free. I can hardly remember a reasonably straightforward way to install IPX/SPX on DOS other than using the (16-bit) NetWare client, and I don’t remember if it was free. I mean, if it was free, then why not the Lan Manager client, which brought NETBIOS? I’m pretty sure that MS SMB clients for DOS were already free not later than 1994, with the release of NT 3.5 . Although, honestly, I don’t know about 1992, when DOOM was released.
Named pipes might seem weird for a network protocol, because they’re not a network protocol. They’re an IPC mechanism, which is intended for both local and network applications.
Before Cutler… I don’t know about 8-bit, but OS/2 1.x have always given me at least some 32-bit IBM mainframe vibes…
Oops, DOOM is from 1993, sorry for that.
Was the MS client free as in freely redistributable with commercial software, or free as it was available by ftp from Microsoft and whatnot?
I just remembered that the first time me and a fried tried Doom we didn’t find the IPX thing but somehow found an IPX-over-packet driver converter and obviously packet drivers for our network cards… (I think that SPX wasn’t needed for Doom).
I admit that I know almost nothing about IBM mainframes. But from what I recall when reading a book (forgot the title, iirc it was considered one of the best about writing software for OS/2) is that OS/2 has an aura of “let’s make a multitasking MS-DOS”, which in turn gives CP/M vibes. The APIs and whatnot just feels awkward as compared to things that were written as some sort of extension/evolution of the 8-bit operating systems. Maybe I’ll have to re-read that book or some similar book and write something about it. Seems like something suitable for a forum thread somewhere or so.
>Good point – whatever IPX stuff was needed to run LAN games like Doom was probably free.
Well, in doom black book stated that Carmack has used udp for network prototype and indeed, there is still udp/666 port reserved in /etc/services for doom. Unfortunately, the book contains no information about why ipx was chosen for PC, just an anecdote about some early implementation issues.
Well it’s not hard to see why they prototyped it with UDP — the development was done on NeXTSTEP. It’s also not hard to see why they didn’t use UDP for the released product — gamers did not run TCP/IP back then, and telling them to buy a TCP/IP stack which cost several hundred dollars was not going to fly. With some version of Quake, they IIRC shipped a very stripped down version of Beame & Whiteside TCP/IP that was intended for dial-up.
NetWare was the king back in the DOOM days, even Microsoft’s networking often ran on top of IPX. It was the logical choice. And it wasn’t an abomination to work with like the horrendous NDIS protocol manager. You didn’t have to put additional memory hungry junk into your CONFIG.SYS, you could just load the IPX TSRs, play DOOM, and unload the network support again.
Re drivers, I am 99% certain that LSL.COM and IPXODI.COM were freely available, plus many if not most NICs came with driver disks that included an old style IPX.COM with the driver linked in.
The NIC driver disks naturally also included NDIS drivers and packet drivers, but those were really just the drivers, useless without a network stack.
The LAN Manager 2.1 client and MS Network 3.0 client were freely available on Microsoft’s FTP, though I couldn’t tell you exactly when.
OS/2 should give some “let’s make a multitasking MS-DOS” vibes because that’s what it literally started out as.
Internet wasn’t really big (for the man at the street) until 1996 or 1997. At the time I probably could have download it from Compuserve, but it was much easier if you had the media. Netware was much more popular than LAN Manager/LAN Server. Also the client from Windows for Workgroups only worked when Windows was running, you didn’t have the client just for DOS.
By the way, remembered that I had see some Lantastic networks at the time and apparently supported NETBIOS.
@Fernando
Actually WfWg 3.11 installed a SMB client with NETBIOS and everything that ran under pure DOS, without Windows running. It was started by running NET.EXE . The prerequisite was the network adapter to have a NDIS2 driver installed. I’m pretty sure that this worked with NetBEUI, did NOT work with TCP/IP, and I can’t remember right now if it worked with IPX/SPX .
Yes, tcp/ip is an obvious choice on NeXT and the choice of ipx because of its popularity is plausible. But, as I said, there are no details.
We can only speculate that Carmack was not very happy about ipx, because idtech2 used tcp/ip for network play (and in the full circle quakeworld switched back to udp). I remember reading in someone’s memoir that network overhaul was second only to true 3d implementation by complexity and time spent.
1995 was the year when Microsoft discovered the Internet (although really it was a couple of years earlier). So, Quake needed to enable network play connecting the entire world (the very name QuakeWorld reflects that). Unfortunately, while IPX/SPX is great for LANs and corporate networks, it just doesn’t work over the wide Internet. Although IPX is a routable protocol, the Internet backbone has no provisions for IPX routing. So TCP/IP had no alternatives for Quake.
For the original quake it was maybe one of the reasons, but likely not the main one.
The quake over contemporary dial-up(~14400) was barely usable before major network
rework in quakeworld which added, among other things, client-side prediction logic.
@vbdasc “1995 was the year when Microsoft discovered the Internet”
Microsoft was pushing hard “MSN – Microsoft Network” in 1995, it was even included in Windows 95. It was a service kind like Compuserve or America Online. About 1996 was hit hard by the reality of the growth of the Internet and by Windows 98 Internet Explorer was included.
MS Internet Explorer was introduced in 1995 as part of Microsoft Plus! for Windows 95.
Having seen in this discussion the various protocols that NetBIOS could be operated over, it made me wonder whether anyone had done something really weird as a joke, like NetBIOS-over-SMTP.
IE being part of “Plus!” seems like a sure sign that Microsoft wanted to milk the last “online service but not Internet” from their customers with MSN before everyone understood that internet would be the future.
@John:
I doubt that anyone has done that, as SMTP afaik always runs over TCP/IP which already can do NetBIOS. A joke thing would be NetBIOS over UUCP for example 🙂
I wouldn’t be surprised if someone has done NetBIOS over some of the mainframe style protocols, but then not as a joke but rather as a way to use standard client software on PCs to access databases and whatnot running on mainframes.
NetBIOS over DECNET is kind of in this style. Don’t know if there were any OBDC database connectivity drivers for accessing DEC RDB via NetBIOS, that in turn used whichever protocol available (DecNET and TCP/IP would be the two options for a VMS server I think).
In general it seems like the documentation/standards för any networking and whatnot that isn’t TCP/IP or part of the Unix related world is usually hard to digest, or even hard to even find.
Sure, there are some RFC and man pages that aren’t perfect in all ways, but in general I would say that they are somewhere within the top level on a 1-5 scale for how good documentation is written. I wish that that would be true for other documentation.
Micro rant: A problem is that many companies really wanted to get paid for everything. I get that that is how capitalism works, but to some extent it might had worked against some of those companies. In particular charging lots of money for API documentation and development tools is probably a reason for there not being any “joke protocol implementations”, and more importantly very few if any hobbyist usages of for example NetBIOS, but also most other things.
DEC seems to have been an exception. Sure, you had to pay for the physical manuals but it seems like the cost wasn’t particularly high, and also in the 90’s they put at least all the VMS documentation online for free to read/download. This is probably the reason for DecNET afaik being the only “complicated” protocol implemented as part of the Linux kernel, of course in addition to TCP/IP. (A while ago DecNET was removed, but it lingered for a long time since there were almost no effort needed to keep it working, and since there were more or less no bug reports in many years, there weren’t much to maintain).
Sure, IPX and AppleTalk isn’t super simple, but without actually knowing my gut feeling says that DecNET is more complicated.
I wish that other companies had done what DEC did, i.e. publish all documentation for free for things that were on it’s way to become mostly obsolete, rather than trying to squeeze every penny out of anyone who wants to know anything about mostly obsolete tech. A few sad cases is that the dev tools and whatnot for CD-i at least was a commercial product in the late 00’s, and probably is still today, which kind of makes the CD-i obnoxious for anyone wanting to tinker with old tech. I also remember that in the late 90’s you had to pay to get a copy of the CP/M disk for an Amstrad word processor/computer thingie. I threw away a PCW9512 20 years ago due to this, and I think I lost my CD-i 450 due to it just sitting unused, also due to this. (I wouldn’t call myself an expert but I sure do know quite a bit about 68k programming, so if any sort of documentation or dev tools had been available I would likely had tinkered with the CD-i).
Also both re “joke protocol implementations” but also “odd but technically useful” implementations it seems like network protocols and whatnot is a narrow hobby/interest, and even the most obvious use cases doesn’t seem interesting to general vintage computing hobbyist. To me it almost feels a bit cringe when people use FTP rather than SMB to transfer files between vintage PCs and other computers. Sure, I get if people don’t want to turn on the insecure SMB options on a modern Windows computer, but in Linux you can run two instances of SAMBA and bind them to different network cards, so you could have one that only allows writes to a small part of the servers disk, but also allows old clients to connect via insecure protocols, and also run another SAMBA that only allows modern safer protocols but allows writing to a larger part of the servers disk. Not that hard to set up, and it’s anyway a good idea to have a separate network for vintage computers.
The NetBIOS protocol stacks circa 1993 were kind of a pain to set up (at least compared to Netware) and used oodles of conventional RAM. IPX was just a lot slimmer, and was particularly easy to install with the ancient NE-2000 driver that was just a single TSR that had IPX.COM linked in.
Whereas installined LANMAN client or IBM’s equivalent… install a bunch of stuff, edit PROTMAN.INI, add several DEVICE= statements, plus have to load some TSRs. The DEVICE= statements meant it was not straightforward to avoid loading this stuff when you didn’t need networking.
The NetBIOS protocol is actually pretty simple and could have been implemented as a single, tiny TSR… but wasn’t. LANMAN is one of those things written back when PCs were 512kB and people just assumed when 640kB PCs came out that nobody would miss the extra memory. (DOS 4.00 comes to mind for making the same, poor assumptions.)
One of the reasons to run Windows for Workgroups was to chew up less RAM when trying to use networking.
Oh, and my earlier post shoud have said 10BASE2, not 10BASE5.
IBM provided extensive documentation with their products, and it didn’t cost extra. Yes, you had to pay for printed documentation f you ordered it separately, and yes library CD-ROMs weren’t free either. But quite a lot was available for free on the Internet. IBM’s Redbooks were also excellent.
Same with Novell, the big red boxes were mostly documentation, and Novell always provided a lot of documentation electronically (even in the NetWare 2.x days).
Re TCP/IP programming, I would draw a big fat line between TCP/IP and BSD sockets. The sockets interface is really (relatively) easy to work with, but a) TCP/IP was not always programmed through sockets, and b) sockets aren’t tied to TCP/IP.
So true about the Microsoft Protocol Manager and NDIS vs Novell’s IPX (ODI or not). MS’s stuff was a huge pain to deal with, and very memory hungry. Figuring out PROTOCOL.INI problems was a nightmare. I don’t know why but the Protocol Manager and all that stuff is just one of those interfaces that make absolutely no sense, it’s all completely baroque and impenetrable and somehow totally backwards. I wonder how much of that was 3Com’s fault.
I think you’re on to something about the 512K to 640K RAM jump. And that some DOS software written in the late 1980s just had the philosophy “hey we have this whole 128K RAM to work with, no need to worry”. I have bad memories of trying to get DOS games working that required upwards of 600K free memory. One of the winners was Ultima VII, requiring over 600K free and no EMM386 style memory manager.
Novell’s stuff was dead easy, with the old single built-in driver + IPX modules you could not go wrong, and ODI was not hard to use either. Just load LSL, then NIC driver, then IPXODI. The defaults were sensible, and everything was implemented as TSRs so you could load and unload the components until it worked.
>Re TCP/IP programming, I would draw a big fat line between TCP/IP and BSD sockets. The sockets interface is really (relatively) easy to work with, but a) TCP/IP was not always programmed through sockets, and b) sockets aren’t tied to TCP/IP.
I don’t think anyone would contest that.
The socket is just the form of ipc. The unix sockets, for example, are widely used when you need to exchange data between two processes on the same host. The tcp/ip also can be used with different api, like STREAMS.
Historically though, ipv4(1983) was almost always used with Berkeley sockets. The STREAMS(1987, SVR3) briefly tried to challenge that, but it stood no chance after UC Berkeley released(1989) the socket library under a free license.
1993 was also the year MS-DOS 6 started selling. And that was also the first MS-DOS version with a built in boot menu, so it was a bit easier to be able to boot with or without network support (and while you are at it you could also have with or without EMM386 when booting without network). But also, near the end of 1993 Windows for workgroups 3.11 was released and that more or less solved all the conventional memory and annoying configuration procedures as Windows for Workgroups solved all the configuration issues, and with the proper configuration you didn’t have to run anything in DOS (but you might had wanted to run SHARE.EXE, perhaps?) as everything could run as 32-bit protected mode code within Windows. (Sorry that I’m Captain Obvious here, just pointing out how fast things moved).
Re documentation: Maybe an issue was that it was a bit hard for people in general to even know what to look for? Maybe it at least partially was an issue with what magazines and whatnot was available for different systems? In the early 1990’s I would think that an “advanced” PC users was considered someone who was able to edit config . sys and understand what they were doing, while many just ran their word processor and/or book keeping software, while for some other platforms an “advanced” user would be someone doing some hobbyist programming or similar. And thus the PC magazines (and also Mac magazines) wrote about word processors and whatnot while the magazines for the classic “home computers” mixed game review with articles about programming (and in particular the German 64er had a bunch of DIY hardware projects too). And there I ended up reading what was available in the regular news paper shops, and there for sure weren’t any Dr Dobbs journal, but rather the magazines that reviewed word processors. :/
If “Netbios over TCP/IP” installs both, NETBEUI and TCPBEUI, is it possible to remove all of the NETBEUI part from PROTOCOL.INI (and related additions to CONFIG.SYS) after the installation is finished ?
As far as I understand, TCPBEUI can completely replace NETBEUI and then, it seems advantageous to remove a completely unused protocol driver …
Yes, editing CONFIG.SYS/PROTOCOL.INI/IBMLAN.INI is always possible. The MPTS GUI mostly does the job as well.