[Freedos-user] Announcement: lDebug release 8

[E. C. Masloch via Freedos-user]

Hello list.

Here's another release of lDebug (with a small L). This application is 
an advanced line-oriented debugger for 86-DOS alike systems. It can be 
loaded instead of a DOS kernel (bootloaded), as a device driver, or as a 
DOS application. The DOS uses may attach or detach from processes using 
the ATTACH and TSR commands respectively, adding the resident debugger 
mode to the normal use as a DOS application. There is a build included 
in the release which supports running as a DPMI client to debug another 
DPMI client.


This is a bugfix and incremental release after last month's release 7 
[1]. A few highlights of what changed:


Release packages do not contain listing files any longer. Some temporary 
files are also deleted after building This saves a lot of space for all 
the build packages except for the SvarDOS binary-only package. One 
reason for dropping the listings is that the debugger main listing as 
well as the Extension for lDebug listings are not particularly useful 
with a non-debuggable build of the debugger, which is the only build 
provided with the release.


If desired, the listing files can be obtained in two ways: Either by 
running (from ldebug/source/) "./make reproduce" and "./makinst.sh" and 
(from ldebug/source/eld/) "./mak.sh", or by downloading yesterday's [2] 
or today's [3] current builds from our server. (Today's current build is 
not yet available but will be created later today before midnight in the 
+0100 timezone.) We have ensured that the map files and listing files 
for these builds are almost exactly the same, excepting the text 
contents of some version strings of the main debugger executable. One of 
the bugfixes in release 8 concerns filling the AMIS description message 
to avoid differing offsets due to a difference in the message length.


Another fix involves running the debugger as a device driver. During 
initialisation of this mode, the debugger can accept command line 
switches. However, specifying a program name to load is invalid for the 
device mode debugger before an ATTACH command ran successfully. When 
such a name is provided on the command line, it will now display an 
error message that reads "Cannot terminate attached while resident." 
instead of crashing the kernel [4].


Another set of bugs fixed involves the drive locking needed to write 
sectors to a drive on MS-DOS v7 and v8. The first bugfix is that the 
correct drive is now unlocked after the write operation, rather than a 
random one. The second bugfix is that the lock and unlock calls are also 
done on MS-DOS v7.00 (from the original MSW 95), which has the locking 
feature (to protect its LFNs) but does not use the new style disk packet 
interface (for FAT32 drives) introduced in MS-DOS v7.10 (corresponding 
to a later MSW 95 revision and MSW 98).


I also attempted to add a way to preserve the current lock state of a 
drive before locking it for writing, but this turned out not to work (at 
least not in pure MS-DOS mode without MSW running). As this failed, the 
debugger will now unconditionally unlock a drive after it wrote a 
sector. (This was the intended mechanism for this, but did not work 
correctly prior to the bugfixes.)


Another change is that the compressed executables now default to support 
depack progress displays. This defaults to a dots display for bootloaded 
mode and no display for device driver and application mode. For the DOS 
modes (that is, not bootloaded mode) setting the environment variable 
%LDEBUGPROGRESS% allows to select a different progress display choice.


The defaults for the progress display can be patched in the inicomp 
(depacker) stage. Newly provided C programs [5] can be used to patch 
both the inicomp progress display choices as well as the query patch 
site in the iniload boot loading stage [6]. Unlike the earlier patch 
Script for lDebug shipped with ldosboot, these programs can be used even 
when arbitrary data is appended to the debugger executables. The 
provided build contains DOS executables compiled from the C sources 
using tkchia's gcc for 8086 DOS targets. However, the C sources can be 
compiled for direct use on other platforms as well.


Another bug that got fixed was likely introduced during the 
reorganisation of the Script for lDebug and Extension for lDebug loaders 
when ELDs were added and refined. In bootloaded mode, a "Y :label" 
command within a Script for lDebug file would not work any longer. This 
command is used to "call" a different part of the same Script for lDebug 
file that is already running.


Finally, the test suite was adapted and verified to run to completion 
correctly for lDebug, lDebugX, lDDebug, lDDebugX, and lCDebugX (all both 
in bootloaded or application mode). The ELD comparison program was also 
run on all registered ELD test install commands [7] and test run 
commands [8]. The testing did turn up the Y bug described in the 
previous paragraph as well as two wrong relocations in the dpb.eld 

[Freedos-user] Announcement: lDebug release 7

[E. C. Masloch via Freedos-user]

Hello list!

Today I prepared release 7 of lDebug (small L). lDebug is an advanced 
debugger for 86-DOS like systems. It is based on Paul Vojta's and 
Japheth's FreeDOS Debug/X, which in turn started out as a clone of 
MS-DOS Debug. Like all of these, it operates with a line-based terminal 
interface. lDebug expands a lot on the capabilities of its ancestors 
however.


Release 7 adds one big feature that's new: The debugger now allocates 
space for and allows loading of Extensions for lDebug (ELDs). Several 
dozen ELDs have been written so far. They're included in the release in 
the bin/ subdirectory (lDebug original packages) or in BIN/ (FreeDOS 
package). The ELD architecture was created to allow optional extensions 
of the debugger without bogging down the build, particularly the code 
segment, with a lot of most likely unused code.


Other than that, some bugfixes have arrived. To summarize from the 
manual's list of news [1]:


 * The DIL command works now, fixing an embarrassing bug in release 6 
for which I provided patches [2].
 * The INSTALL command correctly works with the AREAS keyword followed 
by another keyword.
 * Two bootloaded mode file system read errors were fixed, one when a 
file ends exactly on a cluster boundary and another when a FAT12 entry 
is read which straddles a sector boundary in the FAT.
 * The BOOT PROTOCOL= command with two kernel load files (MS-DOS v6 or 
IBM-DOS load protocol) now allows to freely select the second (DOS) file 
in any subdirectory of the partition to boot from.


A few new features were added (aside from those implemented by 
Extensions for lDebug):


 * An INSTALL TOGGLE command to switch certain features on or off.
 * A fractional digit sometimes displayed for formatted sizes.
 * ::scripts:: and ::config:: keywords can be used in pathnames passed 
to Y, EXT, or BOOT DIR commands in bootloaded mode.
 * The debugger will allocate a 2 KiB environment block for itself (in 
any mode) which is intended for storing Variables for lDebug using the 
set.eld and variable.eld.
 * The application and device init will try to work with a smaller 
initial allocation instead of enforcing a maximum-size ("init max") 
layout early on.


Several new switches are now recognised by the application and device 
mode init. /X resizes the ELD code instance segment from its default 
size, /Y does likewise for the ELD data block area, and /H is the switch 
to do the same to the debugger's history buffer. There is also the 
undocumented /T switch, described some on the blog [3].


Some little-used features of the debugger were actually thrown out. The 
build options _EMS, _RM, and _RN are now disabled by default. They 
correspond to the X commands, as well as the RM and RN command. If 
desired, then apart from creating a build with the options enabled, 
users may instead choose to install the Extensions for lDebug that share 
the sources of the disabled commands. They are named x.eld, rm.eld, and 
rn.eld. They can be used either as transient ELDs (to run a single 
command; requires DOS or bootloaded FS access each time) or installed as 
resident ELDs (needs to access the file only for ELD install).


The packages of this release are found on our server [4]. In the fdpkg 
subdirectory I placed a FreeDOS package, and in the svardpkg a SvarDOS 
binary and sources package each. As usual, all changes are recorded in 
the hg (Mercurial) repository, which can be browsed using our hgweb [5].


As a news blurb for the FreeDOS website (and the sourceforge.net news 
tracker [6]) I would suggest the following:


lDebug release 7

lDebug (small L) is a DOS debugger based on FreeDOS Debug/X. Today's new 
release 7 adds the architecture for Extensions for lDebug, with 52 
different ELDs included in the release package. Further, a number of 
smaller improvements and fixes are included, several of which make 
lDebug better in its bootloaded mode. The application and device mode 
init is less memory-hungry than it would be with its prior "init max" 
approach. Find more details on [the mailing list], and everything lDebug 
at [the lDebug website][7].


Regards,
ecm


[1]: https://pushbx.org/ecm/doc/ldebug.htm#news-r7
[2]: 
https://pushbx.org/ecm/dokuwiki/blog/pushbx/2023/0911_live_patching_the_debugger_itself
[3]: 
https://pushbx.org/ecm/dokuwiki/blog/pushbx/2023/0911_debugger_relocation_all_switches_explained

[4]: https://pushbx.org/ecm/download/ldebug/
[5]: https://hg.pushbx.org/ecm/ldebug/log/release7
[6]: https://sourceforge.net/p/freedos/news/
[7]: https://pushbx.org/ecm/web/#projects-ldebug


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Announcement: lDebug release 6

[C. Masloch via Freedos-user]

On at 2023-09-03 20:31 +0200, C. Masloch via Freedos-user wrote:

On at 2023-08-26 16:30 +0200, C. Masloch via Freedos-user wrote:

Hello list,

I finished release 6 of lDebug (with a small L) today. This is my 
advanced 86-DOS debugger project based on FreeDOS Debug/X (in turn 
based on MS-DOS Debug), with some ideas from DR-DOS Debug. The 
duration since the prior release 5 is back to less than 6 months as 
opposed to the year between releases 4 and 5. Apart from the usual 
amount of bugfixes, there are some new features.


I just found a bug in the release 6 revision of lDebug. It makes the DIL 
command (Dump Interrupt chains with discovery of hidden chains through 
AMIS Interrupt Lists) not work properly. Depending on the prior use of 
(and left-over contents in) the auxiliary buffer, it could either seem 
to appear to work, it could display an error immediately on any hidden 
chain being detected (very common), or it could overflow the auxiliary 
buffer (only possible if hundreds and hundreds of interrupt entrypoints 
are found for one particular interrupt number).


It is unfortunate that this bug slipped by me into the release. I am 
considering whether to make a "minor" release about it. As a halfway 
remedy for now, I created a Script for lDebug that can patch an 
uncompressed executable (ldebugu.com, ldebugxu.com, lcdebugu.com, etc) 
to work around the bug. I have tested this patch on several different 
files. It is described some on my blog [1]. A copy of the patch itself 
is also hosted on our server [2]. The files that can be patched in the 
FreeDOS package are found in the package's directory tree at these 
positions:


Today I figured I could make an online patch in which the debugger that 
needs to be patched can, itself, run a Script for lDebug file to patch 
its own code. The patch result is the same as for the offline patch, 
however the online method works on any executable, including the 
compressed executables.


With the insight into the exact location of the code section (read from 
the read-only variables DCODE1SEG and DCODE1LEN), the online patch is 
even more reliable than the offline one. However, the detection of the 
correct offset used by the instructions to replace is a bit different 
as, at script run time, the init section is no longer accessible. 
Because the online debugger is already loaded, the patch can also patch 
in the exact allowable size of the auxiliary buffer (calculated as 
DAUXBUFLEN - #24 if this variable is available), as at this point this 
size cannot change after the control flow has left init behind. (The /A 
switch to init can be used to enlarge the buffer, which is also the 
cause of this bug to begin with.)


As an addition, this script will end in one of five different paths: 
Success, patch not needed (source patch already applied), patch not 
needed (binary patch is already applied or auxiliary buffer size is 
hardcoded as before introduction of the /A switch), attempt to run the 
script in Protected Mode (which is not supported), and other error.


Here is the full script:

=== snip patchl6.sld
if (dif & 800) then goto :nopm
;   205  <1> protectedmode	equ	 800h	; in 
(DPMI) protected mode

s dcode1seg:0 l dcode1len 88 65 04 80 65 05 FD 89 4D 06
;  2491 1C74 886504  <1> 	mov byte [di + 4], ah		; store 
the multiplex number
;  2492 1C77 806505FD<1> 	clropt [di + 4], 200h		; 
indicate it is claimed
;  2493 1C7B 894D06  <1> 	mov word [di + 6], cx		; = how 
many list entries before ours,

;  2494  <1>  ;  or 
= -1 if not from a list
;  2495 1C7E E9B900  <1>  jmp .done
;  2496  <1>
;  2497  <1> @@:
;  2498  <1> 		; ds:di -> second terminator 
(will be overwritten)

;  2499  <1> %if _AUXBUFFSIZE == _AUXBUFFMAXSIZE
;  2500  <1> 	cmp di, _AUXBUFFSIZE - 8 * 3	; 
enough for 1 entry + 2 terminators ?

;  2501  <1> %else
;  2502 1C81 3B3E[540A]  <1> 	cmp di, word 
[auxbuff_current_size_minus_24]

;  2503  <1> %endif
if (src != 1) then goto :error
r v0 := 2
if (byte [srs:sro + count] == EB) then goto :short
r v0 += 1
if (byte [srs:sro + count] != E9) then goto :error
:short
if (byte [srs:sro + count + v0] == 36) then goto :notneedednew
if (word [srs:sro + count + v0] == FF81) then goto :notneededold
if (word [srs:sro + count + v0] != 3E3B) then goto :error
r word [srs:sro + count + v0 + 2] .
s dcode1seg:0 l dcode1len range srs:sro + count + v0 l 4
if (src != 3) then goto :error
r v1 := 8 * #1024 + #16 - #24
if exists r dauxbuflen then r v1 := dauxbuflen - #24
a srs:sro0
 cmp di, (v1)
 .
a srs:

Re: [Freedos-user] Announcement: lDebug release 6

[C. Masloch via Freedos-user]

On at 2023-08-26 16:30 +0200, C. Masloch via Freedos-user wrote:

Hello list,

I finished release 6 of lDebug (with a small L) today. This is my 
advanced 86-DOS debugger project based on FreeDOS Debug/X (in turn based 
on MS-DOS Debug), with some ideas from DR-DOS Debug. The duration since 
the prior release 5 is back to less than 6 months as opposed to the year 
between releases 4 and 5. Apart from the usual amount of bugfixes, there 
are some new features.


I just found a bug in the release 6 revision of lDebug. It makes the DIL 
command (Dump Interrupt chains with discovery of hidden chains through 
AMIS Interrupt Lists) not work properly. Depending on the prior use of 
(and left-over contents in) the auxiliary buffer, it could either seem 
to appear to work, it could display an error immediately on any hidden 
chain being detected (very common), or it could overflow the auxiliary 
buffer (only possible if hundreds and hundreds of interrupt entrypoints 
are found for one particular interrupt number).


It is unfortunate that this bug slipped by me into the release. I am 
considering whether to make a "minor" release about it. As a halfway 
remedy for now, I created a Script for lDebug that can patch an 
uncompressed executable (ldebugu.com, ldebugxu.com, lcdebugu.com, etc) 
to work around the bug. I have tested this patch on several different 
files. It is described some on my blog [1]. A copy of the patch itself 
is also hosted on our server [2]. The files that can be patched in the 
FreeDOS package are found in the package's directory tree at these 
positions:


SOURCE/LDEBUG/ldebug/bin/ldebugu.com

SOURCE/LDEBUG/ldebug/bin/ldebugxu.com

This is the complete script file:

=== snip patch6.sld
install flat
l
r v1 := bxcx >> 4
r v2 := 0
r v3 := bxcx
if (v1 <= 1000) then goto :small
r v2 := v1 - 1000
r v3 := 1
:small
s cs+10+v2:0 l v3 B1 04 89 C3 D3 EB
if (src != 1) then goto :error
u srs:sro - 4 l 1
if (auo != sro) then goto :error
r v0 := word [srs:sro - 2]
s cs+10+400:0 l 1 3B 3E byte v0 byte (v0 >> 8)
if (src != 3) then goto :error
a srs:sro0
 cmp di, (8 * #1024 + #16 - #24)
 .
a srs:sro1
 cmp di, (8 * #1024 + #16 - #24)
 .
a srs:sro2
 cmp di, (8 * #1024 + #16 - #24)
 .
w
goto :eof

:error
; Error detected
=== snip

This is how to use it:

* Run DOS command "ldebug ldebugu.com"
* Run lDebug command "y patch6.sld"
* Observe whether last line indicates "Error detected"

Regards,
ecm


[1]: 
https://pushbx.org/ecm/dokuwiki/blog/pushbx/2023/0903_august/september_work#the_dil_bugfix

[2]: https://pushbx.org/ecm/test/20230902/patch6.sld


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Announcement: lDebug release 6

[C. Masloch via Freedos-user]

Hi Jerome,

On at 2023-08-28 17:20 -0400, Jerome Shidel via Freedos-user wrote:
 For the most part, that section 
on ibiblio is fully automated and basically just requires me to drop a 
new version of a package into the appropriate upload directories. The 
management software takes care of the rest. It performs some version 
control, creates static web pages, adjusts file system links and etc.


For example, the file you referred to in [5] is just a link to the 
latest file in the ldebug sub-directory. As it turns out, if you were to 
have visited the html for the repository at [R2], it showed the latest 
version as release_5.zip. It also showed an older/alternate version for 
release 4 as simply ldebug.zip.


This was probably caused be me being lazy and just dropping the updated 
version directly into the unstable repository (at present, the latest 
repo is just a link to the unstable repo). Generally, the management 
software will catch this and adjust the links. But, not always when a 
full verification of the repo is not performed.


This was easy to fix. I just deleted the link [5] to the latest file and 
told the repo to update. It adjusted it to the latest file and updated 
the html file to the appropriate file names.



[..]


After correcting the issue with [5], I updated the package on the GitLab 
FreeDOS Archive [R3]. That way Release 6 will be in the next FreeDOS 
interim Build. Then, I uploaded copies to the repos (1.3 and Unstable) 
on ibiblio.


I think all looks good now. If you notice any other issues, please let 
me know.


[1], [4], and [5] are fine now. [R2] is fine too. [2] still seemed to 
refer to release 5. Turns out I had to reload the page in my browser 
explicitly (Firefox on a Debian desktop box), not just open it in a new 
tab, to get it to update. Probably nothing to do with the server though, 
so no fault with you.

Thanks,

Jerome


Thank you!

Regards,
ecm


[1]: 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/devel/ 
[2]: 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/pkg-html/ldebug.html 

[3]: http://freedos.org/source/ 
[4]: 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/devel/ 
[5]: 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/devel/ 
[6]: https://pushbx.org/ecm/doc/ldebug.htm#parlist 

[7]: https://pushbx.org/ecm/doc/ldebug.htm#news-r6 

[8]: https://pushbx.org/ecm/download/ldebug/ 

[9]: https://pushbx.org/ecm/web/#projects-ldebug 





[R1]: http://ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/ 

[R2]: 
http://ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/pkg-html/ldebug.html 
[R3]: https://gitlab.com/FreeDOS/devel/ldebug 





___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Announcement: lDebug release 6

[C. Masloch via Freedos-user]

On at 2023-08-28 16:15 -0500, Jim Hall via Freedos-user wrote:

Hi Jim,

I noticed that the file on ibiblio isn't updated yet [1]. Likewise the
FreeDOS Software page [2] linked from the website [3]. Though both of
these list 1.3 in their pathnames, so I'm not sure what the appropriate
action would be. However, I do think that the website [3] should link to
the most recent files.

Browsing ibiblio I found that the freedos/files/repositories/latest/
tree is even more outdated [4]. The ldebug/ subdirectory does have
release 5, but the ldebug.zip file (in the latest/devel/ directory) says
it is from 2022-04-04. The unstable tree has the same old files [5].



Jerome usually updates the installer repo with new packages, so I'm
leaving that to him.

However, the zip file is mirrored on ibiblio, here:
https://ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/debug/ldebug/rel6/


Allright, thanks.


Finally, here's your news item quoted:



lDebug release 6
2023-08-26 9:27am

lDebug (that's with a small L) is a 86-DOS debugger that
replaces the classic DOS Debug program. The latest version
(release 6) is available today! The new version includes
several cool new features and fixes bugs. Some features
were suggested on the FreeDOS feature request tracker,
and include "style 2" and "style 3" alternative symbolic
flag displays.


Fine so far.


You can display lists with leading keywords.


This is wrong, there is no change to any data displays with the leading
AS WORDS or AS DWORDS keywords. Rather, they can be specified on the
*input* that a user gives in a list parameter [6]. This modifies how the

[..]

Well, I did my best trying to write a news item based on your 680-word
announcement, with 18 footnotes. It's not always easy to get it right.
:-)


Yeah, I understand the need for brevity. And it wasn't all bad, just the 
two bits.



Can you send me an announcement (in about 100 words) that I can
copy/paste into the news system?


Sure, I based it on yours with a few improvements:

lDebug (that's with a small L) is a 86-DOS debugger that replaces the 
classic DOS Debug program. The latest version (release 6) is available 
today! The new version includes several cool new features and fixes 
bugs. Some features were suggested on the FreeDOS feature request 
tracker, including "style 2" and "style 3" alternative symbolic flag 
displays. Lists can be specified as words or dwords. The DT "dump text 
table" command can translate numbers to text. lDebug can read a config 
file on startup. More details are found [in the mailing list 
announcement] [1]. Get it from [the lDebug website] [2].


[1]: link to 
https://sourceforge.net/p/freedos/mailman/freedos-user/thread/9b70d387-bac2-d223-00d0-d78628bde1dd%40ulukai.org/

[2]: link to https://pushbx.org/ecm/web/#projects-ldebug


Regards,
ecm


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

Re: [Freedos-user] Announcement: lDebug release 6

[C. Masloch via Freedos-user]

On at 2023-08-26 11:30 -0500 , Jim Hall via Freedos-user wrote:

Great news, thanks! I've been following the feature request discussion
on the tracker, so it's great to see the new version with the cool new
changes.

There's a lot in this announcement (because so many new features) so I
wasn't able to reproduce all of that in the news item for the website,
but I did my best. :-)


Jim


Hi Jim,

I noticed that the file on ibiblio isn't updated yet [1]. Likewise the 
FreeDOS Software page [2] linked from the website [3]. Though both of 
these list 1.3 in their pathnames, so I'm not sure what the appropriate 
action would be. However, I do think that the website [3] should link to 
the most recent files.


Browsing ibiblio I found that the freedos/files/repositories/latest/ 
tree is even more outdated [4]. The ldebug/ subdirectory does have 
release 5, but the ldebug.zip file (in the latest/devel/ directory) says 
it is from 2022-04-04. The unstable tree has the same old files [5].


Finally, here's your news item quoted:



lDebug release 6
2023-08-26 9:27am

lDebug (that's with a small L) is a 86-DOS debugger that replaces the classic DOS Debug program. 
The latest version (release 6) is available today! The new version includes several cool new 
features and fixes bugs. Some features were suggested on the FreeDOS feature request tracker, and 
include "style 2" and "style 3" alternative symbolic flag displays.


Fine so far.


You can display lists with leading keywords.


This is wrong, there is no change to any data displays with the leading 
AS WORDS or AS DWORDS keywords. Rather, they can be specified on the 
*input* that a user gives in a list parameter [6]. This modifies how the 
input is parsed into a data string for the E, F, and S commands. For 
example, "f 100 l 100 26" will fill the specified memory range with the 
*byte* value 26h, as in 26 26 26 ... Using "f 100 l 100 as words 26", 
the range is instead filled with the *word* value 26h, that is the byte 
pattern 26 00 26 00 26 00 ... (The value would be truncated at the end 
if it wouldn't fully fit, just like all F patterns.)



The DT "dump table" command can generate different table data.


This is a bit vague. I did intentionally refer to it as "dump text 
table" though. Even "dump text" would be more accurate than only "dump 
table", to refer to what it does, especially the form with a numeric 
parameter.



lDebug can read a config file on startup. See the manual [7] for full details 
about the new release. Get it from the lDebug website [8].


I do notice I didn't link the canonical web presence of the project [9] 
in my announcement. Anyway, I would suggest linking either that or the 
announcement mail itself. The latter especially because of the more 
complete new features overview, without getting bogged down by the much 
more detailed news-r6 section. (Of course, the repo history is even more 
detailed.)


Regards,
ecm


[1]: 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/devel/
[2]: 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/1.3/pkg-html/ldebug.html

[3]: http://freedos.org/source/
[4]: 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/latest/devel/
[5]: 
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/repositories/unstable/devel/

[6]: https://pushbx.org/ecm/doc/ldebug.htm#parlist
[7]: https://pushbx.org/ecm/doc/ldebug.htm#news-r6
[8]: https://pushbx.org/ecm/download/ldebug/
[9]: https://pushbx.org/ecm/web/#projects-ldebug


___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user

[Freedos-user] Announcement: lDebug release 6

[C. Masloch via Freedos-user]

Hello list,

I finished release 6 of lDebug (with a small L) today. This is my 
advanced 86-DOS debugger project based on FreeDOS Debug/X (in turn based 
on MS-DOS Debug), with some ideas from DR-DOS Debug. The duration since 
the prior release 5 is back to less than 6 months as opposed to the year 
between releases 4 and 5. Apart from the usual amount of bugfixes, there 
are some new features.


If the debugger is not bootloaded (that is, loaded as a DOS application 
or DOS device driver) then some of the boot-specific code and messages 
is discarded, saving some resident memory. The ATTACH command [1] does 
the opposite of the TSR command, allowing a device-mode debugger to 
attach to a process. The K command is a synonym to N usually, to stay 
compatible to my MSDebug build [2]. .HEX files can be read now.


Some features were suggested on the sourceforge.net FreeDOS feature 
tracker. These include style 2 and style 3 alternative symbolic flag 
displays [3]. The E, F, and S commands allow specifying lists with 
leading keywords like "AS WORDS" or "AS DWORDS" [4] [5]. The DT (dump 
text table) command [6] allows to generate an ASCII table [7], a table 
of the top half of the 8-bit space, or to dump the bytes of a specified 
number as text [8]. The H command displays the remainder if the 
outermost operator is a division [9].


Another feature suggested there [3] is the debugger will attempt to read 
a configuration file on startup now, either from the directory specified 
in the %LDEBUGCONFIG% variable, or else the same directory as the lDebug 
executable. This is described a bit in the manual section on "Invoking 
the debugger as an application" [10]. Further, when a Script for lDebug 
(.SLD) file is not found it is searched for in the directory specified 
by the %LDEBUGSCRIPTS% variable [12], or also the debugger executable 
directory.


The INSTALL and UNINSTALL commands were extended with many new nouns for 
reconfiguring the debugger [11] without having to look up cryptic 
numbers to set or clear in the Debugger Common Options (DCO) variables.


There is a new mode called RH mode [12], which allows the RH command 
[13] to replay any of the last several dozen register dumps from the 
debugger's auxiliary buffer. While on the topic of the auxiliary buffer, 
the application mode and device driver mode init of the debugger gained 
the ability to grow this buffer to up to 24 KiB, beyond its minimum size 
of just above 8 KiB. This is done by passing an /A switch to the 
debugger's init [10]. Because it is done in the init, this costs very 
little amounts of resident space.


Another two features are done in the debugger init, costing no space in 
the resident debugger. The first is the /P switch (or component /PE and 
/PS switches) to guess a filename extension and do a path search for the 
specified file. The second is a warning for an unknown filename 
extension, which can be disabled with a /PW- switch.


Finally, the default build of the debugger gained the run time option to 
install interrupt 0Dh and interrupt 0Ch handlers in Real/Virtual 86 
Mode, using an INSTALL INTFAULTS command [11]. Most physical machines in 
Real 86 Mode, and the most recent dosemu2 VMM in Virtual 86 Mode, will 
dispatch faults in 86 Mode to these handlers. However, the same handlers 
are usually invoked for two different IRQs. The debugger's handlers will 
query the Programmable Interrupt Controller (PIC) to find out whether a 
corresponding IRQ is being serviced; if it is then the debugger will 
pass along the call to the downlink of its handler. Otherwise, it is 
treated as a fault.


The release packages are available from our server [14] as usual. The 
fdpkg subdirectory [15] has a FreeDOS package that I prepared. The 
svardpkg subdirectory [16] has executable and source SvarDOS packages. 
The repo history up to the release can be read in our hgweb [17]. The 
News chapter of the manual has a section on release 6 [18].


Regards,
ecm


[1]: https://pushbx.org/ecm/doc/ldebug.htm#cmdattach
[2]: https://pushbx.org/ecm/doc/msdebug.htm#cmdn
[3]: https://sourceforge.net/p/freedos/feature-requests/93/
[4]: https://sourceforge.net/p/freedos/feature-requests/102/
[5]: https://pushbx.org/ecm/doc/ldebug.htm#parlist
[6]: https://pushbx.org/ecm/doc/ldebug.htm#cmddt
[7]: https://sourceforge.net/p/freedos/feature-requests/105/
[8]: https://sourceforge.net/p/freedos/feature-requests/99/
[9]: https://sourceforge.net/p/freedos/feature-requests/100/
[10]: https://pushbx.org/ecm/doc/ldebug.htm#invoking-app
[11]: https://pushbx.org/ecm/doc/ldebug.htm#cmdinstall
[12]: https://sourceforge.net/p/freedos/feature-requests/118/
[13]: https://pushbx.org/ecm/doc/ldebug.htm#cmdrh
[14]: https://pushbx.org/ecm/download/ldebug/
[15]: https://pushbx.org/ecm/download/ldebug/fdpkg/
[16]: https://pushbx.org/ecm/download/ldebug/svardpkg/
[17]: https://hg.pushbx.org/ecm/ldebug/log/release6
[18]: https://pushbx.org/ecm/doc/ldebug.htm#news-r6

Re: [Freedos-user] Can FreeDOS Be Installed By Means Of UNIX Commands?

[C. Masloch via Freedos-user]

Hi,

On at 2023-07-16 09:21 -0500, Jay F. Shachter via Freedos-user wrote:


Esteemed Colleagues:

I have a computer, with an MBR-partitioned disk, that is configured to
perform Legacy boot.  Microsoft Windows is installed on three primary
partitions, because that is what Windows does, and every other
operating system on this computer must find a home for itself within
the logical partitions carved out of the fourth, extended partition.

I want to install FreeDOS on a logical partition.  So my first
question is: Does FreeDOS even support this?  Many operating systems
do not, and only support installation on primary partitions, and on
GPT-partitioned disks.


The FreeDOS kernel expects its FDCONFIG.SYS ("altconfig", the preferred 
alternative) or CONFIG.SYS ("oldconfig", the old fallback) on whatever 
file system it detects as the C: drive. Technically, this is the *only* 
file you need on what is detected as drive C:, as you can use lines like 
"device=f:\..." and "shell=f:\command.com /p:f:\fdauto.bat" to make use 
of a different drive for other things. (Some DOS programs may expect to 
use drive C: regardless, so watch out.)


(Using the kernel command line extension I added [1] to the kernel in 
2022, you can specify different CONFIG/ALTCONFIG/OLDCONFIG pathnames to 
try a file on a different drive than drive C:, but the only ways to pass 
a kernel command line are currently to boot into my debugger (lDebug 
[2], with a small L) and use it to load the kernel; or to pack the 
kernel executable into my iniload + fdkernpl stages then boot it as 
Multiboot1 or Multiboot2 specification kernel from GRUB which allows to 
pass along a command line as well. I can give more detailed instructions 
on those if you want.)


The kernel will detect drive C: based on which partitions are primary 
and logical. If you have only a single HDD, then probably the first 
visible primary FAT FS partition gets to be drive C: (regardless the 
actual placement on the hard disk; only the position in the partition 
tables should matter).


The kernel is loaded in its entirety by the boot sector loader, or 
whatever is fulfilling its role. That means the kernel itself doesn't 
need to know what drive/partition it was loaded from. Technically, the 
loader will pass along the boot sector with a BPB/EBPB of what partition 
it loaded from, but the kernel does not (yet) make any use of it. (Not 
true if you replace the FreeDOS kernel file by my debugger executable, 
lDebug does make use of this info.) This includes that it does not use 
it for the determination of what drive gets to be drive C:.


As for the boot sector loader, FreeDOS's originals should be able to 
load from a logical partition if you correctly set up the hidden sectors 
field (should give LBA sector number of the boot sector itself in the 
total disk unit, not uninitialised and not counting within the extended 
partition) and possibly the two CHS geometry fields (if the sector will 
use CHS access to load the kernel). All you need to do then is to 
instruct your prior loader to chainload the boot sector loader, either 
from a dump file or from the actual boot sector of the logical partition.


(In my ldosboot repo [3] I provide alternative loaders which can with 
some degree of success auto-detect the hidden sectors and CHS geometry. 
However, not all of these features are available in combination with the 
FreeDOS load protocol because of how much code it requires. But you 
could instead use the lDOS boot loaders to load lDebug, then use lDebug 
to load the FreeDOS kernel.)


To install the proper superblock values into a boot sector dump file, or 
inversely install the proper boot loader into the actual sector while 
leaving intact the superblock values (called the BPB or EBPB), you can 
use a DOS tool like my instsect (a build is included in lDebug packages) 
or the kernel's SYS utility (comes with kernel builds). SYS will 
obviously default to install the loader corresponding to its kernel; 
instsect has default loaders built-in but you can specify a file to read 
the loader from instead. (Do not try lDebug's instsect's default 
built-in loader with the unmodified FreeDOS kernel -- it will fail to 
load it, even if you change the filenames to match. This is because 
these loaders load using the lDOS load protocol rather than the FreeDOS 
one.)


SYS can write the resulting sector to a drive or to a dump file, 
likewise instsect. What I think is a feature unique to instsect is to 
operate on a partition image that appears to DOS as a file, rather than 
a drive, both for reading the superblock values as well as installing 
the resulting sector. However, both programs are DOS programs, so you 
need some sort of DOS running on the system or with access to the drive 
(image) that you want to install to.


The core feature of SYS and instsect is not super difficult to replicate 
using dd. You just need to copy over the (E)BPB of the superblock to 
combine it with the