Thanks for making all your work available in one way or another. And glad you're healthy enough to do stuff like this!

If you're able to run a VM, you're able to run Netware in there, and that's the best way to network DOS and old Windows to modern systems I think.

jharrison wrote on 2022-12-24, 18:55:

If you're able to run a VM, you're able to run Netware in there, and that's the best way to network DOS and old Windows to modern systems I think.

Hi. Since you mention IPX/SPX, an alternative to that might be old AppleTalk (AFP via DDP).
It's LAN only and there's at least one DOS client for it. It can use NE2000 NICs and works with WfW, too.
Mac OS X 10.2 (10.3), Windows XP (via Win2k protocol driver) and earlier are compatible to it.

Edit: EtherDFS is also an alternative.
Edit: Just realized, I'm too chatty. Never mind.

I did not knew this existed, I will add it in my UTILS directory 😀
Thanks for sharing DaveDDS!

oso2k wrote on 2022-12-24, 00:22:

Thanks for making all your work available in one way or another. And glad you're healthy enough to do stuff like this!

Thanks, what happened to me in 2019 was a real "perception changer"!

I've been in this industry since the 70's and I've written a *LOT* of stuff over the years.

And being anal about "not losing it" I've kept multiple backups of pretty much everything!

It's been kinda in my mind lately the publish/release most of it (some i can't because it was contracted by others), but a lot of it I can...
It's going to take months/years but if all goes well, you will see some more dribbling out eventually.

I'll warn that it won't all be "pretty" - over the years there have been a lot of special purpose and one-of tools that I've made for my own use, there's
been systems written around my own custom hardware, so I'm sure a good chunk of it won't be very useful to anyone else...
but I figure it might still be interesting/informative to some...

Sorry, just some random thoughts!

Dave
Dave Dunfield ::: https://dunfield.themindfactory.com
or: "Daves Old Computers" -> Personal (near bottom)

jharrison wrote on 2022-12-24, 18:55:

If you're able to run a VM, you're able to run Netware in there, and that's the best way to network DOS and old Windows to modern systems I think.

DDLINK differs from most other DOS "networking packages" in some very positive ways:

- It doesn't have to be "installed" (just run)
- It's TINY - easily have on bookable diskette!
- It works over LAN, Serial and Parallel interfaces - can communicate with most any DOS system
- It can "bootstrap" itself to a new DOS system with only a serial connection
No software required on target, nice way to get files off/on systems that don't
have floppy/CD/networking working or suitable software!.
- DOSBOX makes it workable on many non-DOS systems!
- It's free and easily available

Dave

DaveDDS wrote on 2022-12-26, 16:26:

DDLINK differs from most other DOS "networking packages" in some very positive ways: […]
Show full quote

DDLINK differs from most other DOS "networking packages" in some very positive ways:

- It doesn't have to be "installed" (just run)
- It's TINY - easily have on bookable diskette!
- It works over LAN, Serial and Parallel interfaces - can communicate with most any DOS system
- It can "bootstrap" itself to a new DOS system with only a serial connection
No software required on target, nice way to get files off/on systems that don't
have floppy/CD/networking working or suitable software!.
- DOSBOX makes it workable on many non-DOS systems!
- It's free and easily available

Dave

All that reminds me of fastlynx, though no idea if it works ok in dosbox .

Thanks, Never tried it -... just from "looking around" - FastLynx 3.3

- Not free

- Big! - the "demo' I found is 1.2M (DDLINK is 15K - my download DDLINK.ZIP is 37K, but that includes some documentation and source to a .C program to help "figure out" the protocol).

- FX33DEMO.EXE contains "This program cannot run is DOS mode." - not sure if it is DOS... might be an "installer" (DDLINK doesn't have to be installed), but even so - definitely can't be done in DOS (might be a DOS executable contained in the install package)

I still have a couple "real" DOS systems, but most of what I do in DOS nowadays is in "actual DOS" booted under DosBox (see my DBBD tool)
As I just want a nice simple/small tool to put stuff on/off DOS - I'll stick with DDLINK!

Dave

I only used it in the late 90s, starting 95, no idea what version that was back then and it was definitely possible to get it on a bootable floppy together with the network drivers. It had a norton commander like interface, and yeah, it wasn't and still isn't free, heck it's still for sale for $20

DaveDDS wrote on 2022-12-26, 16:26:

DDLINK differs from most other DOS "networking packages" in some very positive ways: […]
Show full quote

jharrison wrote on 2022-12-24, 18:55:

If you're able to run a VM, you're able to run Netware in there, and that's the best way to network DOS and old Windows to modern systems I think.

DDLINK differs from most other DOS "networking packages" in some very positive ways:

- It doesn't have to be "installed" (just run)
- It's TINY - easily have on bookable diskette!
- It works over LAN, Serial and Parallel interfaces - can communicate with most any DOS system
- It can "bootstrap" itself to a new DOS system with only a serial connection
No software required on target, nice way to get files off/on systems that don't
have floppy/CD/networking working or suitable software!.
- DOSBOX makes it workable on many non-DOS systems!
- It's free and easily available

Dave

I'm appreciative of anyone continuing DOS development so thank you for this work.

Obviously, Netware and your utility are philosophically different. Your utility is a file transfer utility, whereas the other is a full-blown NOS.

I'm somewhat of a frustrated evangelist, I guess, as I see people not embracing Netware on this old hardware, which I feel should be the de-facto method of connecting these types of systems together. That's how it was done back then, and for a variety of good reasons.

I'm the odd-ball though that likes Mediavision, Matrox and SCSI, too.

As for Netware, the joy of a 4K TSR for the whole stack with Client 32 and no hard drives on any of the clients really has an appeal that can't be met with any other product that has ever been on the market.

Netware seems awfully complicated for most purposes and doesn’t interoperate with anything modern. That’s why TCP/IP won. It tolerates 8-bit machines with a serial connection or Raspberry Pi Picos bit banging on a few resistors & a couple wires, as well the latest enterprise server with a fiber 400GbE NIC. A loosely coupled app stack means the user can choose to serve, be a client, anything in between, and do them concurrently or in a rotation. And writing new apps is simpler if you know how to access a packet driver.

jharrison wrote on 2022-12-26, 22:41:

I'm somewhat of a frustrated evangelist, I guess, as I see people not embracing Netware on this old hardware, which I feel should be the de-facto method of connecting these types of systems together. That's how it was done back then, and for a variety of good reasons.

Not necessarily. My father used something different back then, for example.
A derivative of Little Big Lan (LBL). It could create a full-fledged LAN (file, printer sharing, messages etc) by using Centronics ports, V.24 ports, ARCNet and Ethernet (10Base2) NICs. Of course, he also had Netware disks. But Netware wasn't his favorite.

I rarely need full networking in DOS these days... but getting files to/from for example my ImageDisk system (which has to be DOS as it accesses the floppy controller directly, and in very non-standard ways) - As some disk images can be well over a meg... network really helps - DDLINK works very well for me.
(Not to mention that modern systems rarely have floppy drives these days - so not many other fast ways to get images off).

In my more "DOS active" days, I used a little gem called "NEOS.NET" which was a very small and pretty full features DOS networking package - no interop with anything else though...

Later on I pulled the networking components from Winblows which did work independently under DOS (back when Windows ran on top of DOS). MS networking has changed enough so that this no longer communicates with newer systems - I think XP was the last version where I got it to work!

I did at one point make a nice small (<8k) TFTP.COM which also dosen't need anything "installed"and uses only a packet driver (the TCP "stack" is built in).
It let me move stuff to/from linux with little difficulty.

For things like ImageDisk (and anything else which could be more time/hardware dependant), I rarely like a "blob" of "stuff" sitting in memory which could activate at any time - so DDLINK only being loaded when I want it is nice in that regard as well.

Dave Dunfield ::: https://dunfield.themindfactory.com
or: "Daves Old Computers" -> Personal (near bottom)

oso2k wrote on 2022-12-27, 00:17:

Netware seems awfully complicated for most purposes and doesn’t interoperate with anything modern. That’s why TCP/IP won. It tolerates 8-bit machines with a serial connection or Raspberry Pi Picos bit banging on a few resistors & a couple wires, as well the latest enterprise server with a fiber 400GbE NIC. A loosely coupled app stack means the user can choose to serve, be a client, anything in between, and do them concurrently or in a rotation. And writing new apps is simpler if you know how to access a packet driver.

It's the ONLY NOS that can network these old systems with modern ones in a seamless fashion. NCP is agnostic of the transport layer and runs over IP or IPX, or anything else.

jharrison wrote on 2022-12-27, 13:03:

It's the ONLY NOS that can network these old systems with modern ones in a seamless fashion. NCP is agnostic of the transport layer and runs over IP or IPX, or anything else.

Though you've got to run NetWare 5 or newer to run NCP natively over IP and AFAIK only the windows clients supported that, though apparently its possible to get the DOS/Win16 version of Client32 to connect over IP using a few bits from the Windows 9x client. Unfortunately, Mars NWE never got IP support - either native or NetWare/IP, though I've often wondered just how hard it would be to add NetWare/IP support to it.

But NetWare is fairly off-topic on a thread about DDLINK - different tool for a different job (copying files over a LAN vs network drives). Perhaps it would be worthwhile creating a thread for discussing the merits of NetWare for vintage PC networking (something I would love to see more widely used too).

> Thats why TCP/IP won....

TCB has a lot of nice advantages for a multi-site network, but as a couple
others have pointed out, DDLINK is a completely different animal than any
such "standard".

DDLINK was designed to be a very simple way to move things around quickly
betweem systems that may not have been previously set up to do so..

To that end, it does support networking, but unlike TCP it does not use a
routable protocol, and relies on the unique MAC address built into a network
card as an ID. It needs only a "crynwr" packet-driver which are available for
*MANY* network cards, and is a simple TSR you can just load "on the fly".

You don't have to assign it "network addresses", worry about conflicting with
other devices on your network etc... and no need to accomplish this with
things like DHCP!

You literally connect one DDLINK system directly to another if you are using
serial/parallel, or to the same LAN if you are using network.

For serial/parallel, IDing the remote end is simple - it's the one on the
other end of the wire ... but there can be dozens of systems on the "other
end" ot a LAN cable...

When you start a DDLINK "server" it listens for a "session init"
packet of a certain packet type (default is DD11 but you can change).

When you start a DDLINK client, it "broadcasts" a DD11 packet indicating
that it wants to start a session - the server sees this, notes the MAC address
of the client, responds with a targeted packet to that mac address - from this
the client knows there is a server, and knows it's mac address.

After this, all packets are target between the client and server MAC addresses,
there is no other "noise" packets broadcast. They are effectivelly talking to
each ofher "as if" they were on a dedicated cable!

Packets are very low overhead *PacketType(2), *Macs(6+6), SyncByte(1),
FunctionCode(1), Data(...) and *Crc(4)

* These are part of the packet spec! so everything has to have these
(and most have a LOT move "overhead")

When actually transferring file(s), Data has only a two byte file "handle"
and (usually - this can be set) 1024 bytes of file data per packet.

The DDLINK documents have a complete description of the protocol.. it's "been
around" for a while (last rev. I did seems to have been in 2012), but I have
recently added some example .C source to show how to communicate with it!

Dave Dunfield ::: https://dunfield.themindfactory.com
or: "Daves Old Computers" -> Personal (near bottom)

Interesting program! Going to give this a try at some point.

Our LAN back in the 90s was mainly IPX, as many of the DOS games we played used this. We used Kali Chat to transfer files, which worked ok but wasn't the most convenient way of doing it. Just copying entire folders over with Win95 networking was a relief.

Hezus wrote on 2022-12-31, 10:43:

Interesting program! Going to give this a try at some point.

Our LAN back in the 90s was mainly IPX, as many of the DOS games we played used this. We used Kali Chat to transfer files, which worked ok but wasn't the most convenient way of doing it. Just copying entire folders over with Win95 networking was a relief.

Most any "LAN" will support a basic "packets" such as are used by DDLINK - this is the most basic method of communicating over a LAN. All other "protocols" like
TCP/IP, IPX etc. are implemented as one or more "layers" on top of basic packets.

The only trouble I sometimes have is mostly with some WiFi routers - the wired side is almost always a simple Ethernet "switch" which either (in older 10m) systems send everything to all ports, or newer 100m+ systems, only send broadcast packets to every port, and automatically track and "switch" by MAC address... This works fine for simple packet based networking.

I have run into a few Wireless routers where the "switching" between wired ports and Wifi traffic seems to be actual "routing" based on TCP/IP which can prevent simple protocols from properly crossing over.

It's one of my "someday" projects to write a shim to allow simple packet traffic to be converted to/from UDP in order to be able to pass through such switches... but so far it's not been enough of a problem to spend the time! (anyone know if such a thing already exists?)

Dave Dunfield ::: https://dunfield.themindfactory.com
or: "Daves Old Computers" -> Personal (near bottom)

Does anyone happen to know how to reliably enter an END-of-file character
in the FreeDos console during a COPY/B from the console?

DDLINK can Bootstrap itself to another system via the serial port.
It does this by (eg: COM1):

> CTTY COM1: <- User has to do this

> COPY COM1: DDLBOOT.COM
transfers a small binary bootloader program
0x1A <- EndOfFile character to terminate COPY
> DDLBOOT
... transfer the image, DDLBOOT accepts and write DDLINK.COM **
> DEL DDLBOOT.COM

This works well under MS-DOS and PC-DOS, however it DOES NOT work under FreeDos.

As it turns out, MS-DOS and PC-DOS will accept and place any character in the
file except for 0x1A (EOF - this is used to stop the copy).

FreeDos however appears to block many non-printable characters preventing this "almost binary"
transfer from working.

I had the idea that maybe I could do: copy/b COM1: DDBOOT.COM

This does seem to accept/transfer more byte values(*), however it does not
recognize the 0x1A to end the the file, and therefore "hangs".

*Haven't gotten far enough yet to tell if it will be "good enough".

Dave Dunfield - https://dunfield.themindfactory.com