Re: [Freedos-user] A few suggestions to improve debug
On Wed, Sep 2, 2020 at 5:47 AM tom ehlert wrote: > > UNIX System V certainly was connected to serial terminals (Televideo, > VT100, ...) > > and it had the VI visual editor with definitively cursor movement > across the screen, even when the terminal had no cursor keys. I was a system administrator for setups like that. (At one shop, I had 90 dumb terminals connecting to a SysV, and later a Solaris, machine.) The vi editor relied on the TERM variable being properly set in the login profile. (And vi is a "moded" editor. In Insert mode, things you type are inserted into the file you are editing. In command mode, keys on the keyboard become commands. H, J, K, and L move the cursor left, down, up, and right respectively. So you can use vi on machines that don't have arrow keys.) Unix used a database called termcap (short for terminal capabilities) to tell how to communicate with the terminal. The $TERM variable got set to an entry in the local termcap file. An ANSI termcap entry looked like this. It was provided with a DOS port of the Unix Larn D style game (and required the ANSI.SYS driver to be loaded.) \E is the escape character (ASCII 27). A command sequences begin with escape left bracket # # Monochrome IBMPC. #This is a termcap for the NANSI.SYS device driver. #It is the same as the ANSI termcap, except NANSI supports #line insert (al) and delete (dl) while ANSI does not. # ibmpc-mono:\ Name of termcap entry :co#80:\ Number of screen columns :li#24:\ Number of screen rows :ho=\E[H:\Home the cursor :cl=\E[;H\E[2J:\Clear line :bs:\Terminal has backspace key :cm=\E[%i%2;%2H:\Cursor motion :up=\E[A:\ Up arrow :xd=\E[B:\ Down arrow :nd=\E[C:\ Right arrow (non-destructive space) :bc=\E[D:\ Left arrow :ce=\E[K:\ Clear entry :cd=\E[J:\Clear display :ti=\E[m:\Terminal mode init :te=\E[m:\ Terminal mode end init :so=\E[1m:\ Standout mode (usually boldface) :se=\E[m:\ End standout :us=\E[4m:\ Underline mode :ue=\E[m:\ End underline :al=\E[L:\ Add line :dl=\E[M: Delete line This is a simple example. More complex ones existed. But there were limits in how complex - terminal definitions had to fit into a 1K buffer in memory. Terminals fell into two broad categories - ASCII and ANSI. Earlier terminals were ASCII terminals, and the typical example was the DEC VT52 or the Wyse 50. The VT100 was the typical ANSI terminal. The principal difference was ANSI terminals using ANSI escape sequences for terminal commands, which were a subset of the ANSI 3.64 specification. The latter made life easier for admins. The Wyse 50 ASCII terminal, for example, had a backspace key and a left arrow key. *Both* sent ^H when sent, with no way to determine which of those keys was pressed when the system got a ^H from the terminal. > cursor movement is not tied to memory-mapped devices, and even old DOS > Software (MS Word and friends) were derivative of CP/M software where > they also have to live with serial terminals. they (for the most part) > used only BIOS functions for screen control. And CP/M had a configurable BIOS you could customize to best support your hardware, because there was wide variation in what vendors offered. Likewise, early PC clones took a bit to get IBM PC BIOS emulation correct. Earlier versions of the VDE editor mentioned here could be configured to use the BIOS for cursor movement if the particular brand of machine wasn't fully PC compatible and didn't support the expected control sequences. Using BIOS calls was slower and more expensive than direct addressing, so all breathed sighs of relief when it stopped being needed. __ Dennis ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
On 9/2/2020 2:29 AM, tom ehlert wrote: UNIX System V certainly was connected to serial terminals (Televideo, VT100, ...) and it had the VI visual editor with definitively cursor movement across the screen, even when the terminal had no cursor keys. cursor movement is not tied to memory-mapped devices, and even old DOS Software (MS Word and friends) were derivative of CP/M software where they also have to live with serial terminals. they (for the most part) used only BIOS funtions for screen control. only much later direct memory control became en vogue. Well, yes, serial terminals had (depending on the model) quite sophisticated means of cursor control, however this is something that on the DOS level needs to be supported. And there are/were many different and largely incompatible sets of terminal control codes out there... Ralf -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
> And as there aren't many tools where ZB's idea would make > sense in his opinion, it seems a bit like brewing up a tempest in a > teacup... ;-) +1 > And another reason why this might not be in general a good idea is if we > take compatibility with old(er) DOS software/environments serious, one > might want to consider that DOS (in its basic form) was able to run on > non-memory mapped devices, like serial terminals, which might limit your > ability to move the cursor quite a bit. UNIX System V certainly was connected to serial terminals (Televideo, VT100, ...) and it had the VI visual editor with definitively cursor movement across the screen, even when the terminal had no cursor keys. cursor movement is not tied to memory-mapped devices, and even old DOS Software (MS Word and friends) were derivative of CP/M software where they also have to live with serial terminals. they (for the most part) used only BIOS funtions for screen control. only much later direct memory control became en vogue. Tom ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
On 8/31/2020 7:16 PM, Jon Brase wrote: > Not that convincing rationale considering rather modest overhead necessary. Recall that FreeDOS isn't just about having a FOSS alternative to MS-DOS for modern machines (where you're really better off just using Linux and DOSBox), or for your early-90s 486 retrogaming machine, it's also meant to be an alternative to MS-DOS for the very oldest PC hardware, all the way back to the original IBM 5150. The core software might therefore be expected to work in very little RAM. As I recall, the minimum configuration for the 5150 had only 16k of RAM. Well, yes and no. On a bare minimum PC with only 16KB of RAM, even PC-DOS 1.0 would not run, as this was just for the absolute minimum 14KB IIRC, DOS 2.0 was something in the order of 30KB already. So to run any PC with "DOS", you needed a machine with at least 64KB of RAM, or you could just work with the ROM BASIC... But in general, a lot of those simple command line tools, that in fact have a command line "line" input (right out of my head, I can only think of EDLIN and DEBUG), should be able to work in minimalistic environments. And as there aren't many tools where ZB's idea would make sense in his opinion, it seems a bit like brewing up a tempest in a teacup... ;-) And another reason why this might not be in general a good idea is if we take compatibility with old(er) DOS software/environments serious, one might want to consider that DOS (in its basic form) was able to run on non-memory mapped devices, like serial terminals, which might limit your ability to move the cursor quite a bit. Yes, a bit of a stretch nowadays, but something to keep in mind... :-P Ralf -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
> I'm not sure, but probably a program can distinguish whether it's in > "interactive mode" or used for batch processing? It seems like this should be > possible, but I don't think it is. I've tried doing something similar > (though not quite the same), where I tried to automatically detect whether my > program was being run from the command-line or being "called" (via the DOS > EXEC function) from another program. I could never figure out a way to > automatically detect this. The closest I could come was figuring out the > name of the "parent" program and compare it to a list of known command-line > interpreters (from MS, FreeDOS, 4DOS, etc.). I abandoned the idea since it > was pretty unreliable. If there are some keystrokes you ALWAYS want to "type" > at the beginning of a particular program, you should start the program with a > batch file and use a "keyboard stuffing" utility (there are several of those > available, including my SCANCODE program). However, you should be able to > tell whether your input is coming from the keyboard or being redirected from > a file (which I believe is what is being meant by "batch processing"). With > some of my programs, I do something similar with the output. These programs > have an "automatic pause" feature that stops when the screen gets full > (similar to piping the output of the program to MORE). However, if the > program detects that the output has been redirected to something other than > STDOUT (the screen), the auto-pause is disabled so the entire output is > redirected with no pauses. Sponsored by https://www.newser.com/?utm_source=part_medium=uol_campaign=rss_taglines_more Suit: McDonald's 'Intentionally' Hurt Black Franchisees http://thirdpartyoffers.juno.com/TGL3141/5f4e725a866b9725a7d46st04vuc1 Cheater's NYT Wedding Story Gave Away a Little Too Much http://thirdpartyoffers.juno.com/TGL3141/5f4e725aa9c70725a7d46st04vuc2 Trump Mentions Plane Filled With 'Thugs' in Dark Uniforms http://thirdpartyoffers.juno.com/TGL3141/5f4e725acdaf4725a7d46st04vuc3___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
On Tue, Sep 1, 2020 at 1:35 AM Jon Brase wrote: > > > Not that convincing rationale considering rather modest overhead necessary. > > Recall that FreeDOS isn't just about having a FOSS alternative to MS-DOS for > modern machines (where you're really better off just using Linux and DOSBox), > or for your early-90s 486 retrogaming machine, it's also meant to be an > alternative to MS-DOS for the very oldest PC hardware, all the way back to > the original IBM 5150. The core software might therefore be expected to work > in very little RAM. As I recall, the minimum configuration for the 5150 had > only 16k of RAM. A decent laptop these days will have more 16k blocks of RAM > than a minimal 5150 had *bits* of RAM. So for FreeDOS to work on such > machines, it has to treat kilobytes like young whippersnappers like me treat > gigabytes. 500 or 800 bytes starts looking pretty expensive at that rate. And just who still *has* a working 5150 with 16KB RAM and doing what with it if they do? (For that matter, who is still running original ancient hardware that *hasn't* taken it to the full 640K of supported user memory?) The earliest 5150 model could take 64K on the motherboard, but later models increased that. (The 640KB limit for user accessible RAM was an IBM decision. The 8088 CPU has a 1MB address space.) The earliest versions of DOS looked a lot like CP/M under the hood, which is unsurprising. The previous range of machines the IBM PC was designed to replace were boxes from manufacturers like Osborne and used the Intel 8080 or Intel compatible Zilog Z80 and ran CP/M. Those earlier CPUs had a 64K address space (and some of the machines came with 48K of RAM.) A design goal for the earliest PC was to make it easy to port software originally developed on CP/M machines, like WordStar and VisiCalc, to the new architecture. While early PCs might have been released with as little as 64K of RAM, more was common. (A machine at a former employer had 256K.) Pretty much everything got extended to the full 640K main memory to accommodate RAM hungry applications. (Think Lotus 123, and larger and larger spreadsheets.) Complaints that changes like this make them harder to run on really old kit are only meaningful if someone is *trying* to. I think even the "pure DOS machines" folks here who *only* run DOS have machines with 640K, and possible expansion RAM in EMS or XMS flavors. __ Dennis ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
On Mon, Aug 31, 2020 at 09:16:54PM -0500, Jon Brase wrote: > Recall that FreeDOS isn't just about having a FOSS alternative to MS-DOS > for modern machines (where you're really better off just using Linux and > DOSBox), or for your early-90s 486 retrogaming machine, it's also meant > to be an alternative to MS-DOS for the very oldest PC hardware, all the > way back to the original IBM 5150. The core software might therefore be > expected to work in very little RAM. As I recall, the minimum configuration > for the 5150 had only 16k of RAM. Do you mean FreeDOS should be "alternative to PC-DOS V1.0"? And it should be kept in such (supposed) miserable state? I still have somewhere diskette with PC-DOS V2 - it wasn't interesting experience, compared to - say - DOS V3.34. No, I don't think FreeDOS should be "alternative to MS-DOS for the very oldest PC hardware, all the way back to the original IBM 5150". If it can be run on old XT with 256 KB RAM - then IMHO "it's compatible enough" -- regards, Zbigniew ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
On 01/09/2020 04:16, Jon Brase wrote: it's also meant to be an alternative to MS-DOS for the very oldest PC hardware, all the way back to the original IBM 5150. The core software might therefore be expected to work in very little RAM. As I recall, the minimum configuration for the 5150 had only 16k of RAM. (...) So for FreeDOS to work on such machines, it has to (...) Sorry, but there is no chance that FreeDOS could possibly run on 16K RAM. It requires at least 10 times as much, only to load itself (kernel needs about 64K, command.com requires roughly another 64K, plus buffers and stack) - and more to run any application bigger than a COM-style hello world. Mateusz ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
> Not that convincing rationale considering rather modest overhead necessary. Recall that FreeDOS isn't just about having a FOSS alternative to MS-DOS for modern machines (where you're really better off just using Linux and DOSBox), or for your early-90s 486 retrogaming machine, it's also meant to be an alternative to MS-DOS for the very oldest PC hardware, all the way back to the original IBM 5150. The core software might therefore be expected to work in very little RAM. As I recall, the minimum configuration for the 5150 had only 16k of RAM. A decent laptop these days will have more 16k blocks of RAM than a minimal 5150 had *bits* of RAM. So for FreeDOS to work on such machines, it has to treat kilobytes like young whippersnappers like me treat gigabytes. 500 or 800 bytes starts looking pretty expensive at that rate. ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
On Mon, Aug 31, 2020 at 8:43 PM ZB wrote: > On Mon, Aug 31, 2020 at 05:07:14PM -0400, dmccunney wrote: > > > One of the most popular was Chris Dunford's CED. The following from > > the CED docs is relevant: > > Thanks, I'll try to examine it. Still my suggestion is to make all these > tools of FreeDOS, that offer command line - better. There's really no valid > reason _not_ to use these few keys present on every PC's keyboard. Neither > there was any in the past as well - as I think about this today maybe > "command history" had to be invented, but why MS$ didn't order their > programmers to make use out of that keys too - no idea. Maybe simply > "because those utilities were still usable with poor quality command-line". > Not that convincing rationale considering rather modest overhead necessary On something like *nix, the GNU readline library can provide it. Overhead is low because it's a shared library rather than inline code in applications that use it. But it requires the OS to support a shared library function, and the GPL can be a deal breaker. The GPL is viral, and the license makes any code that links against Gnu code also covered by the GPL. That's a deal breaker for a lot of open source products that are explicitly *not* issued under the GPL. (As a huge example, Google does not use GPLed code in anything they do, and won't. They need to reinvent that particular wheel due to incompatible licensing.) Granted, the *hardware* resources required for something like this is low. The main resource constraint is *developer* time. Just who will *make* these changes? (A lot of what people have expressed a desire for on the FreeDOS list is sophisticated system level programming, and the kind of folks who can do it tend to want to be *paid* for that sort of effort. They won't do it for free.) The advantage if available for using a TSR is that it's effectively a shared library whose functionality can be available to any DOS programming running where it is installed. In the case in question, CED (and other similar products) features are available to any application using DOS function 0AH to get input. You might start by looking at what DOS programs you think could benefit from this use to get input. A change to using 0AH makes the functionality of a TSR like CED available in them, and is likely simpler and less intrusive than building in command line recall and editing. And the TSR can generally be loaded "high". > regards, > Zbigniew __ Dennis ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
On Mon, Aug 31, 2020 at 05:07:14PM -0400, dmccunney wrote: > One of the most popular was Chris Dunford's CED. The following from > the CED docs is relevant: Thanks, I'll try to examine it. Still my suggestion is to make all these tools of FreeDOS, that offer command line - better. There's really no valid reason _not_ to use these few keys present on every PC's keyboard. Neither there was any in the past as well - as I think about this today maybe "command history" had to be invented, but why MS$ didn't order their programmers to make use out of that keys too - no idea. Maybe simply "because those utilities were still usable with poor quality command-line". Not that convincing rationale considering rather modest overhead necessary -- regards, Zbigniew ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
On Mon, Aug 31, 2020 at 3:47 PM ZB wrote: <...> Recall that in the old days, DOS *COMMAND.COM* did not have command line recall and edito\ing. To get it, you installed a TSR that added it. There were a number of them. One of the most popular was Chris Dunford's CED. The following from the CED docs is relevant: "CED is active either at the DOS prompt, or when an application program requests buffered keyboard input from DOS (DOS function 0AH). There are a few such programs (DEBUG and EDLIN are two); but the main use of CED is at the DOS prompt." Do you use a TSR command line editor in your DOS sessions? If you do, DEBUG might already have a lot of what you like because the TSR command editor is active in it. FreeDOS includes JPSoftware's 4DOS COMMAND.COM replacement, but I tend to load a DOS TSR command editor high in a DOS session, so it's available if I shell out of the DOS app, which may not have memory left when shelled out to reload 4DOS., __ Dennis ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
On Mon, Aug 31, 2020 at 12:40:34PM -0700, Ralf Quint wrote: > If you are trying to keep 20 lines in the "history" and even assuming you > limit the length of an entry line to 40 characters, that's already 800 > bytes, just for the buffer space... ...IN RAM, not in program code. :) > But in any case, FreeDOS DEBUG is open source, so feel free to try and add > this and see how much work it is (and if it is worth the effort)... ;-) I'm still learning - that's why use debug. But even if you think it's not worthy - maybe the others think it is, anyway? It was my suggestion, not "an order" -- regards, Zbigniew ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
On 8/31/2020 11:28 AM, ZB wrote: On Mon, Aug 31, 2020 at 11:10:56AM -0700, Ralf Quint wrote: On 8/31/2020 10:44 AM, ZB wrote: ... 2. It could keep "history" for last, say. twenty-thirty command-line entries (available as usual with Up/Down keys). ... A second issue is that a lot of those tools are created for low resource environment, so adding all those editing features to it can increase the size of their executables. Beside that you can easily get to the point where it makes more sense to use a bigger, more "advanced" program with things like full screen editing in the first place. My estimation is it'll "cost" from 200 to 500 bytes more - and, please note, we aren't talking about "adding bloat", but about making command line more useful and comfortable. Why these keys should stay "dead"? Let's use them! If you are trying to keep 20 lines in the "history" and even assuming you limit the length of an entry line to 40 characters, that's already 800 bytes, just for the buffer space... But in any case, FreeDOS DEBUG is open source, so feel free to try and add this and see how much work it is (and if it is worth the effort)... ;-) Ralf -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
One more I'm less interested in, but maybe it would be useful for the others? I mean assuming we have full control over cursor movement as already described - the "Ins" key could be a switch between default "insert" and alternative "overwrite" mode (if not too complicated to implement) -- regards, Zbigniew ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
On Mon, Aug 31, 2020 at 08:11:48PM +0200, Eric Auer wrote: > Mercury also suggests Ctrl-Arrow for word-wise cursor movements. Alternatively we could use PgUp/PgDn for this, which aren't used (and probably won't be used for anything) by debug. This could have advantage of "Control" not being involved at all -- regards, Zbigniew ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
On Mon, Aug 31, 2020 at 08:11:48PM +0200, Eric Auer wrote: > It can harm if you do batch processing. And WHY do you perform "r" > at the start? I always only look at "r" AFTER doing things which > will have sent interesting data to the registers, NOT before. Just realized it's an old habit :D if you were ever using C-64, perhaps you were also using "SMON" monitor ( https://www.c64-wiki.de/wiki/SMON ) it does that on automatic. And in my C-64 times (which actually still didn't find their definite end ;) it was a monitor I was using most of the time. I'm not sure, but probably a program can distinguish whether it's in "interactive mode" or used for batch processing? -- regards, Zbigniew ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
On Mon, Aug 31, 2020 at 11:10:56AM -0700, Ralf Quint wrote: > On 8/31/2020 10:44 AM, ZB wrote: > > 1. I believe it would be handy if it could immediately after its start > >perform 'r' (show registers' contents). Usually we're going to have > >a look at that first when using "debug". Even if we aren't - having > >these two lines on the screen immediately after start won't do any harm. > > > > 2. It could keep "history" for last, say. twenty-thirty command-line entries > >(available as usual with Up/Down keys). > > > > 3. Its command line should recognize "movement keys" just like command.com > >does, I mean Home/End should move cursor to beginning and end current > >entry, Left/Right also for movement (presently Right does just "latest > >entry" while Left is redundant "Backspace" copy) and Del should "eat" > >characters "right from the cursor" (the usual "Del way"). > > > > Just basic stuff. Actually I believe that EVERY utility that offers command > > line entry should act like I described in points 2 and 3. Why not use these > > keys we have present on every PC keyboard - for easier and faster editing? > > Well, I am not sure that this is such a good idea. A lot of those command > line tools are also capable of being used in an interactive mode, DEBUG for > example can be fed instructions to create small/tiny .COM programs via > assembler instructions. Indeed I'm talking exactly about its interactive mode. > A second issue is that a lot of those tools are created for low resource > environment, so adding all those editing features to it can increase the > size of their executables. Beside that you can easily get to the point where > it makes more sense to use a bigger, more "advanced" program with things > like full screen editing in the first place. My estimation is it'll "cost" from 200 to 500 bytes more - and, please note, we aren't talking about "adding bloat", but about making command line more useful and comfortable. Why these keys should stay "dead"? Let's use them! -- regards, Zbigniew ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
On Mon, Aug 31, 2020 at 08:11:48PM +0200, Eric Auer wrote: > Hi ZB, > > > 1. I believe it would be handy if it could immediately after its start > > perform 'r' (show registers' contents). Usually we're going to have > > a look at that first when using "debug". Even if we aren't - having > > these two lines on the screen immediately after start won't do any harm. > > It can harm if you do batch processing. And WHY do you perform "r" > at the start? I always only look at "r" AFTER doing things which > will have sent interesting data to the registers, NOT before. Well, I'll survive without this - but I believe commad-line editing keys (that I have just in front of me) beg to be used. ;) I'm aware most of original DOS utilities didn't use these - but I believe there's no need to keep that "dark side" of DOS legacy. FreeODS tools can - and should - be better than original ones. > Mercury also suggests Ctrl-Arrow for word-wise cursor movements. It would be handy too, I agree -- regards, Zbigniew ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
Hi ZB, > 1. I believe it would be handy if it could immediately after its start > perform 'r' (show registers' contents). Usually we're going to have > a look at that first when using "debug". Even if we aren't - having > these two lines on the screen immediately after start won't do any harm. It can harm if you do batch processing. And WHY do you perform "r" at the start? I always only look at "r" AFTER doing things which will have sent interesting data to the registers, NOT before. > 2. It could keep "history" for last, say. twenty-thirty command-line > entries (available as usual with Up/Down keys). That would be nice, yes. > 3. Its command line should recognize "movement keys" just like command.com > does, I mean Home/End should move cursor to beginning and end current > entry, Left/Right also for movement (presently Right does just "latest > entry" while Left is redundant "Backspace" copy) and Del should "eat" > characters "right from the cursor" (the usual "Del way"). Basically you want https://en.wikipedia.org/wiki/GNU_Readline > Just basic stuff. Actually I believe that EVERY utility that offers command > line entry should act like I described in points 2 and 3. Why not use these > keys we have present on every PC keyboard - for easier and faster editing? Mercury also suggests Ctrl-Arrow for word-wise cursor movements. Regards, Eric ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
On 8/31/2020 10:44 AM, ZB wrote: 1. I believe it would be handy if it could immediately after its start perform 'r' (show registers' contents). Usually we're going to have a look at that first when using "debug". Even if we aren't - having these two lines on the screen immediately after start won't do any harm. 2. It could keep "history" for last, say. twenty-thirty command-line entries (available as usual with Up/Down keys). 3. Its command line should recognize "movement keys" just like command.com does, I mean Home/End should move cursor to beginning and end current entry, Left/Right also for movement (presently Right does just "latest entry" while Left is redundant "Backspace" copy) and Del should "eat" characters "right from the cursor" (the usual "Del way"). Just basic stuff. Actually I believe that EVERY utility that offers command line entry should act like I described in points 2 and 3. Why not use these keys we have present on every PC keyboard - for easier and faster editing? Well, I am not sure that this is such a good idea. A lot of those command line tools are also capable of being used in an interactive mode, DEBUG for example can be fed instructions to create small/tiny .COM programs via assembler instructions. A second issue is that a lot of those tools are created for low resource environment, so adding all those editing features to it can increase the size of their executables. Beside that you can easily get to the point where it makes more sense to use a bigger, more "advanced" program with things like full screen editing in the first place. Ralf -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] A few suggestions to improve debug
4. Ctrl + Arrow should skip a word at a time, as in most modern text editors. Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Monday, August 31, 2020 1:44 PM, ZB wrote: > 1. I believe it would be handy if it could immediately after its start > perform 'r' (show registers' contents). Usually we're going to have > a look at that first when using "debug". Even if we aren't - having > these two lines on the screen immediately after start won't do any harm. > > 2. It could keep "history" for last, say. twenty-thirty command-line entries > (available as usual with Up/Down keys). > > 3. Its command line should recognize "movement keys" just like command.com > does, I mean Home/End should move cursor to beginning and end current > entry, Left/Right also for movement (presently Right does just "latest > entry" while Left is redundant "Backspace" copy) and Del should "eat" > characters "right from the cursor" (the usual "Del way"). > > Just basic stuff. Actually I believe that EVERY utility that offers > command > line entry should act like I described in points 2 and 3. Why not use > these > keys we have present on every PC keyboard - for easier and faster editing? > -- > regards, > Zbigniew > > > 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
