Old DOS networking technologies - Update

[Grant Taylor]

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

[Kerr-Mudd,John]

On Fri, 14 Jun 2019 04:27:14 GMT, Grant Taylor

Post by Grant Taylor
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.

erm Sage used to be in the UK
https://www.cbronline.com/news/sage_revamps_peer_to_peer_mainlan_system_f
or_windows_and_mac_adds_mac_sterling_2_new_version_of_sovereign/

Post by Grant Taylor
- Microsoft's LAN Man client / redirector for DOS.
- MS-DOS's INTERLNK.EXE & INTERSVR.EXE
- NetSoft's NSLAN v1.40
- Novell NetWare

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).
There was a LL competitor, I think with the initials DD or BB? - gawd
it's been a long time.

[Grant Taylor]

Post by Kerr-Mudd,John
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.

[Kerr-Mudd,John]

On Fri, 14 Jun 2019 19:03:47 GMT, Grant Taylor

Post by Grant Taylor

Post by Kerr-Mudd,John
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.

[Grant Taylor]

Post by Kerr-Mudd,John
Dang, I was hoping for a memory hint for whatever DD or BB I was
grasping for.

Sorry.

Try searching the web for LapLink alternatives.

Even something like an old PC World review might mention competitors.

[T. Ment]

Post by Grant Taylor
I came across a couple more old DOS networking technologies; CBIS & MainLan.
- Novell NetWare

Novell also had Client32 for DOS, similar to Helix cloaking. It only
takes 2k to load NIOS.EXE, and the network card driver runs in protected
mode. Most cards had a Client32 driver, and those that don't, sometimes
you can substitute the Novell 32-bit .LAN driver (like SIS900).

I have a working config for a Realtek 8139, they had good drivers for
Novell. Not all cards did, some were buggy.

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.

[T. Ment]

Post by T. Ment
My config uses ODINSUP for MS-LANMAN 2.1 NETBEUI basic redirector

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

[Grant Taylor]

Post by T. Ment
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?

[T. Ment]

Post by Grant Taylor

Post by T. Ment
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?

Yes.

[Grant Taylor]

Post by T. Ment
Novell also had Client32 for DOS, similar to Helix cloaking.

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.

Post by T. Ment
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?

Post by T. Ment
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.

Post by T. Ment
The network config also works with Windows 3.11 (not WFWG). It took
some time to find the right magic, but it seems stable.

I think that's fairly typical of most of the DOS based networking options.

[T. Ment]

Post by Grant Taylor
What can you do with Client32 that doesn't include a NetWare server?

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

Post by Grant Taylor
That might be all that's needed to play an old IPX based network game.

Right, ipx.nlm is a separate module.

Post by Grant Taylor

Post by T. Ment
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?

No. but it to works with it, using ODINSUP as a shim.

Post by Grant Taylor
Or is it just the stock Microsoft's LAN Man client / redirector for DOS?

Right.

Post by Grant Taylor

Post by T. Ment
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.

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.

[Grant Taylor]

Post by T. Ment
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

ACK

Post by T. Ment
Right, ipx.nlm is a separate module.

ACK

Post by T. Ment
No. but it to works with it, using ODINSUP as a shim.

ACK

Post by T. Ment
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.

Intriguing.

Post by T. Ment
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.

[T. Ment]

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.

Seems to me the socket API would be independent of the transport. But
that's all I know about that.

[T. Ment]

Post by Grant Taylor

Post by T. Ment
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.

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.

[Grant Taylor]

Post by T. Ment
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

Post by T. Ment
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. ;-)

Post by T. Ment
But all that is separate from winsock.

Agreed.

I was wondering if there was a DOS SOCKET counterpart that supported
TCP/IPX.

Post by T. Ment
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.

ACK

[T. Ment]

Post by Grant Taylor

Post by T. Ment
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

Post by T. Ment
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. ;-)

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.

[Grant Taylor]

Post by T. Ment
I have that book. But I'm not talking about Microsoft DOS INT calls.

Ah.

Post by T. Ment
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.

[T. Ment]

Post by Grant Taylor

Post by T. Ment
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.

Probably. They wrote some apps for their 16-bit TCP kernel, like FTP,
which presumably used the INT API, instead of the DOS socket library
they released to the public. That FTP client still works with Novell
TCP32.

Post by Grant Taylor
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.

So much code, so little documentation.

It's always about the money. When the market dies, nobody cares anymore.
All that knowledge goes in the trash.

[T. Ment]

Post by T. Ment
Novell also had Client32 for DOS, similar to Helix cloaking. It only
takes 2k to load NIOS.EXE

NIOS.EXE was created in a time before large memory systems. They later
released a fixed version, but I prefer the original that comes with the
client32 package.

On large memory systems, DOS 6.22 himem.sys only sees 64MB, and that
works fine. Later versions of himem.sys may be a problem, because they
can see more memory.

Himemx.exe with its memory limiting /MAX parameter also works. On one
computer of mine with 512MB ram, NIOS works with /MAX=450000, but fails
with 460000. Not sure why the cutoff is not an even 512MB.

Another trick with NIOS is how it's loaded. By default, it loads itself
high, and that can make it fail. This trick:

lh /l:0 c:\net\nios.exe

works on the computers I have.

If used with Microsoft EMM386.EXE, NIOS may also need the /MV parameter,
but they say it's slower. You can also run without an EMM, in real mode:

device=c:\bin\dos622\himem.sys /testmem:off
device=c:\bin\umbpci\umbpci.sys

Windows 3.1 can be also a problem. Fixing up system.ini with:

EMMExclude=a000-ffff
NoEMMDriver=true
UseROMFont=false
SysVMIn2ndBank=false

Seems to make things work. Not sure about the last two parameters, but
Helix Netroom insists on them.

If you want to try client32, I can post my startup files. Without a road
map, it's easy to get lost in the details.

[T. Ment]

Post by T. Ment
Windows 3.1 can be also a problem

I should also mention, himemx.exe works with NIOS, but not Windows 3.1.
Jack's xmgr.sys has the same problem.

The only way I've found to get everything working, both NIOS and Windows
3.1, is to use himem.sys from DOS 6.22 or Windows 3.11. A binary compare
using "fc /b" says they are identical.