#93 Status register flags in DEBUG.EXE - Could you provide an option to change the output of the flag registers to a better human readable form?

[Oliver]

I know that DEBUG.EXE tries to be a 100 % replacement with identical behavior and look & feel of DEBUG.EXE from MS-DOS.
But there is one big problem in MS-DOS' DEBUG.EXE, the status register output is not very user friendly, and the same applies to DEBUG.EXE of FreeDOS.

As a user you have to know the meaning of the abbreviations when the status register values change.

In DEBUG.EXE the
Overflow Flag is called OV or NV, depending on the current value of the register.

The same applies to all the other registers:
Direction Flag = DN or UP
Interrupt Flag = EI or DI
Sign Flag = NG or PL
Zero Flag = ZR or NZ
Auxiliary Carry Flag = AC or NA
Parity Flag = PE or PO
Carry Flag = CY or NC

A typical output looks like this (for example after pressing r, t, or p):

AX=0010  BX=00FF  CX=FE2C  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000     DS=0885  ES=0885  SS=0896  CS=0895  IP=0100   NV UP EI PL NZ NA PO NC       0895:0100 8AE7                MOV     AH, BH  

This is not very user friendly and difficult to read. Especially for non English speakers.
If you don't know the abbreviations heart, you have to keep looking up which abbreviation stands for what. And when you work with it, errors creep in just because of the constantly changing names.

Thus could you offer an option in DEBUG.EXE to change the output format in a human readable form?

If you move the output of assembler directive (in this example "MOV AH,BH") a little bit to the left, then there is enough place to put zeros or ones directly under the status flag names and keep the flag names always the same.

That way the output could look like this and would be much more readable.

AX=0010  BX=00FF  CX=FE2C  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000     DS=0885  ES=0885  SS=0896  CS=0895  IP=0100   OF DF IF SF ZF AC PF CF       0895:0100 8AE7             MOV     AH, BH     0  0  1  0  0  0  0  0    

OF DF IF SF ZF AC PF and CF are the abbreviations of the status flag names and after the modification they always stay as they are, and only the value below in the next line changes.

OF = Overflow Flag Register
DF = Direction Flag Register
IF = Interrupt Flag Register
SF = Sign Flag Register
ZF = Zero Flag Register
AC = Auxualiary Carry Flag
PF = Parity Flag
CF = Carry Flag

And when then the CF and ZF changes, it would look like this:

AX=0010  BX=00FF  CX=FE2C  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000     DS=0885  ES=0885  SS=0896  CS=0895  IP=0100   OF DF IF SF ZF AC PF CF       0895:0100 8AE7             MOV     AH, BH     0  0  1  0  1  0  0  1    

Such an output is much easier to read and less error prone.
The 100 % compatibility to MS-DOS DEBUG.EXE could be kept, by providing this output with an option.

You could for example provide a command line parameter, lets call it /f for flags to change the output format of the status register flags from classic output to the new better readable one.

The user could then start DEBUG.EXE with:

debug /f

to have the new better and more readable and less error prone output format of the status register flags.

If this is not possible, because you need the free space in the third line of the output, you could as an alternative also just do it this way:

AX=0010  BX=00FF  CX=FE2C  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000     DS=0885  ES=0885  SS=0896  CS=0895  IP=0100   O0 D0 I1 S0 Z1 A0 P0 C1       0895:0100 8AE7                 MOV     AH, BH  

In this case, the first char is the name of the status flag and the second char is its value which is 0 or 1.
And if the OF, SF and PF flag changes, it would look like this:

AX=0010  BX=00FF  CX=FE2C  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000     DS=0885  ES=0885  SS=0896  CS=0895  IP=0100   O1 D0 I1 S1 Z1 A0 P1 C1       0895:0100 8AE7                 MOV     AH, BH  

And if you want improve that to make it easier to read, you could use a underline char _ instead of a 0 for the value zero. This would be easier to read, because it is easier to notice a change.
In this case, the output cold look like this:

AX=0010  BX=00FF  CX=FE2C  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000     DS=0885  ES=0885  SS=0896  CS=0895  IP=0100   O_ D_ I1 S_ Z1 A_ P_ C1       0895:0100 8AE7                 MOV     AH, BH  

And when the IF and AC flag changes, it would look like this:

AX=0010  BX=00FF  CX=FE2C  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000     DS=0885  ES=0885  SS=0896  CS=0895  IP=0100   O_ D_ I_ S_ Z1 A1 P_ C1       0895:0100 8AE7                 MOV     AH, BH  

What do you think about this suggestion?

[E. C. Masloch]

I still have a suggestion. Would a parent directory that is then set in the environment variable %LDEBUGSCRIPTS% and the subordinate directories then have a fixed name help to keep memory requirement to minimum ?
Suggestion:

No, this would also require more memory.

There was no such file as extension as ELD.ELD.
So i tried:

-ext eld install
EXT command failed to open file.
-ext eld.eld install
EXT command failed to open file.
-install ELD
^ Error

I probably misunderstood you here.
How exactly do I get ldebug to load ELD files without specifying the filename extension?

You seem to have figured this out elsewhere but for the record when I referred to "the extname ELD" I meant the ELD in the file "extname.eld" which you invoke as ext extname.eld install. After that ext foo will search two spots for "foo.eld" then "foo.xld", first the current directory ("foo.eld" then "foo.xld") then the scripts path ("::scripts::foo.eld" then "::scripts::foo.xld").

Just the EXT command itself.

Added to main online help page.

[E. C. Masloch]

(SLD0 format help is not yet defined, can be added soon if you want it however.)

Yes, every extensions, script etc, file should have a short description and a help section. And if possible a more generous usage section with examples.
The help and description section should be mandatory. The usage section should be present, but the content should be optional.
And there should be a way to automatically test whether the corresponding file has all 3 sections for those who write these script or extension files.

I don't have anything in place yet to check things like this to make a description line or help mandatory. And we aren't shipping any Scripts for lDebug as yet.

However, today I implemented SLD0 format help for list.eld and it looks like this:

@;SLD0
@
@;desc = Test Script for lDebug
@
@;helpstart
@;This SLD is a test.
@;
@;Multi-line help content.
@;helpend
@
rv

The description line I already mentioned before. The help starts with a comment (optionally prepended by an @) reading "helpstart" alone on a line. Next, every comment-only line (also optionally prepended by an @ in the first column) is part of the help, until the End Of File or a "helpend" line is encountered.

[Oliver]

At the moment i am in the process of configuring the default script ldebug.sld according to my preferences.
I noticed that ldebug shows the entire script when it starts. Would it be possible to suppress the output of the entire script and only show that the ldebug.sld script was loaded and executed?

Sometimes I still need the rest of the output from DOS that was printed before ldebug started. However, if the entire script is displayed, then the old output is lost due to scrolling.

[E. C. Masloch]

You can hide a command line input being shown by prefixing a single line with an AT sign @ (must be the very first text in a line, no blanks allowed before it), or hide the input of all subsequent lines by setting a YSF flag within the script: https://pushbx.org/ecm/doc/ldebug.htm#varysf

In the sources you can also find a way to quiet the normal (non-error) output of a command while reading from the RC buffer or a Y script file, at https://hg.pushbx.org/ecm/ldebug/file/783981207053/source/debug.asm#l2861

The YSF flag for that is found in https://hg.pushbx.org/ecm/ldebug/file/783981207053/source/debug.mac#l765

[E. C. Masloch]

Would it be possible to suppress the output of the entire script and only show that the ldebug.sld script was loaded and executed?

Like I mentioned you can use the YSF flags or @ prefixes to hide display of a Script for lDebug running. If you want to have an indication of the script running, I recommend including a comment without an @ prefix, like ; Welcome to lDebug! at the start of the :applicationstartup section.

[Oliver]

That's a good idea. Thank you for the tip and answer.

As for your other answers in the other feature requests, I won't be able to answer those until tomorrow. Unfortunately I have a few other things to do today.

[E. C. Masloch]

Today I also added a bunch of commonly used DCO options to the INSTALL command, listed in the updated manual at https://pushbx.org/ecm/doc/ldebug.htm#cmdinstall

[Oliver]

I will test that. Thank you.

Btw, i noticed that your current ldebug.zip development version contains duplicate files:

fdupes * -r -S
fdupes: could not chdir to license.txt  
1 byte each:                            
tmp/debug.rep/cmdline
tmp/debugx.rep/cmdline

195 bytes each:
tmp/debug.rep/usevars
tmp/debugx.rep/usevars

189 bytes each:
tmp/debugc.mac
tmp/debugxc.mac

219272 bytes each:
lst/ldebugc.lst
tmp/sa2/ldebugc.lst

17309 bytes each:
lst/ldebugc.map
tmp/sa2/ldebugc.map

219272 bytes each:
lst/ldebugxc.lst
tmp/sa2/ldebugxc.lst

17310 bytes each:
lst/ldebugxc.map
tmp/sa2/ldebugxc.map

79360 bytes each:
bin/ldebug.com
tmp/sa2/ldebug.com

88064 bytes each:
bin/ldebugx.com
tmp/sa2/ldebugx.com

0 bytes each:
bin/nulfile
lst/nulfile
tmp/nulfile
test/scripts/empty.exe
test/scripts/empty.com
tmp/debug.rep/nasmenv
tmp/scratch
tmp/debugx.rep/nasmenv

You could save a few kilobytes by only having the .com and .lst files once in the ZIP archive.

[Oliver]

Okay, i tested

INSTALL GETINPUT 
INSTALL RHIGHLIGHT

from the available options. That's the one i will use. And they work fine.
So far I've also set flag style 3 in my default ldebug.sld configuration style. Others may follow:

r dco6 or=4000_0000

But i have one more question. Could you update the mentioned manual section above in a way that it says more precisely which options GETINPUT and RHIGHLIGHT do exactly set?

In the other feature request you explained, that the command history can be triggered by using different options:
https://sourceforge.net/p/freedos/feature-requests/110/#3f72

So it would be nice to know, which one GETINPUT uses. The same applies to all the other INSTALL command options. This should be mentioned in my opinion in the manual.

[E. C. Masloch]

I will add this to the manual. The GETINPUT noun uses DCO 800h, while RHIGHLIGHT uses DCO3 04_0000h.

[Oliver]

Thank you.

[Oliver]

You can hide a command line input being shown by prefixing a single line with an AT sign @ (must be the very first text in a line, no blanks allowed before it), or hide the input of all subsequent lines by setting a YSF flag within the script:

About the @ hiding sign i found a small minor bug.
It seems to be, that the first two lines are hidden even when no @ sign is used in front of them.

The following configuration file:

; Startup configuration file "LDEBUG.SLD" loaded
:applicationstartup
@  ; Flag Style 3:
@  r dco6 or= 4000_0000
@  ; Command history;
@  INSTALL GETINPUT
@  ; r dco or= 800
@  ; Syntax Hightlightning:
@  INSTALL RHIGHLIGHT
@:devicestartupr

results in a command line output that looks like this:

C:\TEMP>ldebug hello.exe
-

So there is no

C:\TEMP>ldebug hello.exe
& ; Startup configuration file "LDEBUG.SLD" loaded
&:applicationstartup
-

line before the - prompt as expected.

I have to write my "Startup configuration file" message two times:

@; Startup configuration file "LDEBUG.SLD" loaded
@:applicationstartup
; Startup configuration file "LDEBUG.SLD" loaded
@  ; Flag Style 3:
@  r dco6 or= 4000_0000
@  ; Command history;
@  INSTALL GETINPUT
@  ; r dco or= 800
@  ; Syntax Hightlightning:
@  INSTALL RHIGHLIGHT
@:devicestartupr

To see the message:

C:\TEMP>ldebug hello.exe
&; Startup configuration file "LDEBUG.SLD" loaded
-

Would it also be possible to add a PRINTor ECHO command so that you don't see the semicolon?

@; Startup configuration file "LDEBUG.SLD" loaded
@:applicationstartup
@ echo "Startup configuration file ""LDEBUG.SLD"" loaded"
@  ; Flag Style 3:
@....

Output should be:

C:\TEMP>ldebug hello.exe
& Startup configuration file "LDEBUG.SLD" loaded
-

Or even better without the & if possible:

C:\TEMP>ldebug hello.exe
Startup configuration file "LDEBUG.SLD" loaded
-

And one more questions. Is it possible to print the version information via the script?
So that i get something like this:

@; Startup configuration file "LDEBUG.SLD" loaded
@:applicationstartup
@ echo "Startup configuration file ""LDEBUG.SLD"" loaded. - Version: %Version%"
...

C:\TEMP>ldebug hello.exe
Startup configuration file "LDEBUG.SLD" loaded. - LDEBUG Version: 2023-07-01 
-

[E. C. Masloch]

It seems to be, that the first two lines are hidden even when no @ sign is used in front of them.

The first line in your example is never actually executed. That's because the Y command is y ::config::LDEBUG.SLD :applicationstartup, so the debugger will skip to the goto destination label :applicationstartup (Just as if the first line in the file was @goto :applicationstartup.) You can put anything you want before the label. (You can also "end" a section with goto :eof, say if you want to have different sections for :applicationstartup versus :devicestartup.)

And goto type jumping currently never displays the destination label line, even though it is "executed".

Would it also be possible to add a PRINTor ECHO command so that you don't see the semicolon?

I have considered that but did not yet add it. Likely I would want a printf if anything, to allow to format numbers and the like.

And one more questions. Is it possible to print the version information via the script?
So that i get something like this:

There are no text environment variables in the lDebug scripting language, so no. But you can run @?build which will show a build date, and number of ancestors and source control revision IDs for several components.

[Oliver]

Thank you for your answer.

I have considered that but did not yet add it. Likely I would want a printf if anything, to allow to format numbers and the like.

A printf would be even better.

There are no text environment variables in the lDebug scripting language, so no. But you can run @?build which will show a build date, and number of ancestors and source control revision IDs for several components.

The build date would be good enough, the rest is too much when it comes to output. Could this be extracted somehow by script so that only the date is given?

[E. C. Masloch]

The build date would be good enough, the rest is too much when it comes to output. Could this be extracted somehow by script so that only the date is given?

This is not possible with lDebug scripting. I added a new command ?VERSION that displays only the first line, however.

[Oliver]

That's great. Thank you very much!

[E. C. Masloch]

Would it also be possible to add a PRINTor ECHO command so that you don't see the semicolon?

I added a printf Extension for lDebug, it is included in current release builds. Run it like ext printf.eld "Hello World!\r\n" to display a message. The message can include some printf escapes/format specifiers as well. I will have to get around to documenting all of those some time later.

Your example works with that:

-ext printf.eld "Startup configuration file ""LDEBUG.SLD"" loaded\r\n"
Startup configuration file "LDEBUG.SLD" loaded

Displaying the version is still a challenge, there are the set.eld and variable.eld which allow to set Variables for lDebug (I suggest to use names with the letters "VLD" prepended) in lDebug's DOS environment block as well as expand VLDs in debugger commands. For example:

-ext set.eld run /e vldversion=?build                      
-ext variable.eld run ext printf.eld "Startup config loaded. Version: %vldversion%\r\n"
Startup config loaded. Version: lDebug (2023-11-19)
-

But there is no way yet to operate on the version text (which can include "release 7" or such) without writing your own Extension for lDebug. That is easier than modifying the debugger, but probably not for the faint of heart.

[Oliver]

I added a printf Extension for lDebug, it is included in current release builds. Run it like ext printf.eld "Hello World!\r\n" to display a message. The message can include some printf escapes/format specifiers as well. I will have to get around to documenting all of those some time later.

Thank you that works great. But i noticed an inconsistency:

-ext co.eld help
... ; help text.

Gives me a help and usage information for co.eld.

But when i try this with printf.eld i get:

-ext printf.eld help
PRINTF error: No starting quote mark!

Same with:

-ext LIST.ELD HELP
File not found.

But now i know, what LIST.ELD does, this works:

-ext LIST.ELD LIST.ELD HELP
... ; prints help text about list.eld
-ext LIST.ELD printf.eld help
... ; prints help text about printf.eld

It would be nice, if all extensions would behave the same when a general parameter like help is used.
So this:

-ext LIST.ELD HELP
...; should print help text about list.eld too.

I would also suggest to rename LIST.ELD to INFO.ELD if it is there to show informations about ELD files, like the LIST.ELD's verbose parameter does.

It would also be great. if you could leave out the ELD extension.

-ext SET.ELD HELP
; prints help about set
-ext SET HELP
; prints help about set too. <- This doesn't work at the moment, because no file extension was given with SET.

One more question. Is it correct that ELD files, that must be installed with the INSTALL command do reserve memory, while ELD files, that are not installed with the INSTALL command do not require additional memory. They are just run and then the memory is freed again, correct?

I also tested the SET.ELD extension.

-ext SET.ELD INSTALL
-set
; lists alle environment variables, including environment variables like LDEBUG_DIR or TEMP
-set TEMP
C:\TEMP
-

So this feature works fine, too.

For the variable.eld file i could install it and print its help, but i don't know how to exactly use its features. Is it used in combination with set.eld?

I haven't tested the other ELD files yet.

[Oliver]

One more thing.

An alternative approach to implement a general help would be to bound it to the ext command:

-ext help printf.eld
... ; prints help of printf.eld by reading the help section of printf.eld
-ext help list.eld
... ; prints help of list.eld

That way you could also add information features to ext:

-ext info printf.eld
... ; prints the same what "ext list.eld list.eld verbose" does now.

[E. C. Masloch]

No, this would require at least a residently installed ELD (possible, but I don't see the need) or changes to the debugger itself (absolutely not).

[Oliver]

That's sad to hear. It would have improved usability and consistency. Especially if you also take INSTALL and LIST into account, as suggested in the other thread.
https://sourceforge.net/p/freedos/feature-requests/118/?page=3#05c4/e111/feb5/e17b/3469/808d/345e/592b/806f

But okay, I'll live with it then.

[E. C. Masloch]

Thank you that works great. But i noticed an inconsistency:

-ext co.eld help
... ; help text.

Gives me a help and usage information for co.eld.

But when i try this with printf.eld i get:

-ext printf.eld help
PRINTF error: No starting quote mark!

Yes, this is inconsistent. I might add a help to printf.eld later.

Same with:

-ext LIST.ELD HELP
File not found.

You can use ext list.eld without any parameter, it will display the help.

But now i know, what LIST.ELD does, this works:

-ext LIST.ELD LIST.ELD HELP
... ; prints help text about list.eld
-ext LIST.ELD printf.eld help
... ; prints help text about printf.eld

It would be nice, if all extensions would behave the same when a general parameter like help is used.

I will consider this.

I would also suggest to rename LIST.ELD to INFO.ELD if it is there to show informations about ELD files, like the LIST.ELD's verbose parameter does.

I prefer list.eld, but you can just copy it to info.eld if you prefer.

It would also be great. if you could leave out the ELD extension.

As mentioned elsewhere, ext extname.eld install will achieve this. (For ext list commands with a pathname pattern passed to list.eld, you do still have to include the filename extensions in the pattern however.)

One more question. Is it correct that ELD files, that must be installed with the INSTALL command do reserve memory, while ELD files, that are not installed with the INSTALL command do not require additional memory. They are just run and then the memory is freed again, correct?

This is correct, yes. Some ELDs are oneshot operation only, and thus only take up memory while running. Some ELDs can be installed residently (eg co.eld, extname.eld), and will then take up memory until uninstalled (eg copyoutput uninstall). Some ELDs can operate in either mode (eg set.eld, variable.eld, ldmem.eld). This distinction isn't the 100% truth however, as eg eldcomp.eld and set.eld run /E will install themselves "residently" but only for a brief interval and then uninstall themselves afterwards automatically.

To display the ELD memory blocks in use, run a command like ext ldmem.eld eld. At init time the ELD buffers can be increased using the /X (code space) and /Y (data space) switches to the DOS-mode debugger. They default to 16 KiB each IIRC.

The reason that some ELDs can be installed is because either they want to modify the general operation of the debugger in some way, or I want to be able to use them while the debugger doesn't have DOS available (in InDOS mode), or, equivalently, while the bootloaded debugger doesn't have its FS available (auxiliary buffer is in use eg from RH mode, or don't want to call int 13h). By installing the ELD when possible, it can then be run during the times an ELD cannot be newly loaded.

For the variable.eld file i could install it and print its help, but i don't know how to exactly use its features. Is it used in combination with set.eld?

variable.eld is a bit of an odd one out. It was supposed to be installed residently (using the install parameter) but would then modify every normal debugger command input to replace %variables%. That means if you want to use a percent sign for anything else you should suddenly start to double it to escape it from variable.eld's wrath. (Uninstall with variables uninstall, note the additional S there.) It is now preferred (if you don't need it while InDOS) to run ext variable.eld run <command %variable%> where the run parameter will make the ELD inject the following command to the debugger. Before the injected command actually runs, variable.eld will have unloaded itself from memory again. You can also use the display parameter to just display the result from the variable substitution.

Like mentioned elsewhere, I recommend using variables starting with a "VLD" prefix as Variables for lDebug. You can access the usual DOS variables like %PATH% and %COMSPEC% using the ELDs as well, however. (But only lDebug and its child processes execed after a change will get the modifications, not a debugger parent process like the DOS's shell.)

[Oliver]

You can use ext list.eld without any parameter, it will display the help.

Okay, but it doesn't work the same way with some other elds.

-ext printf.eld
PRINTF error: No starting quote mark!
-ext dm.eld
PSP: 2A2E
028F .... ; memory dump
-ext amitsrs.eld
No TSRs are using the alternate multiplex interrupt
-ext bases.eld
               ^ Error
-ext DI.ELD
             ^Error
-ext doscd.eld
              ^Error
-ext dosdrive.eld
A:
-ext dospwd.eld
A:\
-ext dtadisp.eld
2A2E:0080
-ext DX.ELD
00000000 38 46 ... ; memory dump
-ext eldcomp.eld
0000 0001 0000 0001
0000 0001 0000 0001
-ext instnoth.eld
ELD linker: no other link info found!  ; definitely not the help description
-ext instnoun
01AC 0010 - Faults ; other data
-ext kdisplay
HELLO.EXE
-ext ldmem
Entry segment .... ; Some data
-ext ldmemoth
ELD linker: No other link info found! ....
ext reclaim.eld
; no text message.

The following examples are special, because there it does really make sense to have a very short command to save unnecessary typing but this also shows why it is a good reason to introduce a help parameter for ext ext help name.eld or introduce a @ character to run extensions as suggested before.

Here again, i assumed that i will get a help screen like in the ext list.eld examples above:

-ext rm.eld
; MMX register output
-ext rn.eld
; FPU register output

The following example i mention separately because this can be dangerous and lead to data loss.
As in the ext list.eld examples above, i assumed it will print me a help information first:

-ext quit

Well, this unexpectedly and immediately terminated my VM.
Here the user should at least be asked with a (Y/N) answer and an information text in front of it whether he really wants to turn off the computer.

BTW i now think i know what you meant with the eld ommiting the extension thing. It seems to work, but the parameter listed in the help file seem to have no effect:

-ext extname.eld INSTALL
EXTNAME installed.
-extname on
           ^Error
-EXT extname ON
Install this ELD using .... ; help text
-

Summary:
At the moment the help output for some extensions is very inconsistent. With some you get help if you leave out the help parameter, with others you have to specify it and others only give the help via ext list.eld eldfile help.

It would probably make the most sense, as already suggested, to execute the extensions only by preceding them with an @ sign.

Another thing I noticed is the formatting of the help. The output here also seems to be very inconsistent. Some help uses indentation, others don't.
Here you could use the help output of the DOS programs or a man page like in Unix/Linux as example.

I prefer list.eld, but you can just copy it to info.eld if you prefer.

I agree here now. At first I didn't know that you could use list.eld to list all ELD files. At first I thought this was just to get information about a single ELD file.
This ext list.eld *.?LD definitely belongs in the help of list.eld.

As mentioned elsewhere, ext extname.eld install will achieve this. (For ext list commands with a pathname pattern passed to list.eld, you do still have to include the filename extensions in the pattern however.)

Thanks.

This is correct, yes. Some ELDs are oneshot operation only, and thus only take up memory while running. Some ELDs can be installed residently (eg co.eld, extname.eld), and will then take up memory until uninstalled (eg copyoutput uninstall). Some ELDs can operate in either mode (eg set.eld, variable.eld, ldmem.eld).

Thank you for the clarification.
I would suggest including a date in the ELD file format indicating whether this is an extension that remains resident in memory or does not do so, or allows both.
That would be quite sufficient as an overview.
Especially if you could then display this date using something like an ext list.eld *.?LD command.

To display the ELD memory blocks in use, run a command like ext ldmem.eld eld. At init time the ELD buffers can be increased using the /X (code space) and /Y (data space) switches to the DOS-mode debugger. They default to 16 KiB each IIRC.

That's very helpful and a useful command. Thank you.
Thanks also for your explanation of variable.eld

[E. C. Masloch]

Okay, but it doesn't work the same way with some other elds.

printf.eld now has a help which will show with ext printf.eld (empty command line tail) or ext printf.eld help.

-ext instnoth.eld
ELD linker: no other link info found! ; definitely not the help description

The *oth.eld files require an "oher link" debugger to be resident and have its install amis and ext amisoth.eld installhaving run. I may consider adding a more informative message but the check runs very early during the ELD's linking, not later when the ELD itself is running.

The following example i mention separately because this can be dangerous and lead to data loss.
As in the ext list.eld examples above, i assumed it will print me a help information first:

-ext quit

Well, this unexpectedly and immediately terminated my VM.
Here the user should at least be asked with a (Y/N) answer and an information text in front of it whether he really wants to turn off the computer.

I added an DCO7 option instead. If you install quickrun then an empty ext quit.eld (or an ext quit.eld install followed by empty quit) will act as before, trying to shut down the (virtual) machine. Without the DCO7 enabled, quit.eld will now require the run keyword to actually run its main code.

BTW i now think i know what you meant with the eld ommiting the extension thing. It seems to work, but the parameter listed in the help file seem to have no effect:

-ext extname.eld INSTALL
EXTNAME installed.
-extname on
^Error
-EXT extname ON
Install this ELD using .... ; help text
-

This is what the help says:

~-ext extname.eld
Install this ELD using the INSTALL keyword parameter.

Running EXT or Y command will invoke filename extension guessing.
Run as EXTNAME keyword [ON|OFF|TOGGLE] to configure this ELD,
where keyword is one of WARNEXT, GUESSEXT.
Run as EXTNAME UNINSTALL to uninstall this ELD.

It may not be too clear but you can run extname warnextto view the warn extension status, extname warnext off to switch it off, and extname warnext toggleto toggle or extname warnext on to switch it back on. That's what "where keyword is one of" means here.

This ext list.eld *.?LD definitely belongs in the help of list.eld.

I will consider this. Presumably dosdir.eld should also specify what patterns can be used.

I would suggest including a date in the ELD file format indicating whether this is an extension that remains resident in memory or does not do so, or allows both.
That would be quite sufficient as an overview.
Especially if you could then display this date using something like an ext list.eld *.?LD command.

That shouldn't require much memory so I may add it.