Exactly. Dual-pane file managers modeled after Norton Commander, e.g., Volkov Commander, are used widely on many systems and all […]
Show full quote

Exactly. Dual-pane file managers modeled after Norton Commander, e.g.,
Volkov Commander, are used widely on many systems and all have this set
of shortcuts, from Midnight Commander and Krusader over Double Commander
and FAR Manager to Total Commander. So, a lot of people already know
these shortcuts by heart. In contrast, we need to learn DDLINK keys,
which don't "make obvious sense", when you already know dual-pane file
managers for decades.

I don't know "Norton Commander", "Volkov Commander", "Midnight Commander",
"Krusader", "Double Commander", "FAR Manager", "Total Commander" or most
of the myriad of commercial tools that some people "just love". ** I've
heard of only a couple of these, and most certainly don't know their users
interfaces "off by heart".

DDLINK was something I created for myself (initially a way to move disk
images to/from a DOS booted from floppy to run my ImageDisk tool), and as
I find it very useful, I decided to give it away for others - It was never
a product, I never made money at it - it's just something I needed.

And I simply see no reason to bloat my code with "features" that I don't
want and will never use...

If you so much prefer the user interface from a different tool....
by all means - use THAT tool!

** I differ from many users in that if I need a tool to perform some
specific task, I almost always *write it* - I don't generally use much
"off the shelf" commercial software, because it never does exactly what
I want and/or efficiently.

That's true for the English language, but not for many others.

Always true - but in my experience many foreign users using English language
software know "a little"/"enough" English to be able to use that software.

Sure, perhaps in your preferred language the word for "copy" begins with
{F5} but I don't know what sound F5 makes or how to represent it's character
in prompts on the screen - In other words, regardless of language, I don't
see remembering 'C' for copy any harder than remembering F5 (unless
of course every piece of software in the world is made to resemble your
favorite tool that does copy operations with F5)

Okay, here is a DDLINK.KEY file for your KEYSUB.
Can be loaded as a TSR using KEYSUB.COM DDLINK.KEY -T before running
DDLINK.

I designed KEYSUB to be able to perform "any keys" on keyboard which
didn't have those keys ... but you can certainly use it for things like
this too...

Note: I excluded Alt+F2 (Change Drive), because it would be in conflict
with the global 'Run application' shortcut on my Linux Mint system.

But... are you telling me that there is a version of Linux that uses keys
NOT compatible with your favorite tools? - shouldn't someone be complaining.

.. Another reason to avoid Fkeys where possible. There will always be
something that uses the Fkeys you choose in an incompatible way... Standard
typewriter keys ('A'-'Z', '0'-'9' etc.) are almost always available for
applications to use as they wish.

(we're sorry, but we decided to use 'x' as a overriding system control key
- we've sure our users won't mind not being able to enter 'x' when entering
text)

Sorry - I guess this turned into a bit of a "rant" - touchy subject!

I did some "speed tests" using a test file of random binary bytes
exactly 1 megabyte (binary = 1024x1024 = 1048576 bytes) in size.

Test systems were both running DOS 5.0:
- P3 with NE2000 (compatile) PCI NIC using NE2000.COM packet driver
- P4 with on-board SIS900 NIC using SIS900.COM packet driver

They were connected with:
-10mbps ethernet HUB
-Parallel transfer cable (see DDLINK ?L ) LPT1<>LPT1
-Serial null modem cable (see DDLINK ?C ) COM1<>COM1

Times were measured with a stopwatch.. Pressed START and 'Y' in response to
'C'opy prompt exactly the same time - pressed STOP as soon as the transfer
finished. (so not digitally precise but pretty close)

1        P= : <2 sec
2       L=1 : 24 sec
3       C=1 : 93 sec {default speed 115200}
4 C=1,57600 : 185 sec
5 C=1,19200 : 556 sec
6  C=1,9600 : 1117 sec

I didn't take the time to measure other/lower serial rates, but it's
pretty close to the theoretical maximum - you can calculate "close enough"
if you want lower speeds.

1048576 is 1024 transfers of 1024 bytes each.
Each transfer is: 1(func)+2(handle)+2(length)+1024(data)+2(crc) = 1031 bytes
+ response: 1(func)+2(bytes read/written)+2(error-code} = 5 + 1031 = 1036
1024*1036 = 1060864 bytes in packets

Serial is 1(start)+8(data)+1(stop) = 10 bits/char, bytes = speed/10

1115200 / 10 = 11520 bytes/sec : 1060864 / 11520 =   92 sec
2 57600 / 10 =  5760 bytes/sec : 1050864 /  5760 =  184 sec
3 19200 / 10 =  1920 bytes/sec : 1050864 /  1920 =  556 sec
4  9600 / 10 =   960 bytes/sec : 1050864 /   960 = 1105 sec

There's a bit of extra time to receive packet (RX has to be fully
received (uart empty) before TX response can start, plus read/write
data/OS delays etc.

But as it shows, network is WAY faster - and since DDLINK uses "raw"
packets, you don't need to have a network that works under DOS, the
only other software you need is a "packet driver" (available for LOTs
of cards) - I keep "loose" ISA and PCI network cards that I can just
stuff into a system when I need!

LPT is next up - still a lot faster than serial.

bttr wrote on 2025-03-16, 14:09:

Note: I excluded Alt+F2 (Change Drive), because it would be in conflict with the global 'Run application' shortcut on my Linux Mint system.

I've made a couple enhancements to KEYSUB which may be able to work
around this...

Namely, when run without a .KEY file specification, it shows the status
of KEYSUB - now it also sets ERRORLEVEL :

1  10 = Not Installed
2  11 = Installed/Disabled
3  12 = Installed/Enabled

I also added a -Quiet option, which prevents it from displaying "stuff"
so you could make a .BAT file to run DDLINK with your KEYSUBs enabled,
but disable them otherwise:

1   @echo OFF
2   keysub -q
3   if errorlevel 12 goto ok
4   if errorlevel 11 goto en
5   keysub keys -tq
6   goto ok
7   :en
8   keysub -eq
9   :ok
10   C:\cmds\DDLINK %1 %2 %3 %4 %5
11   keysub -dq

Update available: KEYSUB.ZIP in download area of my site.

Actually, I just looked at doing a "special version" which I could include
for those who really want the "Commander" keys and don't care that it would
make DDLINK bigger...

I could have done this fairly easily with something like:

#define Case(a) //case a :
...
Case(_F5)
case 'C':
...

Then I would just have to remove the "//" from: #define Case(a) case a :

To enable these extra cases .... but I ran into a problem with Alt+F2

My Micro-C text windowing library doesn't support ALT+Fkey
I wrote this library in 1989, and my vague recollection was that
Alt+('A'-'Z') were clearly defined by IBM/MS and commonly used,
but other Alts much less so - as I rarely used Alt, never Alt+
(anything other than 'A'-'Z') I decided to only support Alt+('A'-'Z')

KEYSUB works because
A) I wrote it much laster (within the last year or two)
(and I had 35+ year more experience with BIOS/DOS/PC)

B) It hooks in at a much lower level where it sees "all" keys

C) User interactively create the translation table so I don't have
to make assumptions about what the key will represent.

This means I'd have to redo my text-windowing library, and since this is something that in 35+ years, I've
never had a problem with, or received requests to support ... it's really not something I want do do at this
point!

So.. sorry, it looks like KEYSUB is the best solution for you!

Thanks for your efforts. I was already fine with the KEYSUB solution. 👍

bttr wrote on 2025-03-17, 19:51:

Thanks for your efforts. I was already fine with the KEYSUB solution. 👍

Good to know - I hope the additions I made so you can tell what state its in
to enable/disable it in a batch file helped. (I guess it depends on how "system" the Alt+F2 is
whether or not you can use it in an application - at least you can disable it outside DDLINK now!)

Someday, I might modify KEYSUB to be able to fully unload - but being a TSR I don't want to
make it bigger - it's currently TINY (51 byte of code) - but it basically has to unload itself.
Perhaps I can patch it on the fly to upload... just haven't gotten "a round tuit" yet!

** My wife did get me one a few years back - I guess I was saying "I need to get a round tuit"
too much! (It's on a bar-fridge downstairs, but hasn't helped get things done at all!!)

I'm unable to reproduce your 'off-standard' .zip files. I tried in DOSBox and on a physical machine with PKZIP 2.04g & 2.50 shareware and with PKZIP 2.50 registered.

I used the command 'path_to_pkzip\pkzip -a -ex ..\test.zip' in a directory with some test data. All files in that test data directory just have the archive attribute set, so the 'external file attributes' dword for each .zip file member became 20 00 00 00.

I was able to reproduce your 'off-standard' .zip files using PKZIP 2.50 registered version. Firstly, I ran PUTAV.EXE to enable signing .zip files. Then I ran 'path_to_pkzip\pkzip -! -a -ex ..\test.zip' in a directory with some test data and, voilà, the 'external file attributes' dword became, e.g., 20 D7 82 E5.

So, these strange 'external file attributes' come from signing.

bttr wrote on 2025-03-23, 11:02:

... So, these strange 'external file attributes' come from signing.1

Thanks, I kinda though it might be related - Most "modern" .ZIP managers don't mention if a .ZIP is signed!

I think this is a problem with the affected UNZIP tools - PKWARE basically defined the .ZIP format, and
signing was a "thing" from very early on. Anything that claims to support .ZIP should be able to handle
signed ZIP files!

I don't really want to to NOT sign my files - this has been one of the ways I try to allow users to validate that
the stuff they have is actually from me!

I'll add a note on my download page warning that some UNZIP have this problem!