[Freedos-user] Announcement: lDebug release 8

2024-03-08 Thread 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

2024-02-16 Thread 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