I came across a couple more old DOS networking technologies; CBIS &
MainLan.
Here is the complete list of what I'm aware of.
- Artisoft LANtastic
- Banyan VINES
- CBIS Network OS
- EtherDFS (http://etherdfs.sourceforge.net)
- Invisible LAN (http://www.invisiblesoft.com/invlan/software.html)
- LapLink
- MainLan from U.S. Sage Inc.
- Microsoft's LAN Man client / redirector for DOS.
- MS-DOS's INTERLNK.EXE & INTERSVR.EXE
- NetSoft's NSLAN v1.40
- Novell NetWare
I came across a couple more old DOS networking technologies; CBIS & MainLan.
- Novell NetWare
My config uses ODINSUP for MS-LANMAN 2.1 NETBEUI basic redirector
I think LapLink and MS Interlink are not full networks, just 1 client
to 1 server (generally used for syncing files between a laptop and
desktop).
Novell also had Client32 for DOS, similar to Helix cloaking.
My config uses ODINSUP for MS-LANMAN 2.1 NETBEUI basic redirector,
so I can mount network shares to a Win98 server.
Novell also provided a TCP32 and a SDK to write TCP apps. It's a
complicated config, but it works.
The network config also works with Windows 3.11 (not WFWG). It took
some time to find the right magic, but it seems stable.
Correction, the readme.txt says 2.2c. It's the set of files named:
dsk3-1.exe
dsk3-2.exe
dsk3-3.exe
dsk3-4.exe
dsk3-1.exe
dsk3-2.exe
dsk3-3.exe
dsk3-4.exe
Aren't those the files that are used to create disks 1-4 for the
Microsoft's LAN Man client / redirector for DOS, all of which have
multiple files on them?
What can you do with Client32 that doesn't include a NetWare server?
That might be all that's needed to play an old IPX based network game.
My config uses ODINSUP for MS-LANMAN 2.1 NETBEUI basic redirector,
so I can mount network shares to a Win98 server.
Is that somehow related to Client32?
Or is it just the stock Microsoft's LAN Man client / redirector for DOS?
Novell also provided a TCP32 and a SDK to write TCP apps. It's a
complicated config, but it works.
Interesting.
I wonder if it supported any of the TCP/IPX (yes, IPX, not IP) that was around in the NetWare 4.x & 5.x days.
On 6/14/19 4:25 AM, Kerr-Mudd,John wrote:
I think LapLink and MS Interlink are not full networks, just 1 client
to 1 server (generally used for syncing files between a laptop and
desktop).
Fair enough.
But you do get into a discussion of what is and what is not a network.
;-)
The original context of the thread where the list started was a way to
copy files between two PCs.
Dang, I was hoping for a memory hint for whatever DD or BB I was
grasping for.
client32.nlm talks to a Novell server, but it's a separate module you
can omit from your startup file. So you don't need a Novell server
at all
Right, ipx.nlm is a separate module.
No. but it to works with it, using ODINSUP as a shim.
Right.
The SDK provides a socket interface for homegrown TCP apps, You need Microsoft C 6 or 7. I coded a test app to see how it works. It receives
40MB of data from a linux host, TCP port 19 (chargen), then quits.
The SDK was developed for the old 16-bit Novell TCP/IP, and they warn against using it with TCP32, but it works so far in my limited testing. Novell 16-bit TCP/IP is buggy and slow, their TCP32 is much better.
Not sure if that was your question.
No. At least not directly. TCP/IP ? TCP/IPX. I'm referring to a
solution that Novell provided that allowed transporting TCP on top of
IPX without IP. This was a way to allow machines on an IPX only network
to access the TCP/IP internet.
It worked by using a special Winsock stack that intercepted API calls
and translated them to be TCP on top of IPX and sent the packets to a gateway server. The gateway server would receive the TCP/IPX and
translate it to TCP/IP out a separate WAN / network connection.
The SDK provides a socket interface for homegrown TCP apps, You need
Microsoft C 6 or 7. I coded a test app to see how it works. It receives
40MB of data from a linux host, TCP port 19 (chargen), then quits.
The SDK was developed for the old 16-bit Novell TCP/IP, and they warn
against using it with TCP32, but it works so far in my limited testing.
Novell 16-bit TCP/IP is buggy and slow, their TCP32 is much better.
Intriguing.
Novell also had Client32 for DOS, similar to Helix cloaking. It only
takes 2k to load NIOS.EXE
That could be misleading, I should clarify. The SDK is for coding DOS
apps only. It's a set of DOS libraries that provide a socket interface
so you don't have to do INT calls. Nobody knows what the INT calls
are anyway, they're undocumented.
If you could reverse engineer and discover them, you wouldn't need
the DOS socket libraries.
But all that is separate from winsock.
Novell client32 provides a standard winsock.dll, and also a companion wlibsock.dll, which must be a translation layer between winsock.dll
and Novell TCP32 INT calls.
With Novell winsock, WFWG is not needed. Windows 3.11 works fine.
That could be misleading, I should clarify. The SDK is for coding DOS
apps only. It's a set of DOS libraries that provide a socket interface
so you don't have to do INT calls. Nobody knows what the INT calls
are anyway, they're undocumented.
I expect that many of them are documented. It's more of a question of
where they are documented.
I expect that the MS-DOS Encyclopedia from Microsoft Press likely has
many of them. At least as of the time of publishing.
https://www.amazon.com/MS-DOS-Encyclopedia-Ray-Duncan/dp/1556151748 >https://www.amazon.com/MS-DOS-Encyclopedia-Versions-1-0-Through/dp/1556150490
If you could reverse engineer and discover them, you wouldn't need
the DOS socket libraries.
You wouldn't /need/ the DOS socket libraries. But you might /want/
them. Abstraction layers can be a good thing. Especially if Microsoft
were to ever change things under the hood. ;-)
Windows 3.1 can be also a problem
I have that book. But I'm not talking about Microsoft DOS INT calls.
I'm talking about TCP INT calls Novell created for their own purposes.
They just picked some unused INT number and built a TCP API on that,
by coding it into their TCP kernel. But who knows what INT they picked,
or how the API looks.
That's what's undocumented. With the right tools, you could discover
and reverse engineer it, but who has that much time.
I'm talking about TCP INT calls Novell created for their own purposes.
They just picked some unused INT number and built a TCP API on that,
by coding it into their TCP kernel. But who knows what INT they picked,
or how the API looks.
That's what's undocumented. With the right tools, you could discover
and reverse engineer it, but who has that much time.
I bet they are, or at least were, inside of Novell.
But there's a reasonable chance that information is either gone
or will never see the light of day. Thus it's effectively lost
information.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 910 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 252:03:09 |
| Calls: | 12,118 |
| Calls today: | 1 |
| Files: | 186,506 |
| Messages: | 2,227,582 |