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 On Sat, Aug 26, 2023 at 9:31 AM C. Masloch via Freedos-user <freedos-user@lists.sourceforge.net> 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. > > 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 > > > _______________________________________________ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
