https://www.os2museum.com/wp/os-2-tcpbeui-name-resolution/ OS/2 Museum OS/2, vintage PC computing, and random musings OS/2 Museum Skip to content * Home * About + Wanted List * OS/2 History + OS/2 Beginnings + OS/2 1.0 + OS/2 1.1 + OS/2 1.2 and 1.3 + OS/2 16-bit Server + OS/2 2.0 + OS/2 2.1 and 2.11 + OS/2 Warp + OS/2 Warp, PowerPC Edition + OS/2 Warp 4 + OS/2 Timeline + OS/2 Library o OS/2 1.x SDK o OS/2 1.x Programming o OS/2 2.0 Technical Library + OS/2 Videos, 1987 * DOS History + DOS Beginnings + DOS 1.0 and 1.1 + DOS 2.0 and 2.1 + DOS 3.0, 3.1, and 3.2 + DOS 3.3 + DOS 4.0 + DOS Library * NetWare History + NetWare Timeline + NetWare Library * Windows History + Windows Library * PC UNIX History + Solaris 2.1 for x86 - IBM PC 5150 Model Numbers OS/2 TCPBEUI Name Resolution Posted on October 8, 2024 by Michal Necasek 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: [warp-conn-inst-tcpbeui]Which protocol would you choose? 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: [warp-conn-mpts-config]LAPS configuration dialog This leads to a fork in the road: [warp-conn-mpts-names]TCPBEUI configuration selector The Names list interface allows adding the actual names: [warp-conn-mpts-names-added]NetBIOS name successfully added 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: [warp-conn-mpts-drvparms]Zero means nothing 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. [nbtcp-debug-640x480]Debugging NBTCP in OS/2 MCP2 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 NAMESFILE keyword 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 ENABLEDNS keyword 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. [nbtcp]NBTCP running on OS/2 2.00.1 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. This entry was posted in IBM, Networking, OS/2, TCP/IP. Bookmark the permalink. - IBM PC 5150 Model Numbers 18 Responses to OS/2 TCPBEUI Name Resolution 1. [7297] vbdasc says: October 8, 2024 at 7:38 pm "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. 2. [8f7d] Michal Necasek says: October 8, 2024 at 7:56 pm 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. 3. [7297] vbdasc says: October 8, 2024 at 8:46 pm 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. 4. [5e58] JQW says: October 8, 2024 at 11:26 pm 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. 5. [7e72] MiaM says: October 9, 2024 at 5:56 am 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. 6. [7297] vbdasc says: October 9, 2024 at 8:27 am @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. 7. [8f7d] Michal Necasek says: October 9, 2024 at 12:36 pm 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. 8. [8f7d] Michal Necasek says: October 9, 2024 at 12:38 pm 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. 9. [8f7d] Michal Necasek says: October 9, 2024 at 12:45 pm 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. 10. [5c38] SweetLow says: October 9, 2024 at 1:09 pm 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? 11. [7e72] MiaM says: October 9, 2024 at 5:44 pm @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? 12. [8f7d] Michal Necasek says: October 9, 2024 at 6:55 pm 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. 13. [5e58] JQW says: October 9, 2024 at 11:28 pm 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 14. [2dfe] --- says: October 10, 2024 at 1:06 am "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. 15. [8f7d] Michal Necasek says: October 10, 2024 at 11:44 am 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. 16. [7297] vbdasc says: October 10, 2024 at 5:00 pm 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. 17. [fadb] Josh Rodd says: October 10, 2024 at 5:01 pm 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. 18. [8f7d] Michal Necasek says: October 10, 2024 at 5:52 pm 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. Leave a Reply Your email address will not be published. Required fields are marked * [ ] [ ] [ ] [ ] [ ] [ ] [ ] Comment * [ ] Name * [ ] Email * [ ] Website [ ] [Post Comment] [ ] [ ] [ ] [ ] [ ] [ ] [ ] D[ ] This site uses Akismet to reduce spam. Learn how your comment data is processed. * Archives + October 2024 + September 2024 + August 2024 + July 2024 + June 2024 + May 2024 + April 2024 + March 2024 + February 2024 + January 2024 + October 2023 + September 2023 + August 2023 + July 2023 + June 2023 + May 2023 + April 2023 + March 2023 + January 2023 + December 2022 + November 2022 + October 2022 + September 2022 + July 2022 + June 2022 + May 2022 + April 2022 + March 2022 + February 2022 + January 2022 + December 2021 + November 2021 + October 2021 + September 2021 + August 2021 + July 2021 + June 2021 + May 2021 + April 2021 + March 2021 + February 2021 + January 2021 + December 2020 + November 2020 + October 2020 + September 2020 + August 2020 + July 2020 + June 2020 + May 2020 + April 2020 + March 2020 + February 2020 + January 2020 + December 2019 + November 2019 + October 2019 + September 2019 + August 2019 + July 2019 + June 2019 + May 2019 + April 2019 + March 2019 + February 2019 + January 2019 + December 2018 + November 2018 + October 2018 + August 2018 + July 2018 + June 2018 + May 2018 + April 2018 + March 2018 + February 2018 + January 2018 + December 2017 + November 2017 + October 2017 + August 2017 + July 2017 + June 2017 + May 2017 + April 2017 + March 2017 + February 2017 + January 2017 + December 2016 + November 2016 + October 2016 + September 2016 + August 2016 + July 2016 + June 2016 + May 2016 + April 2016 + March 2016 + February 2016 + January 2016 + December 2015 + November 2015 + October 2015 + September 2015 + August 2015 + July 2015 + June 2015 + May 2015 + April 2015 + March 2015 + February 2015 + January 2015 + December 2014 + November 2014 + October 2014 + September 2014 + August 2014 + July 2014 + June 2014 + May 2014 + April 2014 + March 2014 + February 2014 + January 2014 + December 2013 + November 2013 + October 2013 + September 2013 + August 2013 + July 2013 + June 2013 + May 2013 + April 2013 + March 2013 + February 2013 + January 2013 + December 2012 + November 2012 + October 2012 + September 2012 + August 2012 + July 2012 + June 2012 + May 2012 + April 2012 + March 2012 + February 2012 + January 2012 + December 2011 + November 2011 + October 2011 + September 2011 + August 2011 + July 2011 + June 2011 + May 2011 + April 2011 + March 2011 + January 2011 + November 2010 + October 2010 + August 2010 + July 2010 * Categories + 286 + 386 + 386MAX + 3Com + 3Dfx + 486 + 8086/8088 + Adaptec + AGP + AMD + AMD64 + Apple + Archiving + Assembler + ATi + BIOS + Books + Borland + BSD + Bugs + BusLogic + C + C&T + CD-ROM + Cirrus Logic + CompactFlash + Compaq + Compression + Computing History + Conner + Corrections + CP/M + Creative Labs + Crystal Semi + Cyrix + DDR RAM + Debugging + DEC + Development + Digital Research + Documentation + DOS + DOS Extenders + Dream + E-mu + Editors + EISA + Ensoniq + ESDI + Ethernet + Fakes + Fixes + Floppies + Graphics + Hardware Hacks + I18N + IBM + IDE + Intel + Internet + Keyboard + Kryoflux + Kurzweil + LAN Manager + Legal + Linux + Marketing + MCA + Microsoft + MIDI + NetWare + Networking + NeXTSTEP + NFS + Novell + NT + OS X + OS/2 + PC architecture + PC hardware + PC history + PC press + PCI + PCMCIA + Pentium + Pentium 4 + Pentium II + Pentium III + Pentium Pro + Plug and Play + PowerPC + Pre-release + PS/2 + QNX + Quantum + Random Thoughts + RDRAM + Roland + Ryzen + S3 + SCO + SCSI + Seagate + Security + Site Management + SMP + Software Hacks + Solaris + Sound + Sound Blaster + Source code + Standards + Storage + Supermicro + TCP/IP + ThinkPad + Trident + UltraSound + Uncategorized + Undocumented + UNIX + UnixWare + USB + VGA + VirtualBox + Virtualization + VLB + Watcom + Wave Blaster + Western Digital + Windows + Windows 95 + Windows XP + Wireless + WordStar + X11 + x86 + x87 + Xenix + Xeon + Yamaha OS/2 Museum Proudly powered by WordPress.