SvarDOS Core packages for reconsideration

[igully]

I have found a couple of free packages which are worth considering as replacements for current core packages:

---

SvarDOS KEYB is 12 KB in size + 116 KB in 103 keyboard layouts = 128 KB total (3 KB when resident)
mKEYB 0.52.1 is 12 KB in size and contains 27 keyboard layouts = 12 KB total (752 bytes when resident)

Switching to mKEYB will save 116 KB of drive space at no perceivable
functional loss (Unless you want some really esoteric keyboard layout). You
can even edit its name from "mKEYB" to "KEYB" for legacy compatibility
purposes quite easily. And you save precious ram too.

---

SvarDOS FDAPM + idledpms = 9 KB in size
EIDL 1.10 (by ecm) = 4 KB in size

FDAPM is picky with memory managers, causing havoc with Microsoft's EMM386. It
consumes 928 Bytes when resident. Its power status gauge is pretty inaccurate
on many instances, and seems to be the cause of numerous, sometimes
inexplicable system stalls.

EIDL is tiny in size, uses 192 bytes of memory and it is very simple to use.

DEBUG.COM v1.25 is 23 KB in size
MSDebug release 3 by ecm is 10 KB (packed)

SvarDOS MOVE 3.3a - Size 16 KB
MOVE 2.41 - Public domain by unique Software - Size 1.4KB

SvarDOS ATTRIB 2.1 - Size 5 KB
ATTRIB by Dave Dunfield 1995-2003 - Size 3 KB

Find attached all non-SvarDOS alternatives presented here

ATTRIB.ZIP
EIDL_20240731.zip
mKEY.zip
move241.zip
msdebug_20241109.zip

[mateuszviste]

Thanks for the suggestions. Couple of remarks:

1. Dave's ATTRIB is not open-source AFAIK, which makes it a no go for "CORE" usage. Would be nice to include it into the SvarDOS repo of packages, though (would you be willing to package it into an svp?)
2. I did swap EIDL in place of FDAPM at some point, but noticed performance issues, so I reverted back to FDAPM. Ultimately it would be best if the EDR kernel had some embedded power-saving knowledge, as mentioned here...
3. upstream mKEYB is restricted to 286+ - yet the version you attached seems to be XT-compatible. Interesting. May I ask where you found it? I'm not sure if it's a good replacement to FD-KEYB, needs some testing, but at the very least we should include it in packages as an alternative.
4. MOVE -- smaller footprint is nice, but loosing NLS support is not. :-/ But again - good candidate for inclusion into the packages repo.
5. MS-DEBUG - sounds like a good idea. Maybe @ecm-pushbx could confirm there is no obvious reason to avoid MS-DEBUG?

A possibly interesting option could also be to pack some tools with aPACK instead of UPX -- but this requires quite some work to repack, compare and retest each tool to make sure aPACK did not break it.

[igully]

I will get Dave's ATTRIB, MOVE and mKEYB into SVPs.

The story with mKEYB is that I found out the problem was that only UPX worked reliably to pack it as working TSR. mKEYB was very picky about the packer it tolerated. And the author packed it using UPX without the undocumented --8086 switch which made it unviable on anything other than a 286+, so I repacked appropriately and voila, now works on an XT.

Then, the other thing I simply did for legacy compatibility purposes, was to quickly patch the uncompressed binary replacing any "mKEYB" occurrence with " KEYB" which is untidy, as I added a space, but IMHO tolerable anyway. Also reworked the Copyright message which was extending beyond the end of line, looking odd. And finally renamed the executable to "KEYB" before repacking it, so that it could integrate into any DOS environment without any adjustments due to its now matching name.

I agree that power management should ideally be handled by the kernel, but there is certainly a need for an interim solution. FDAPM was only stable on original MS-DOS for me, if I used the BIOS option, all others gave me headaches one way or the other And forget about reliably measuring the battery/AC status. ECM fixed EIDL (well, not fixed, but tamed it, you should try this new version). Older version of EIDL reported several times in the MCB chain, and you could easily make a mess out of it by running it several times concurrently. But not now, now it behaves like a good old dog.

Regarding repacking, in my experience, non-TSR programs are easy to evaluate, and then when it comes to TSR's you enter into a new dimension where the packer can mess the most subtle and imperceivably tiniest things, resulting in an apparent success, when in reality you created a hidden bug waiting to flourish in the most unexpected corner case because the programmer decided to use a very nice, cool and undocumented trick to accomplish a certain goal. TSR's require A LOT of testing before making sure they are ready to be released packed. That said, the concept of repacking as much as possible is certainly desirable, regardless of the hardships involved.

[ecm-pushbx]

5. MS-DEBUG - sounds like a good idea. Maybe @ecm-pushbx could confirm there is no obvious reason to avoid MS-DEBUG?

There's more recent versions of MSDebug at https://pushbx.org/ecm/download/old/msdebug/ Other than that it should be compatible with everything original MS-DOS Debug did, except FAT32 drive sector access and the X (EMS) commands. A comparison to lDebug is in https://pushbx.org/ecm/doc/ldebug.htm#ldebug-ad

Both MSDebug and my version of EIDL should work with any executable packers.

[boeckmann]

Regarding mKeyb, there are different versions available. The original one maintained by Tom Ehlert and a fork here on Github made by Davide Bresolin.

Davides fork is the one used as the default KEYB implementation in recent FreeDOS releases.

Tom Ehlert says that his original mKeyb only runs on 286+. Davide changed this in his port to make it also run on an 8088, apart from other changes trying to auto-detect whether an extended keyboard is present.

I would not change the mKeyb name to KEYB unless a proper fork is done, at least not without the ok from the original authors.

[mateuszviste]

There's more recent versions of MSDebug at https://pushbx.org/ecm/download/old/msdebug/ Other than that it should be compatible with everything original MS-DOS Debug did, except FAT32 drive sector access and the X (EMS) commands. A comparison to lDebug is in https://pushbx.org/ecm/doc/ldebug.htm#ldebug-ad

Sounds cool :) Thanks for the confirmation!
@igully would you be willing to pick up the latest MSDEBUG from ECM's repo and put it into an *.svp?

Tom Ehlert says that his original mKeyb only runs on 286+. Davide changed this in his port to make it also run on an 8088, apart from other changes trying to auto-detect whether an extended keyboard is present.

Perfect. So we simply need to add Davide's fork to the SvarDOS repo as a newer version of Tom's MKEYB (currently the latest available version in the SvarDOS repo is MKEYB 0.41).

I would not change the mKeyb name to KEYB unless a proper fork is done, at least not without the ok from the original authors.

Agreed. No need for any hacking anyway, since Davides' version seems to be usable as-is.

[igully]

@mateuszviste

Could you please verify the repo uploads I made?
attrib-2003.svp was recognized without issues, but all others, despite having an LSM file in the APPINFO directory, seem to fail to be acknowledged (move-2.41.svp + msdebug-20250911.svp + mkey-0.52.1.svp).

Please let me know what the issue is so that I rectify it, or don't make the same mistake again.
Thanks in advance.

[mateuszviste]

ATTRIB: you should really use a different package name (maybe "DDATTRIB"?). As it is now, the ATTRIB you uploaded is considered to be an upgrade over the system (FreeDOS-sourced) ATTRIB, so users will have their attrib replaced by a different implementation and in a different path... will be confusing. The LSM description could maybe also mention that this one comes from Dave Dunfield.

(same with MOVE)

[mateuszviste]

mkey-0.51.svp is missing one letter in the filename (should be "mkeyb-0.51.svp")

[mateuszviste]

MSDEBUG: the LSM should be also named "MSDEBUG", the package filename must be consistent with the LSM filename.

[mateuszviste]

BTW if you scroll down to the bottom of the page at http://svardos.org/?p=repo you will see a review link that shows packages logs. You might want to look into that to see if your packages trigger anything.

[mateuszviste]

I've renamed the mKEYB package to its correct filename and reworked MSDEBUG into a CORE package which replaces the previous DEBUG.

Left to fix: (DD)ATTRIB2003 and MOVE241

[igully]

Thank you for your feedback. I will fix those two packages.

[igully]

Done!

[mateuszviste]

Awesome, thanks! So last item would be for me to look into mkeyb, test it in a few exotic setups, make sure it supports everything that the SvarDOS installer expects and if all good modify the installer so it uses mkeyb instead of keyb. I will find time to tackle all this before the end of the month.

[igully]

Sounds good enough for me. For what it is worth, I have been using mKEYB in all sorts of different DOSes and under plenty of configurations, and has not failed on me for more than a year. This includes quite many eccentric 86Box emulator configurations.