I always used FastLynx back in the day. Similar program, similar concept-- even similar "Midnight Commander" inspiration on UI.
Glad to know that there is a "No, really-- please use this! I dont charge for it!" alternative, since the maker of FastLynx still exists, and wants your money still. (See below, re:licensing) I will add it to my toolkit, and give it a whorl someday.
As for running NetWare... I'm not sure that's really the best solution in the modern era. Granted, ODI packet drivers do tend to consume less memory than MS's NDIS 2.0 drivers, the latter is better able to coexist peacefully (with a little prodding) with a modern fileshare.
Further complicating the netware angle, was the fact that Novell liked to sell their product with "Seat Licenses", and unless you happen to have license files from the days of yore tucked away in a filing cabinet, that's not really possible to deploy legally for the majority of people. The microsoft networking supplement for dos, on the other hand, has no such licensing restrictions going on.
(Disclaimer-- I have the dubious distinction of being a Certified Novell Administrator for Netware 5. Lucky me. 😜 )
Recently used DDLINK to transfer data to a system that is "externally I/O challenged," and despite the 8250 UARTs, the 19200 bps serial rate, and the wireless RS-232 transceivers involved, the solution exceeded my expectations.
Recently used DDLINK to transfer data to a system that is "externally I/O challenged," and despite the 8250 UARTs, the 19200 bps serial rate, and the wireless RS-232 transceivers involved, the solution exceeded my expectations.
Always good to know that some people still use this stuff and derive some benefit from it! - thanks
Bit of a story behind DDLINK - not sure exactly when I wrote it - earliest reference to in I've found so far in my own files is
1990 - really needed it back then - Not only did I have quite a few "not networked" DOS systems, but ...
As part of a few large projects I did for major clients where I had developed much of fairly complex products (usually ARM based) , built
on top of my own/unknown multi-tasking operating system . This OS had some basic network capability (units on the same network
could communicate with each other) - but no standard/known protocols. So I created a process which was a DDLINK server (much easier
to implement than most other network software) This let us easily put various necessary files on/off such systems "on the fly".
In more recent years I'd all but forgotten about it - till I was setting up a new ImageDisk system which didn't have reasonable access
to a network (MS client no-longer connects to modern systems) - took a few days of "trying stuff" before I found something in my
archives referencing DDLINK and realized that I'd solved this problem before! - Of course modern system can't run DDLINK directly
but it was fairly trivial to use within a DosBox that had NE2000 emulation.
Recently used DDLINK to transfer data to a system that is "externally I/O challenged," and despite the 8250 UARTs, the 19200 bps serial rate, and the wireless RS-232 transceivers involved, the solution exceeded my expectations.
... (MS client no-longer connects to modern systems) -...
Not exactly true... but it IS disabled by default.
Microsoft disabled it for a reason: SMB1.0 is a great big "KICK ME!" sign to basically every known network worm that affects windows networks, and a "I am SUPER EASY" to all those crypto-ransomware things floating around. However, the ability is still there, just disabled by default.
You may also need to turn on "Insecure guest logons" with the group policy editor, since that gets disabled by default also. (Otherwise, you have to configure your legacy clients with Active Directory.)
... (MS client no-longer connects to modern systems) -...
Not exactly true... but it IS disabled by default.
Kool - I didn't know this (to be fair - I never really looked into it in much detail) - I don't use old systems nearly as much these days, but I do still have a
few XP's that I might look into making able to sometimes connect to newer stuff - all my older systems are blocked from access to/from "the world"
(on their own "local only" network - so I don't expect the "kick me" sign to be much trouble 😀
I do still have a few XP's that I might look into making able to sometimes connect to newer stuff
Apologies - my confusion (seems to happen more frequently after my events of 2019 *) - XP will connect to many modern systems
without having the change settings ... my problem with XP was that it won't connect to my new network. A few years back I upgraded
to super-fast fiber, and that came with a new router to connect to the fibe.
Like much modern tech, it seems to have be "improved" so much it no longer works with some older stuff.
I haven't looked into it in detail either - but basically it can see the WiFi network but cannot connect to it.
I of course came up with an "easy fix" - I just dug out one of my old WRT54Gs and configured it as a "dumb" access point (no DHCP etc.)
My XP netbooks can connect to it just fine and everything works!
(* throughout my career chatting with other professionals in the business - we would often joke that the weird thing that others
often created were because of "brain damage" - I can tell you from personal experience ... when it really happens to you .. it's
about as far from funny as it gets!)
that sounds like your wifi card/dongle can't do wpa2.
depending on the device, a driver upgrade might fix it.
Quite likely.. I just haven't bothered to "figure it out" or "find" drivers suitable for these old machines. I have a couple of the original "Aspire One" netbooks
- Atom based TINY WinXP systems. I still use them from time to time as really small/portable DOS compatible platforms.
As I don't do internet stuff on them, and older router solution was super-easy and didn't take any significant time - I only mentioned it as my previous post
had confused this problem with another one and wanted to "clarify".
Just in case anyone is interested / still using DDLINK, I've just made "Yet
Another Update" - a new command line option that lets it "fake" the
reported/required protocol version.
Just in the last rev, I added a message in the protocol so that the client
could cause the server to exit with a specified error-level. Super-handy in
batch files - I often have DDLINK auto-run on a remote system, and being
able to cause such an exit makes it easy to "do other stuff" within that
batch file.
But.. DDLINK in it's focus on efficient/small, simply looks at the protocol-
version in LINK_INIT to decide if it can/can't accept the session. This
insures that "everything works" in that you are running the same protocol
version on both ends.
The problem I ran into was having dug out an old non-floppy DOS system, I
couldn't DDLINK things to/from it anymore as the protocol version had changed.
-- and it was not easy to get a serial connection to serial-bootstrap --
So.. I added option to override protocol version - since basic transfer msgs
haven't change since 1.0 - this lets me do simple transfers - other "newer"
functions may not work, but at least DDLINK can update itself! (and it worked
perfectly - older DDLINK had no problems getting DDLINK.COM from the new)
I was about to drop in here and say that this is a problem that Ethernet solves, but there are plenty of good uses cases where a straight serial or parallel connection without drivers or a TSR would be ideal. This is very cool. Thanks for sharing.
Out of curiosity, would this be able to leverage otherwise dead weight 56k modem connections to transfer files? Lots of early laptops have an integrated modem but no Ethernet.
Out of curiosity, would this be able to leverage otherwise dead weight 56k modem connections to transfer files? Lots of early laptops have an integrated modem but no Ethernet.
As long as it is a "pure binary" connection, it should work - DDLINK doesn't know of care what the serial connection is
going through - as long as it's setup and working when DDLINK starts. (so you'd have to dial/connect a modem first).
The default serial speed is 115200 (fastest standard PC serial speed), but you can set this with a command
line option: eg: c=1,19200 (COM1 at 19200) - don't forget to do this on both the client AND server side!
If the laptop has parallel, it would be a LOT faster - but you'll probably need another DOS system to connect it to
(I've not gotten hardware LPT port access to work reliably in DosBox - Serial and LAN do work fine)
Is parallel going to be faster than serial and modem? I understand that there are several different parallel standards as well, some faster than others.
Serial requires bits be "dribbled" out 1 at a time at the selected baudrate
(plus start/stop bits etc.) the overhead of the software in nothing compared
to this ... so your transfer rate will be 1/10 the baud rate... 19200 bps
would give you about 1920 char/sec.
Network is 10 or 100 mbits, no start/stop, but some packet overhead...
so very "rough" guess - 125k/1250k chars/sec. Software overhead will be
considerably more ... which will make actual transfer rate somewhat less
than that.
Network also has it's own "packet overhead" which eats a number of bytes
of every transfer.
Parallel sends 4-bits/time, and software overhead is very low (write 1st 4
bits, drop control, write 2nd 4 bits, raise control) - theoretically a
significant portion (almost half) of local memory->memory transfer speed.
It is artificially slowed down considerably in order to account for external
cable/interface speed and allow the remote end to have plenty of time to
detect/assemble the 4-bit blocks into 8-but characters...
Serial and Parallel both use only the DDLINK "packet" overhead, typically less
then a dozen bytes per 1024 byte packet.
In practice, I find serial noticeably slower (consider that I'm typically using
the maximum 115200 - lower rates will slow it down even more) - but usually faster
than other serial transfer methods. LAN and LPT are much faster (pretty much instant
for small files) with LPT having a slightly noticeable advantage for huge files.
I happened to be testing some classic RS-232 serial port performance. Here are my results on that:
WIRELESS (wimodems):
1Using 20MB test file (modern-PC to modern-PC, or ZOC to ZOC). 2 3---------------------------- BELOW: (normal wifi modem @ about -50 dBm) 4[ use ATDT<IP>:<port> to connect one WiModem232 to another on the LAN ] 5ZModem @ 38400 --> 3.6KBps (many re-try errors but maintained decent rate) 6ZModem @ 57600 --> 0.4KBps (too many errors, gave up; did not complete xfer) 7 8YModem @ 57600 --> 1.9KBps 9YModem @ 115200 --> 2.8KBps 10YModem @ 230400 --> 3.7KBps 11YModem @ 460800 --> 5.0KBps 12(921K did not work; tried shorter/better cable and also tried 8-N-2 instead of 8-N-1, no effect, still did not work) 13 14---------------------------- BELOW: ("NULL-MODEM MODE" on WiModem, basically wireless-via-Bluetooth) 15[ on older WiModem232 do AT*NULLMODEM0 ] 16[ on newer WiModem232 Pro do AT*CABLE0 ] 17YModem @ 115200 --> 6.7KBps 18YModem @ 230400 --> 10.6KBps 19YModem @ 460800 --> 13.0KBps 20ZModem @ 460800 --> ~3.0KBps (while transfer worked, many re-try errors hindered the throughput) 21(921K did not work; TBD with new cable)
SUMMARY OF THE ABOVE: YModem is actually superior during a wireless exchange (the speculation is that ZModem requires some specific timing-window requirements, which isn't practical on a variable speed WiFi connection)
The first set of results above is using Y/ZModem over (Basically) WiFi TCP/IP. THe second set of results above is the "null modem" mode of the WiModem232, that uses Bluetooth instead of WiFi. And yes , KBps is Kilobytes per second. This is still with modern equipment (i.e. both sides of the connection using USB-to-serial adapters that have large tx/rx buffers, but are still using RS-232 voltage swings).
The results below are WIRED across a variety of systems, which the point being to demonstrate how fast those system can push data out to their connected system. In these cases, on the older x86 side I ran conex 7.5 (a late 90's terminal program "written in assembly" (but one of the newest yet still 16-bit MS-DOS compatible terminal programs I could find) -- I don't know if the Y/ZModem implementations it has were also done in assembly).
1With wired null-modem cable between... 24.77MHz PC 5150 to Modern PC --> 0.9KBps (ZModem @ 9600 baud, 19200 and 38400 did work but at 0.6 and 0.8 KBps {excessive errors}, then did not work at all at 57600; conex 7.5 to ZOC) 3286 to Modern PC --> 2.3 KBps (ZModem @ 57.6K, faster was not reliable; conex 7.5 to ZOC; no errors reported, so unsure why this couldn't get over 5KBps; maybe FIFO throttled or need better cable, idk) 4486 to Modern PC --> 11.3 KBps (ZModem @ 115.2K, conex 7.5 to ZOC; this needed a few error corrected retries, indicating on the edge of performance, i.e. a poor quality cable could reduce this) 5Pentium to Modern PC --> 11.1 KBps (no retries, ZModem @ 115.2K under WinXP HT to ZOC; feels non-stressed) 6Modern PC to Modern PC --> 18.9 KBps (no retries, YModem @ 460K, Windows ZOC to ZOC) 7Modern PC to Modern PC --> 44.9 KBps (no retries, ZModem @ 460K, Windows ZOC to ZOC; state-of-the-art :) sort of, there are some 30MHz clocked UARTs out there by SIIG) 8(not stable at 921K, unable to transfer files)
Again, I couldn't achieve 921600 even on the modern PC. By "modern PC" I am meaning i7-laptops at >2GHz.
The only USB/serial adapter I'm coming across that sincerely supports 921600 is "Thunderlinx™ USB 3 to Serial Adapter" (which is expensive), but the cheaper USB/serial adapters I show to handle 460300 baud ok.
My question is, for DDLINK, is there a listener on the modern-PC (64-bit Wintel) side across a USB-parallel adapter that could receive the parallel data? I would like to verify the parallel processing is faster data throughput, but I don't have code on a modern Win7/10/11 setup ), and I don't have anything on the modern PC side for Laptlink, Interlink)?
Last edited by voidstar on 2025-02-23, 16:01. Edited 5 times in total.
I happened to be testing some classic RS-232 serial port performance.
Did you try File Maven 3 (DOS) already? It's a nice tool.
It supports 3-wire and 7-wire null-modem cables an can do up to 115200 Baud.
It also has a parallel port mode for LapLink cables, I think.
Edit: For testing purposes, I mean. Not as a substitute to DDLINK.
It just came to mind because I had used it years ago to connect an old PC to a PC running DOSBox (via null-modem, it's in my YT channel).
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel
... My question is, for DDLINK, is there a listener on the modern-PC side across a USB-parallel adapter that could receive the parallel data? I would like to verify the parallel processing is faster data throughput, but I don't have code on a modern Win7/10/11 setup ), but I don't have anything on the modern PC side for Laptlink, Interlink)?
DDLINK is a 16-bin .COM ... it won't run at all in Win64 (I use DosBox to do so)
It will run in Win32, but Win doesn't allow direct access to most hardware...
There is software available to enable this, but Win "twiddles" the LPT pins from
time to time (probably looking to see if a printer has been attached)
So... although LPT connection works very well under DOS, I've not had good luck under Win ...
And even if there wasn't the above problem ... DDLINK performs LPT transfers by directly
manipulating the LPT hardware on a pin basis ... It knows nothing about USB (DOS program)
[and although Win32 "emulates" serial port hardware for DOS program, it's not great and
can be slow]
Also BTW - The original PC design used 8250 UARTs for the serial ports .. and DOS doesn't
have native fast/interrupt-driven serial port functions ... DDLINK (and most other DOS
software) performs serial I/O again by directly accessing the hardware assuming it's
an 8250 UART.
The primary serial speed on the PC 8250 UART clock is 115200, and the 8250 sets it's
baud rate with a simple divisor :
115200/1=115200 /2=57600 /3=38400 /4=28800 /5=23040 /6=19200 ...
So... while you can get fairly "fine" on lower speeds: /48=2400 /47=2451 /49=2351
higher speeds are quite fixed: 115200,57600,38400,28800 ...
and you just can't configure the serial port to "in between" speeds..
Right, I get DDLINK.COM is legacy application for 16-bit MS-DOS. Same for MS-DOS 6.22's INTERLNK, and LapLink. So we can do "MS-DOS to MS-DOS" transfers with those tools. Just seem using a USB/parallel adapter, we should be able to get 64-bit build of a tool that can transfer with the same file-exchange protocol as the 16-bit tools. I suppose after all these years, no one has bothered to write that natively for a 64-bit runtime since (1) generally you can just use a NIC instead even for as far back as the 1981 IBM PC ISA bus, (2) you're saying DOSBox can run it? (which can write to your host file system). But I started looking at RS-232 serial exchanges since I'm using other various non-ISA / non-MS-DOS systems (POLY88, NEC 8800, Model 100, GRiD OS, PC-5000).
Then I also started exploring "how to beat 115.2K baud" (or how to get past ~10KBps throughput, without a NIC). For older below-12MHz-systems, I don't think there is much hope on that (with standard RS-232 at least). For example, the serial card for the X16 we used a 14.7456MHz clocked UART, but the overall 8MHz system still can't push much past ~10KBps throughput in a dedicated data stream (where you actually do something with the data, like display it or write to file).
But with a Pentium or higher end 486, combined with a 7.3728MHz equipped 16550, it might have a chance (but you're right, existing legacy software is "tuned" to divisors suited for the 8250 or more specifically the 1.8432 clock used with it -- which I saw that speed was used in the earlier POLY88 from 76/77, not really originated from the IBM PC). I just got those higher speed serial cards recently and will see how a 386 handles them. People have gotten some amazing speeds across the C64 user port (not sure if using 4-wire or full 8-wire) at its stock clock speed. That got me to recalling about Laplink, and then I came across your DDLINK 😀
I'd still like something that goes MS-DOS to modern-Win64 more natively (via a USB-dongle of some sort, without DOSBox). Note, I was recently surprised by that "wireless-null-modem" (Bluetooth) support in the WiModem232 (requires two WiModem232's in close proximity to each other, then they are "locked" into that mode until you power cycle the device).
Has anyone tried DDLINK.COM under OS/2 ?
Attached is a "UART clock chart" I've used in some of my testing, where I've had to play with clock dividers across different systems.
Then I also started exploring "how to beat 115.2K baud" (or how to get past ~10KBps throughput, without a NIC). For older below-12MHz-systems, I don't think there is much hope on that (with standard RS-232 at least).
IMHO, the Z80 SIO and DART were more elegant than i8250.
Z80 systems often used either of them.
Fossil drivers maybe can provide compatibility with non-standard serial ports.
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel
Right, I get DDLINK.COM is legacy application for 16-bit MS-DOS. Same for MS-DOS 6.22's INTERLNK, and LapLink. So we can do "MS-DOS to MS-DOS" transfers with those tools. Just seem using a USB/parallel adapter, we should be able to get 64-bit build of a tool that can transfer with the same file-exchange protocol as the 16-bit tools. I suppose after all these years, no one has bothered to write that natively for a 64-bit runtime since (1) generally you can just use a NIC instead even for as far back as the 1981 IBM PC ISA bus, (2) you're saying DOSBox can run it? (which can write to your host file system). But I started looking at RS-232 serial exchanges since I'm using other various non-ISA / non-MS-DOS systems (POLY88, NEC 8800, Model 100, GRiD OS, PC-5000).
...
I've toyed with the idea of writing a DDLINK server side for Win..
- I have implemented a DDLINK server as part of some software I did for a
clients ARM based device - It had network ports to "talk" to other units,
but didn't support any of the usual file transfer or drive sharing
protocols - DDLINK made it very easy to put "files" on/off.
I've not found enough reason to actually do it under Windows. I generally
don't like doing much stuff like that under Windows... I don't like having
to spend most of my time dealing with OS things that make it very hard and
complicated to do this kinds of thing I want.
For example, one of the simplest C development toolsets I've found so far
(and the one I tend to use for small tools) is LCCwin32 - it has 922 files
and occupies about 32m of disk space (There's more that 400/10m of header
files alone).
I still do a LOT of stuff under DOS, and I use my own Micro-C toolset:
30 files, 19 headers, about 700k of which >500k is documentation!
I haven't found a good way to do serial I/O under LCC - nice fast
interrut driven functions are build into the Micro-C library!
If I want to "rip something simple" out in Micro-C under DOS, it usually
takes me couple minites (might be an hour or two it it's something really
complex).
In Winblows with LCC, I spend days/weeks trying to figure out how to make
some fairly simple things happen ... It's just not worth it to me!
Btw, I tend to use my own "adjusted" older version of DosBox (formerly
called "MegaBuild6") - It does most everything I need for DOS (I have fixed
some really annoying bugs) ... and it's "small"(by Windows standards at least)
- < 2.5m of .EXE and .DLLs doesn't have to be "installed" (I can just copy
in on to a system and run it)
and ... It supports NE2000 network card emulation, meaning DDLINK works
within it over NETWORK - this is the main way I move things to/from my
various DOS systems
