And to be fair... theres no reason you can't run multiple DDLINKs in a multitasking environment

DDLINK is an end-to-end program and does assume you know what you are doing

You can run as many pairs as you lile with different packet types.

Or with same types, just started in pairs
(Server, client) .. once connected the lan is a simple wire

DaveDDS wrote on 2026-01-12, 23:04:

And to be fair... theres no reason you can't run multiple DDLINKs in a multitasking environment […]
Show full quote

And to be fair... theres no reason you can't run multiple DDLINKs in a multitasking environment

DDLINK is an end-to-end program and does assume you know what you are doing

You can run as many pairs as you lile with different packet types.

Or with same types, just started in pairs
(Server, client) .. once connected the lan is a simple wire

I totally agree, I was only looking for an interrupt function that could answer to simple questions like whether the program is active, which resources are being locked, instances running, type of interface being used (com, lpt, eth, other), version, etc., the more the merrier... Perhaps asking way too much... 😀

I perfectly understand I am not being realistic in this day and age, but I couldn't help myself for trying to ask anyway.

Does multitasking dos not have a method to show/query whats running?

Yeah, that might not tell you the command options that were selected... but... is there a standard for pgms reporting that?

Or should I spend a few days designing and implementing a proprietary comprehensive reporting interrupt so that 1 (or maybe 2) users could write the softwate which would be needed to make use of it?

Sorry for the snark hopefully this helps see a point!

DaveDDS wrote on 2026-01-13, 00:24:

Does multitasking dos not have a method to show/query whats running? […]
Show full quote

Does multitasking dos not have a method to show/query whats running?

Yeah, that might not tell you the command options that were selected... but... is there a standard for pgms reporting that?

Or should I spend a few days designing and implementing a proprietary comprehensive reporting interrupt so that 1 (or maybe 2) users could write the softwate which would be needed to make use of it?

Sorry for the snark hopefully this helps see a point!

Your point has been already understood long ago. That doesn't invalidate making a polite request.
Your program, your goals, your design choices.

I am sorry if I insulted you somehow by asking. That was not clearly the intention.
Bye.

I don't feel "insulted", I'm just having a hard time figureing out how to reply to repeated responses which essentially say (paraphrased): "I completely get that the feature I requested may not be appropriate or desireable ...but... I'd like to restate the request while pointing out how appropriate and desireable this feature is" - still seems to be a lack of communiction...

BTW: If your mt-DOS can't tell you if a process called "DDLINK" is alreatd running, you MAY be able to tell via the network interface (but I don't know how your mt-DOS handles packets to self - YMMV)

Broadcast a LINK_INIT packet with a wrong/bad version ... if a DDLINK server is active it will respond with a reject (and indicate the version which is running)

The "from" MAC would tell you if it is local or remote.

Just in case anyone else could use this...

I often work on my "realDOS" systems which are located in my basement, far away from my upstairs office - to move files to/from them as I Work, I leave a DDLINK server running in DosBox upstairs, and use DDLINK client under DOS as needed.

This works very well, but there are couple of cases where I wanted more:

- If things fail badly enough the server sometimes "gives up" and terminates. This happens very rarely, not enough to be an actua problem, but I addressed it.

- Sometimes I want to execute a command on the server ... usually to MOUNT a directory or things like that.

In either of these cases, I have to leave my bench downstairs and go up to my office to address it... so I wrote this little tool to run DDLINK as a server without direct supervision.

1C:\> DDLSVR -?
2DDLink SerVeR
3
4use:    DDLSVR  [batloc] [options]
5
6opts:   -Sn     set (DosBox) cycles on Start (lower overhead)            [5000]
7        -En         "   "   "   "   "  End/Exit                         [40000]
8        -Dn     set Delay after commands    \                               [0]
9        -C      disable client Commands      >see -?C
10        -K      Keep [batloc].BAT           /
11        -V      Verbose (show commands)
12
13Runs DDLINK as a network server with some "extras":
14    Auto-restarts if an operation fails(badly)
15    Execute commands on server                see -?C
16
17C:\> DDLSVR -?C
18CmdDir: R:\DDLCMD.BAT
19
20To execute a command on this server from the client, send the command(s) in the
21above file, then make serverDDLINK exit (errorlevel 99) > DDLINK P= E=99
22
23DDLSVR will delete this file after running it unless option: -Keep
24
25[batloc] is location of this file, if not given, %TEMP% is used, if %TEMP%
26not SET, defaults to my ramdrive:  R:\
27  If this location ends with '\', "DDLCMD.BAT" is appended!

This will get added to my distribution the next time I update it... if anyone wants it sooner, let me know and I can rush an uppdate.

I've not published this yet, but I can make it available on my site if anyone wants...

If you've read this thread you'll know that I designned DDLINK to be a super-simple and easy way to transfer files between DOS systems without a traditional network. It also works well to transfer between "modern" systems and DOS - or even two modern systems in cases where you don't want to use a network.

But... being a DOS program, DDLINK.COM doesn't run on Win64 ... The simple way to work around this is to run it under a network enabled edition of DosBox.

If you have DosBox installed and working on your network, this is easy. But I've helped out enough people who want to transfer files to/from DOS systems who don't use DosBox or are familier with the intracasies of installing and configuring it to work, that I've created:

DDLBOX - a minimal DosBox which is already set up for and has the components needed to do DDLINK transfers. It's main "features" are:

- Based on an older/simpler/smaller edition of DosBox - minimal "footprint".

- Does NOT have to be installed (just go to it and run)

- Minimal setup - it offers a resonably comprehensive DosBox config menu, but most will only want to pick a location (or two) on the host system where files can be transferred.

- Fairly simple main menu to select DDLINK over LAN (or COMn) as a server or client, View docs etc. This basically opens and closes like any other native host application and you don't have to "think" about DosBox.