DOS ain't dead - Enhanced DOSKEY 2.5

Wengier

09.10.2014, 16:59

Enhanced DOSKEY 2.5 (Announce)

Paul Houle's Enhanced DOSKEY 2.5 (freeware) has been released about a month ago. For those who do not yet know, one of the most notable added features of Enhanced DOSKEY over the original DOSKEY shipped with DOS/Win9x is command and file auto-completion via the Tab key. Although enhanced, it has a small disk and memory resident footprint, and may be used as a drop-in replacement for the DOSKEY program shipped with DOS/Win9x. It now supports long file names (LFN) as well as short (8.3) names for auto-completion, and also features a CHANGE mode (can be turned on with -C option or with Alt+F9 shortcut) in addition to the APPEND mode. There are also many other new features such as improved macro support; for example, you can now redefine F1-F12 function keys with macros. It has been tested on both single-byte (English, French, etc) DOS/Win9x systems and double-byte (Chinese/Japanese/Korean) DOS/Win9x systems. For more information and downloads (executable & source code) please visit its home page at:

http://paulhoule.com/doskey/

Direct link for the Enhanced DOSKEY 2.5 program:

http://paulhoule.com/doskey/doskey25.zip

Feedbacks are welcome!

RayeR

CZ,
13.10.2014, 10:39

@ Wengier

Enhanced DOSKEY 2.5

Post reply

Hi, I use CMDEDIT.COM 3.21 for several years and I'm satisfied with it. Is there something better on this enhanced doskey?

---
DOS gives me freedom to unlimited HW access.

Wengier

14.10.2014, 16:32

@ RayeR

Enhanced DOSKEY 2.5

Post reply

> Hi, I use CMDEDIT.COM 3.21 for several years and I'm satisfied with it. Is
> there something better on this enhanced doskey?

Hi RayeR! Thanks for your query! As far as I know, CMDEDIT is certainly a nice tool too. Unfortunately, it has not been updated for over 10 years by now -(. The biggest difference between Enhanced DOSKEY and CMDEDIT, as their names suggest, is that Enhanced DOSKEY is an *Enhanced* version of DOSKEY, whereas CMDEDIT is a separate tool with somewhat similar functionality. For example, the function keys (e.g. F7, Alt+F10) and the macro feature of Enhanced DOSKEY are fully backward compatible with DOSKEY shipped with DOS/Win9x and thus may be used as a drop-in replacement for the latter. On the other hand, this is not the case for CMDEDIT. If you are more familiar with the original DOSKEY shipped with DOS/Win9x, then Enhanced DOSKEY is probably your best bet. And plus, unlike CMDEDIT, Enhanced DOSKEY is still in development. If you have some suggestions for some new feature to be added in Enhanced DOSKEY, then just ask for it. You will probably be satisfied when the new version comes out.

RayeR

CZ,
14.10.2014, 20:04

@ Wengier

Enhanced DOSKEY 2.5

Post reply

Thanks for explanation. I never used original doskey for more than a command history so I'm not much demanding user. When I discovered cmdedit I was very happy to have tab command completion that is the main feature I use. A nice feature would be integrated scrollback buffer that use XMS to save low mem.

---
DOS gives me freedom to unlimited HW access.

Wengier

14.10.2014, 23:43

@ RayeR

Enhanced DOSKEY 2.5

Post reply

> Thanks for explanation. I never used original doskey for more than a
> command history so I'm not much demanding user. When I discovered cmdedit I
> was very happy to have tab command completion that is the main feature I
> use. A nice feature would be integrated scrollback buffer that use XMS to
> save low mem.

I see. So the main feature you use is the Tab completion feature. Indeed, both Enhanced DOSKEY and CMDEDIT have this functionality (so I did not mention this as a difference in my previous post). However, while these two pieces of software have some common features for Tab completion, such as LFN support, there are also a few differences in their implementations for the auto-completion feature. Below is a short (and probably incomplete) list of features that I have found out that Enhanced DOSKEY supports (for Tab completion) whereas CMDEDIT does not:

1. Enhanced DOSKEY 2.5 support DBCS (double-byte character set), whereas CMDEDIT does not;

2. If the command entered are CD/MD/RD (or CHDIR/MKDIR/RMDIR), then its arguments that Enhanced DOSKEY's Tab completion will complete are limited to directories (not files). CMDEDIT does not support this feature;

3. Enhanced DOSKEY supports the inclusion and exclusion of system and hidden files for Tab-completion. CMDEDIT does not support this feature (it always exclude system and hidden files);

4. Enhanced DOSKEY supports both APPEND and CHANGE mode for Tab-completion. CMDEDIT supports only one mode for this;

5. Enhanced DOSKEY will complete command or file names into the actual names saved on the disk, but CMDEDIT always changes everything to lower case.

So if you need any of above (and perhaps more) features for Tab completion, it may be a good idea to use Enhanced DOSKEY instead of CMDEDIT. Also thanks a lot for your suggestion!

Rugxulo

Usono,
24.10.2014, 00:30

@ Wengier

Enhanced DOSKEY 2.5

Post reply

> Below is a short (and probably incomplete)
> list of features that I have found out that Enhanced DOSKEY supports
> (for Tab completion) whereas CMDEDIT does not:
>
> 1. Enhanced DOSKEY 2.5 support DBCS (double-byte character set), whereas
> CMDEDIT does not;

Dare I ask the obvious, but are you able to test such things? Most of us apparently cannot. Hence why I'm pretty sure (among other reasons) that FreeDOS does not currently (properly? if at all?) support DBCS languages (which? CJK?).

> 5. Enhanced DOSKEY will complete command or file names into the actual
> names saved on the disk, but CMDEDIT always changes everything to lower
> case.

Again, isn't this related to FUCASE in the kernel (and supporting files)? Does that even work on MS-DOS 7? And does this mean that (LFN) filecase isn't being preserved properly for your preferred language without this feature?

> So if you need any of above (and perhaps more) features for Tab completion,
> it may be a good idea to use Enhanced DOSKEY instead of CMDEDIT. Also
> thanks a lot for your suggestion!

To be honest, I haven't tried this tool. Mostly because I'm not even sure it would work with FreeDOS' FreeCOM. In years back, I always used Toddy (by Wolfware ASM / WASM author) on DR-DOS. When I switched to FreeDOS on a newer machine, it didn't work properly, and I was too lazy (eh?) to recompile FreeCOM with history disabled just to hope it would work okay. 4DOS has its own history, but I very seldomly test there, even if it is installed (and easily available in CONFIG.SYS menu).

You also forgot to mention that this DOSKEY 2.5 assembles (also) with JWasm and is GPL! (But CMDEDIT comes from PC Magazine, which is more or less verboten in licensing.) So I could actually mirror this to iBiblio for FreeDOS, if you want. But I'm not sure of a good subdirectory to put it in. (I don't even remember what Toddy's license is, but it has sources.) And I hate the fact that FreeCOM makes this more difficult to use. Sigh, but there's no maintainer to officially fix it, and I'm just not really qualified.

Okay, sorry if this isn't a super useful message, I just felt like I had to say it anyways. :-P

Wengier

24.10.2014, 01:01

@ Rugxulo

Enhanced DOSKEY 2.5

Post reply

Hi Rugxulo! Thanks for your message! Your message is certainly valuable and I appreciate it.

> > 1. Enhanced DOSKEY 2.5 support DBCS (double-byte character set), whereas
> > CMDEDIT does not;
>
> Dare I ask the obvious, but are you able to test such things? Most of us
> apparently cannot. Hence why I'm pretty sure (among other reasons) that
> FreeDOS does not currently (properly? if at all?) support DBCS languages
> (which? CJK?).

Yes, since I can speak Chinese natively, and also have some basic understanding of the Japanese script (both are DBCS languages). In fact I have put many hours of effort to make Enhanced DOSKEY's DBCS work on actual Chinese/Japanese/Korean (CJK) DOS/Win9x systems. FreeDOS, of course, does not support DBCS natively. However, like MS-DOS, there are third-party DOS tools available in order to display DBCS characters in DOS.

>
> > 5. Enhanced DOSKEY will complete command or file names into the actual
> > names saved on the disk, but CMDEDIT always changes everything to lower
> > case.
>
> Again, isn't this related to FUCASE in the kernel (and supporting files)?
> Does that even work on MS-DOS 7? And does this mean that (LFN) filecase
> isn't being preserved properly for your preferred language without this
> feature?

The LFN feature is, of course, requires the existence of LFN API. Win9x or DOSLFN for example provide such APIs (Int21/AX=71xx). What I meant in my original post is that Enhanced DOSKEY will use the actual names provided by the API (which in turn reflect the actual names saved on the disk) , but CMDEDIT will forcely change everything to lower case without any options to prevent this.

> To be honest, I haven't tried this tool. Mostly because I'm not even sure
> it would work with FreeDOS' FreeCOM. In years back, I always used Toddy (by
> Wolfware ASM / WASM author) on DR-DOS. When I switched to FreeDOS on a
> newer machine, it didn't work properly, and I was too lazy (eh?) to
> recompile FreeCOM with history disabled just to hope it would work okay.
> 4DOS has its own history, but I very seldomly test there, even if it is
> installed (and easily available in CONFIG.SYS menu).

Unfortunately, it indeed will not work with FreeDOS's FreeCOM, since FreeCOM's built-in DOSKEY will take over the job. There is currently no way to turn its built-in DOSKEY off (unless probably making a patch by ourselves). That is why I have not even tried to actually mirror this Enhanced DOSKEY to iBiblio for FreeDOS.

But of course, you are right that Enhanced DOSKEY is GPL, which is a great bonus by itself.

Rugxulo

Usono,
01.11.2014, 22:41

@ Wengier

Enhanced DOSKEY 2.5

Post reply

> > > 1. Enhanced DOSKEY 2.5 support DBCS (double-byte character set),
> > > whereas CMDEDIT does not;
> >
> > Dare I ask the obvious, but are you able to test such things? Most of us
> > apparently cannot. Hence why I'm pretty sure (among other reasons) that
> > FreeDOS does not currently (properly? if at all?) support DBCS languages
> > (which? CJK?).
>
> Yes, since I can speak Chinese natively, and also have some basic
> understanding of the Japanese script (both are DBCS languages). In fact I
> have put many hours of effort to make Enhanced DOSKEY's DBCS work on actual
> Chinese/Japanese/Korean (CJK) DOS/Win9x systems.

I'm fascinated by foreign languages but have no training, certainly not for difficult things like CJK. Still, I'm impressed that you took the initiative to support this.

> FreeDOS, of course, does
> not support DBCS natively. However, like MS-DOS, there are third-party DOS
> tools available in order to display DBCS characters in DOS.

I don't know why FreeDOS doesn't support it. My experience with i18n in DOS is limited, mostly just curiosity in the past few years. FreeDOS surpasses most DOSes in codepages and keyboard layouts, but I guess the kernel developers (7-/8-bitters? heh) traditionally weren't passionate enough to try supporting DBCS. Maybe it was too undocumented and difficult, I have no idea.

> > > 5. Enhanced DOSKEY will complete command or file names into the actual
> > > names saved on the disk, but CMDEDIT always changes everything to
> lower
> > > case.
> >
> > Again, isn't this related to FUCASE in the kernel (and supporting
> files)?
> > Does that even work on MS-DOS 7? And does this mean that (LFN) filecase
> > isn't being preserved properly for your preferred language without this
> > feature?
>
> The LFN feature is, of course, requires the existence of LFN API. Win9x or
> DOSLFN for example provide such APIs (Int21/AX=71xx). What I meant in my
> original post is that Enhanced DOSKEY will use the actual names provided by
> the API (which in turn reflect the actual names saved on the disk) , but
> CMDEDIT will forcely change everything to lower case without any options to
> prevent this.

I was thinking of the (untested by me) FUCASE bug in MS-DOS. But is this downcase (normalization??) just inconvenient or does it actually corrupt the filenames? Because, as you well know, forcing to lowercase isn't a (practical) problem in 7-bit English, even in LFNs. Is this a serious problem with others or just a minor nuisance?

> > To be honest, I haven't tried this tool. Mostly because I'm not even
> > sure it would work with FreeDOS' FreeCOM.
>
> Unfortunately, it indeed will not work with FreeDOS's FreeCOM, since
> FreeCOM's built-in DOSKEY will take over the job. There is currently no way
> to turn its built-in DOSKEY off (unless probably making a patch by
> ourselves). That is why I have not even tried to actually mirror this
> Enhanced DOSKEY to iBiblio for FreeDOS.
>
> But of course, you are right that Enhanced DOSKEY is GPL, which is a great
> bonus by itself.

The built-in version is good enough for light use, just not really strong nor flexible enough for anything heavy. Also, there is no proper maintainer since a long time, so lots of feature requests, bugs, patches aren't integrated at all (not that many exist). I'm not sure I'm really up for improving it myself.

I've (rarely) rebuilt FreeCOM before, but it just felt ultra brittle and annoying. (BTW, the OW port was never finished, so you still need TC, IIRC.) I'm vaguely curious whether disabling the built-in history would allow it (or Toddy) to work at all. Even then, it might just choke due to no DBCS support. I have no idea. Unfortunately, FreeDOS (and worse, semi-noobs like me) just isn't organized enough to do much these days.

You'd almost do better to just modify a different shell (Centroid?), but those are always worse, esp. for .BAT support (which is somewhat important but an entirely separate issue). If I knew how, maybe I'd just rewrite the whole thing from scratch, but it's not necessarily that easy.

Wengier 02.11.2014, 14:00 (edited by Wengier, 02.11.2014, 19:18) @ Rugxulo	Enhanced DOSKEY 2.5 Post reply
	To disable the built-in DOSKEY of FreeCOM, you probably need to disable both FEATURE_HISTORY and FEATURE_FILENAME_COMPLETION before rebuilding it. I have never tried myself so I don't know whether it will actually work either. It is indeed annoying to use the TC1 compiler..

Rugxulo

Usono,
14.02.2015, 05:36

@ Rugxulo

Enhanced DOSKEY 2.5

Post reply

> I'm vaguely curious whether disabling the built-in history would
> allow it (or Toddy) to work at all. Even then, it might just choke
> due to no DBCS support.

I didn't know (or totally forgot) that 0.82pl3 plainedt.zip was a compile (not XMS-Swap, though) with built-in history excluded.

So I temporarily changed my %SHELL% to that. Enhanced Doskey still didn't seem to work, but Toddy does work. So at least that's good.

Just FYI, if anyone else wants to test (or fiddle with things).