COMPAQ ISA PC to ethernent

Grant Taylor cctalk at gtaylor.tnetconsulting.net
Sat May 22 12:16:35 CDT 2021


On 5/20/21 9:09 PM, Tomasz Rola via cctalk wrote:
> I assume there is Windows on the Compaq?

I think that it would need to be Windows for Workgroups; 3.1 / 3.11, to 
include networking support.  Depending on the class of hardware that 
Randy's Compaq is, that may be a tall order for the system.

> If you only want "some" connection, not "fastest possible", then I 
> would go with serial cable (I think the special one - so called "null 
> modem" is required, but there are probably receipts for making one) 
> via some kind of Unix laptop to connect with the rest of the world.

The venerable options of LapLink and / or InterLnk (InterSvr) come to 
mind for transferring files.

I've also seen a number of older DOS based networking things that are 
completely proprietary communications protocols.  EtherDrive (?) comes 
to mind.  --  I know that there are old threads on this list talking 
about them.  I think I started some of them.

> I think your options are briefly described here:
> 
> - TCP over RS-232 with Windows 3.1 and Internet Explorer 5 dialer
> 
> https://retrocomputing.stackexchange.com/questions/9018/tcp-over-rs-232-with-windows-3-1-and-internet-explorer-5-dialer
> 
> PPP or SLIP protocols for serial line, then some net routing on 
> laptop. Trumpet Winsock was the name of software that did such trick 
> for me 25 years ago, when I configured and connected Windows95 on 
> Pentium without net card to the Linux box, using PPP. It was not 
> perfect but mostly worked.

TCP/IP is one of many network stacks that could be used.

I personally somewhat question the value of TCP/IP on early computers, 
mostly because I'm ignorant of viable client applications.  As in the 
web browsers that existed for the time can do very little today without 
a lot of help.  Telnet / rlogin are mostly dead for security reasons. 
And I'm not aware of any SSH / HTTPS implementations that have been 
created for old OSs.

Thus, file and printer sharing are the main things that networking older 
systems seems to offer to me.  With that in mind, it seems to me like 
other network stacks might be easier to work with; IPX (NetWare), 
NetBIOS (IBM / Microsoft / Artisoft), DECnet (Digital), Vines (Banyan).

> - MINUET for DOS
> 
> https://en.wikipedia.org/wiki/Minnesota_Internet_Users_Essential_Tool
> 
> You may have some basic clients in this package, provided they are 
> still relevant in modern web environment (and if they are available 
> to download). On the page above there are some links you may follow.
> 
> Things could be better if you had something Unixy on old computer, but 
> web browsing is not going to be fun, just passable experience. Other 
> protocols - like, for sending mails - could have moved on too and it 
> is hard to tell what current servers will tell if you try old clients 
> with them... You will find out :-) .

Ya.  Hence why I think TCP/IP for contemporary Internet on old computers 
is so problematic.

There are some SSL/TLS stripping proxies that can be used to allow 
clients that don't support contemporary web security standards via the 
intermediary gateway almost doing a protocol conversion between 
unencrypted and contemporary encryption.  Then you get into old browsers 
not understanding contemporary HTML.  Let's not even think about HTTP/2.

Fortunately, SMTP hasn't changed much.  Sure, there's now ESMTP, but 
many / most systems will fall back to stock SMTP with little difficulty. 
  The biggest hurdle that I see is authentication and the likely need to 
do that over an encrypted channel.  Fortunately it's trivial to stand up 
a private contemporary SMTP server that will allow retro clients to 
communicate in retro methods and then turn around and speak contemporary 
methods to contemporary servers.

> One of the thing you may want to be wary is, old terminal emulator 
> (on Unixy OS) may not be prepared for some fancy attacks, when, say, 
> something (a command or an email being viewed in your mail client 
> on the terminal) produces certain charcter squence and makes your 
> terminal do things...

Unicode and UTF-8 immediately come to mind.

Though I would hope that a proper TERMCAP and well behaved client 
software would largely work around most of that.

> For example (this one is few days old):
> 
> - rxvt-unicode: possible remote code execution
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1961794

Yep.



-- 
Grant. . . .
unix || die


More information about the cctech mailing list