{var%20f='http://v.t.sina.com.cn/share/share.php?appkey=1515056452',u=z||d.location,p=['&url=',e(u),'&title=',e(t||d.title),'&source=',e(r),'&sourceUrl=',e(l),'&content=',c||'gb2312','&pic=',e(p||'')].join('');function%20a(){if(!window.open([f,p].join(''),'mb',['toolbar=0,status=0,resizable=1,width=440,height=430,left=',(s.width-440)/2,',top=',(s.height-430)/2].join('')))u.href=[f,p].join('');};if(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else%20a();})(screen,document,encodeURIComponent,'','','https://www.manongdao.com/data/attach/logo/logo.png', '推荐 戒情不戒烟 的问题《How buffered input works》','https://www.manongdao.com/q-82915.html','页面编码gb2312|utf-8默认gb2312'));){kind=link}
The input in next program works OK, but when I ask to display the output, DOS doesn't display anything at all! How is this possible?
ORG 256
mov dx, msg1
mov ah, 09h ;DOS.WriteString
int 21h
mov dx, buf
mov ah, 0Ah ;DOS.BufferedInput
int 21h
mov dx, msg2
mov ah, 09h ;DOS.WriteString
int 21h
mov dx, buf
mov ah, 09h ;DOS.WriteString
int 21h
mov ax, 4C00h ;DOS.TerminateWithExitcode
int 21h
; --------------------------------------
msg1: db 'Input : ', '$'
buf: db 20 dup ('$')
msg2: db 13, 10, 'Output : ', '$'
; --------------------------------------
Inputting text using
int 21h AH=08hAll three input methods described until now (in the above answer!) were clearly tailor-made to suit Microsoft tools like EDLIN.EXE and COMMAND.COM.
If you are writing your own application then better results can be achieved through producing your own input procedure. At the heart of such a procedure will be one of the DOS single character input functions. I chose the STDIN Input function 08h because I want to allow ctrlC/ctrlBreak checking and I intend to echo the characters myself via BIOS
Int 10h AH=09hWrite Character And Attribute At Cursor Position. This way I can avoid messing up any redirected output.Programmatically there's no difference in using this BufferedInput procedure or the DOS.BufferedInput system call. However for the user at the keyboard inputting will be much easier since all the keys associated with the old and difficult template editing have been dismissed and replaced by the usual editing keys that enable you to freely move the cursor around.
If the 2nd byte of the input buffer holds a non-zero value then the storage space is supposed to contain an old string (perhaps from a previous input). DOS would have called this the template. Different from DOS is that:
While the input is in progress, tabs are not expanded and the input is confined to staying within the current row. Longer texts will scroll horizontally.
When the input is finally done, the completed text is written once with tab expansion (on screen, the storage space will always hold ASCII 9) and no longer restricted to a single row.
This procedure does ctrlC/ctrlBreak checking.
When this procedure finishes, the cursor will be in the far left column on the current row.
This procedure was written with input redirection and output redirection in mind, and thus well suited for console applications.
One effect of input redirection is that it's useless to echo any temporary output to the screen. Either the user is not there to gaze at the screen or the temporary output will be gone in the blink of an eye.
Example 4, Improved Buffered STDIN input.
Problem understanding the source? The assembler I used:
push cx sitranslates topush cxpush si.Looking at how you defined your input buffer (
buf: db 20 dup ('$')), I get it that you want to cut corners and have the input already $-terminated ready for re-displaying it. Sadly this messes up the required settings for the DOS input function 0Ah and your program is in serious problems with a potential buffer overrun.Moreover using $-termination is not the brightest choice that you can make since the $ character could already appear amongst the inputted characters. All the example programs that I present below will use zero-termination instead.
Inputting text using
int 21h AH=0AhThis Buffered STDIN Input function gets characters from the keyboard and continues doing so until the user presses the Enter key. All characters and the final carriage return are placed in the storage space that starts at the 3rd byte of the input buffer supplied by the calling program via the pointer in
DS:DX.The character count, not including the final carriage return, is stored in the 2nd byte of the input buffer.
It's the responsibility of the calling program to tell DOS how large the storage space is. Therefore you must put its length in the 1st byte of the input buffer before calling this function. To allow for an input of 1 character you set the storage size at 2. To allow for an input of 254 characters you set the storage size at 255.
If you don't want to be able to recall from the template any previous input, then it is best to also zero the 2nd byte. Basically the template is the pre-existing (and valid) content in the input buffer that the calling program provided. If pre-existing content is invalid then the template is not available.
Surprisingly this function has limited editing facilities.
The current input is abandoned but stays on screen and the cursor is placed on the next row, beneath where the input first started.
Works as expected if the input stays within a single row on screen. If on the other hand the input spans several rows then this backspacing will stop at the left edge of the screen. From then on there will be a serious discrepancy between the logical input and the visual input because logically backspacing will go on until the 1st position in the storage space is reached!
The screen will show "^Z".
The screen will show "^@".
Many more editing keys are available. They are all reminiscent of EDLIN.EXE, the ancient DOS line editor, which is a text editor where each previous line becomes the template on which you build the next line.
Tabs are expanded by this function. Tab expansion is the process of replacing ASCII 9 by a series of one or more spaces (ASCII 32) until the cursor reaches a column position that is a multiple of 8.
This tab expansion only happens on screen. The storage space will hold ASCII 9.
This function does ctrlC/ctrlBreak checking.
When this function finishes, the cursor will be in the far left column on the current row.
Example 1, Buffered STDIN input.
Inputting text using
int 21h AH=3FhWhen used with predefined handle 0 (in
BX) this Read From File Or Device function gets characters from the keyboard and continues doing so until the user presses Enter. All characters (never more than 127) and the final carriage return plus an additional linefeed are placed in a private buffer within the DOS kernel. This now becomes the new template.Hereafter the function will write in the buffer provided at
DS:DX, the amount of bytes that were requested in theCXparameter. IfCXspecified a number that is less than the number of bytes generated by this input, one or more additional calls to this function are required to retrieve the complete input. As long as there are characters remaining to be picked up, this function will not launch another input session using the keyboard! This is even true between different programs or sessions of the same program.All the editing keys described in the previous section are available.
Tabs are expanded on screen only, not in the template.
This function does ctrlC/ctrlBreak checking.
When this function finishes, the cursor will be in the far left column on the
Example 2a, Read From File Or Device, pick up all at once.
Example 2b, Read From File Or Device, pick up one byte at a time.
Inputting text using
int 2Fh AX=4810hThis DOSKEY Buffered STDIN Input function can only be invoked if the DOSKEY.COM TSR was installed. It operates much like the regular Buffered STDIN Input function 0Ah (see above), but has all the same editing possibilities as the DOS command line, including the ability to use all of the DOSKEY special keys.
On DOS 6.2 the storage space is always limited to 128 bytes, allowing an input of 127 characters and room for the mandatory carriage return. It's not possible to pre-load a template, so always set the 2nd byte of the input buffer to zero.
On DOS Win95 the storage space can be as big as 255 bytes if you installed the DOSKEY.COM TSR with a command like
doskey /line:255. It's possible to pre-load the storage space with a template. This brings the Win95 version very close to what is feasable with input function 0Ah.This function does ctrlC/ctrlBreak checking.
When this function finishes, the cursor will be in the far left column on the current row. If the character count is zero, it means that the user typed in the name of a DOSKEY macro that was not yet expanded. You don't get to see the un-expanded line! A second invocation of the function is needed and upon returning this time, the cursor will be behind the last character of the expanded text.
A peculiarity is that when a multi-command macro (
$T) gets expanded, you only get the expanded text of the 1st command. Additional invocations of the function are needed to get the other expanded texts. Although all of this is very useful from within a command shell like COMMAND.COM, from within a user application it's really annoying that you can't know when this happens.Since the inputted text is added to the command history, it is unavoidable that the history fills up with unrelated items. Certainly not what you want to see at the DOS prompt!
Example 3, Invoking DOSKEY.COM.
Inputting text using
int 21h AH=08hProblem understanding the source? The assembler I used:
push cx sitranslates topush cxpush si.