On Fri, 2 Apr 2004 10:03:12 +0400 (MSD), you wrote: Hi Arkady,
> Of course, MEM doesn't store screen output into internal buffers. If >you wish to use scrolling possibility, use 3rd party utilities (usually >named LESS). I start with M$-DOS 3.2, when the first time I use DIR I have the feeling: hey! why the screen didn't stop after the page is full? Eric "teach" me "programmers concern" before. But I think the old standard DOS behaviour is a bit too old, too user hostile, neither frightened them away or make them feel using "windows" more comfort > I may add possibility to "pause" by default if output isn't redirected >(to file), but this option wasn't default for any original DOS program. >Also, imagine: you redirect to NUL (which is character device, like CON) and >will not know, why MEM is "hang" whereas it simply waits "any key" after >each screen. Yes, this is a problem, for me it's the "weakness" of DOS, why MORE or LESS exist because many years ago, programmers want to did the job easily without writing extra code, then they skipped to code the program "smart" enough to determine the situation ... After a decade, some command line program such as MI and PKZIP, ARJ growing up, becoming "smart" with automatic screen pause, also can redirected to file without "hang". What I think is - can we copy the idea from them and let FreeDOS "smart" like them It's an improvement and let user feel comfort, also without breaking up the current usage of LESS or MORE, if you want advance function of MORE or LESS, just add a switch to disable automatic pause As a programmer, yes, this is extra work (oh I'm sorry I let you do extra work). If it's very difficult to code ... if I'm a programmer I'll also like you - leave it alone, but if the work is not so big, adding the "smart" feature and let the "new/normal" user feel happy also benefit to FreeDOS image, "it's easier than M$-DOS, with compatibility and even better quality" > This functionality is out of scope MEM. Again: for this extended >scrolling functionality you should use 3rd part scrolling programs (LESS) or >redirect to file (which you may browse with any viewer/editor). Yes, I agree with you, this is out of scope of MEM. I can understand programmers should focus on the program's "main usage" other than this kind of standard I/O. I think is it possible someone code the smart I/O handling as a "standard library" and become a standard behaviour when compiling, avoid duplicating effort also being "smart" for every command line program > First, all lines in complete list (/A) above separator relate to (and >only to) low memory, all lines below separator relate only to (and only to) >upper memory. To see how much given _program_ (not alone memory block) uses >_both_ low and upper memory, was designed /C option. I know you put a lot of time to improve, you MEM did an excellent job when displaying memory usage information. I just provide a user's point of view for you as reference, for example: When I use MEMA/A, I see a program "NMTSR" resides in LOW area, then press a key to scroll, and see a program also named "NMTSR" in HIGH area, and I've to compare the name, it's same ... oh it's the same program have loaded itself high! During this I may need LESS to scroll back to confirm When I use MI, at first glance I know "NMTSR" is a single program which have a part LOW and a part HIGH (in the same line!), no need to guess it's the same program! The format is so friendly and better use a single line to display "as many information as it can" Addr. Low area High area Program or device driver ----- -------- --------- -------------------------- 02E7h 1,248 .. Device=HIMEM Attr=A000h Name=XMSXXXX0 **Sorry for hard-selling this format, but I love it too much! Rgds, Johnson. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
