Explanation of why some code needs <cr>,<ctl cr> to terminate a text READ or PAUSE
Run DOS applications in Windows.
Brought to you by:
emendelson,
josschaars
I reported this problem more than once and was asked to try to
define better the circumstances (mainly Microsoft compilers)
and MS and other compiled Fortran programs.
I found that with text reads, and response to PAUSEs in early MS
code, ^C is not processed, and reads or pauses can not be terminated
with the <ret> key, but all need <ret>, then <ctl-ret> to work.</ctl-ret></ret></ret>
In Chapter 7 of Dave Williams' "Programmer's Technical Reference
for MSDOS and the IBM PC" (1992), I think I found the explanation
in the section on the File Read in Ascii Mode service (0Ah).
This is a LONG chapter and I could not find how to attach this,
but a quick description is:-
MS compilers and compiled programs often use ascii file access
services (0Ah), using handles 1 through 5. I know MS Fortran does!
The read service (standard input) checks for and acts on ^C,^S,^P
and ^Z. It also traps <cr>, <lf> and <cr-lf> combinations and
replaces cr or lf alone by cr-lf, as long as there is room in the
specified buffer and then terminates! ^Z terminates and closes.
The PAUSE statement uses this same service.
Control-C causes complete program termination.</cr-lf></lf></cr>
This matches exactly what I have been seeing in code pre- 2000.
I doubt vDos emulates this service but adapts a simpler service.
I don’t know why I even bother, INT 21-0Ah is a DOS 1 function!
No mention of intercepting ^S, ^P, ^Z or translating <cr> to <cr><lf> in Ralf Brown’s Interrupt List. I also tested INT 21=0Ah with NTVDM, here also no special handling of these keys. Only ^C, but that can’t be done by vDos, it doesn’t maintain a DOS internal break flag or INT 23.</lf></cr></cr>
So it has to be something else, or your programs don’t even run in NTVDM.
You should probably just upgrade to newer versions of your compilers.
I can’t invest time in some obsolete DOS function no one uses, except you.
Jos
Jos, The problem is occurring in ALL DOS versions up to V6.1 that I have.
The compilers are Microsoft Fortran V3 and V4 of 1985 and later.
The reference I gave given applies to what was common usage in 1997.
The EARLIEST DOS I even worked with myself was V5.
The use of file handles was central to Microsoft view of file usage.
Can you suggest a 'later' Fortran Compiler for MSDOS use (that I don't
already have)? The concept of 5 standard I/O units is fundamental to
Fortran (and I worked on Fortran in IBM, 1960 on).
I have Fortran compilers (DVF, Intel, Lahey) for native Windows targets,
but their use in Windows will not allow the access to ports for
laboratory control functions and some office hardware for data capture.
Hence the continued use of MSDOS where possible.
(Yes Porttalk and other port release programs work, but they had to
pre-loaded on every computer in the office, before the MSDOS session).
And also screen, keyboard and mouse control under Windows is so different
that it would require almost total re-write even if the source were
still to be available (mostly not).
Vdos is FINE and works, but has these tiny human interface glitches.
I repeat these programs are by far, NOT my programs, nor are the compilers
where this ascii file reading is all encoded.
Suppose you put a switch in CONFIG that determined if cr, or lf, should
be replaced by cr-lf if the service was Int 21 0Ah, and the read terminated?
So your programs already had this issue all the time, it didn’t arise in vDos?
You could have a look at vetusware.com if newer compilers are available (menu at the bottom, search).
Pre 2.0 MS-DOS didn’t know file handles, it worked with FCB’s.
If you would use vDos to access hardware ports, you will get stuck. All LPT and COM ports in vDos are considered to be used for printing. No support for reading and writing is directed to files.
You would be the only one to use a switch in config.txt for a modified INT 21-0Ah function. So you or some other willing programmer should modify the vDos code.
Jos
Why not hire a programmer to do this for you? That way you will actually get it to happen. It won't happen otherwise.
Hello:
I have been in programming in FORTRAN for 30+ years and Ctrl C/S/P/Z and <cr> & <cr><lf> are a pain in the ??? but they can be handled. You need a RPA (Read Pass All) solution and unfortunately FORTRAN can not do this directly. In DEC FORTRAN you use a VMS (or RSX if you really have an old system) System Services Call called “QIO” and add-on on terminal driver options to the QIO to bypass the standard terminal driver options.</lf></cr></cr>
In Microsoft Fortran you use DOS internal calls to make it happen. Use INT 21-07h instead of INT 21-0Ah. This routine will read any keyboard scan code (normal and extended) and ignore Ctrl-C.
Below is MASM code to read PC keyboards via FORTRAN.
.MODEL LARGE
;
; {START MANUAL BLOCK}
;
;--- KEY_RPA.ASM (RPA = Read Pass All)
;
; \=======================================/
; ( N W R C o n t r o l S y s t e m s )
; /=======================================\
;
; THIS ROUTINE WILL:
;
; -READ IN ANY KEYBOARD CHARACTER AND RETURN IT AS A I2 NUMBER AND
; THE HIGH BYTE IS CLEAR.
; -IT TAKES 2 READS, TO READ IN AN EXTENDED (F1, HOME, ETC) KEYSTROKE
; -FIRST READ IS A NULL AND THE 2ND READ IS THE KEY SCAN CODE.
; -THE SCAN CODE FOR AN EXTENDED KEY IS NOT UNIQUE AND IT LOOKS LIKE A
; NOT EXTENDED KEY WAS PRESSED.
; -MAKE THE EXTENDED KEY NUMBER -VE AND NOW IT IS UNIQUE.
;
; -SEE "C:\DOSCODE\COMLIB\KEYS.INC" TO CHANGE NUMBERS INTO KEYBOARD
; KEYS.
;
; FORTRAN CALL:
;
; CALL KEY_RPA(NUMBER)
;
; NUMBER : OUTPUT I2
;
; {END MANUAL BLOCK}
;
; MODIFICATION HISTORY;
; =====================
;
; DAVID DODGE V-1.1 17-May-2011 18:06:01
;
; -RENAMED RPA.ASM TO KEY_RPA.ASM
;
; DAVID DODGE V-1.0 15-Dec-1989 15:30:47
;
; -CREATED
;
; ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
;
.CODE
;
PUBLIC KEY_RPA
KEY_RPA PROC FAR
;
PUSH BP ;SAVE THE REGISTERS
MOV BP,SP
;
MOV AH,07H ;DIRECT CHARACTER INPUT WITHOUT ECHO
MOV CX,1
JMP NON_ASCII
;
EXTENDED:
;
MOV CX,-1 ;EXTENDED VARIABLE SO MAKE IT -VE
;
NON_ASCII:
;
INT 21H ;GENERATE THE INTERRUPT
CMP AL,0 ;TEST FOR A NULL (NEEDS 2 READS)
JE EXTENDED
;
XOR AH,AH ;MAKE SURE THE HIGH BYTE IS CLEAR
MUL CX ;ADD ON THE SIGN OF THE KEYSTROKE
LES BX,DWORD PTR [BP+6]
MOV WORD PTR ES:[BX],AX ;RETURN THE INPUT CHARACTER
;
POP BP ;RESTORE REGISTERS
RET 4 ;CLEAN THE STACK
;
KEY_RPA ENDP
END
I don't quite understand the sentence below that was pasted from a response from the forum moderator. "I don’t know why I even bother, INT 21-0Ah is a DOS 1 function!". I realize vDos is not 100% pure DOS however, what difference does it matter if DOS calls (ie. INT 21-0Ah) are from DOS V-1.0 or any version up to and including V-6.22? I believe that DOS V-1.0 was the only version that has the smarts for reading the keyboard and were ported to all later DOS versions.
I also don’t quite understand the sentence that was pasted from a response (https://sourceforge.net/p/vdos/discussion/general/thread/93171872/) from the same moderator re allowing access to a serial port via vDos. "Accessing serial ports isn’t really a DOS thing...".
My understanding the "purpose" of vDos is to allow 16 bit DOS code to run in a 64 bit environment like Win 7. I know what is DOS and what is not DOS, but please explain what is DOS and what is not DOS related to this forum. Thank you.
David Dodge
David, I really appreciate the trouble you went to to help out.
I copied your example to study against my way (below).
If I HAVE the source code I can fix the emulation problems.
I can't do that with compilers. Luckily MS coded the linkers
differently. I HAVE to compile for MSDOS targets.
And the users also have staff inputting data on the newer
64-bit computers, unfortunately loaded with 64-bit Windows. I
advised most to reload with the 32-bit version, but a lot cannot.
Some people use old computers just to run MSDOS with RS232C
interface control software to existing equipment.
By far the most common language I work with is Fortran, because
it's used by all technological companies and institutions, including
university research in almost all disciplines.
I rarely code a formatted READ or WRITE any more in Fortran,
because I can write to the screen (or invite entry) in any colour
combination and scroll in all four directions, and let the User
edit or confirm or alter text, while doing the full trapping of every
non-text key (shifted numeric, central pad, tab, backspace, delete,
function keys and tab and all the rest.
Then a CASE block decides what the User wants to do with the data,
based on the key-code used to terminate the input.
PAUSE is replaced by get character as input (see INPC(0)).
But doing those changes to any existing code is arduous, even with
parsing tools I developed for that.
Fortran NEVER DEFINED how an entry should be terminated!
Apple tends to use linefeed, most others just <enter></enter>
Here is a tiny ASM sample of how to wait fo,r or test for, any key of
255 keys (using all shifts). (Note: Fortran calling convention).
Use: IKEY=INPC(ioption)
DOS 1 didn’t use file handles, introduced with DOS 2, but FCB’s. To remain compatible, some DOS 2+ functions still have to deal with FCB’s internally. So when DOS 1 functions with the cumbersome FCB’s come in view, Terence only at this moment, after many long posts, came with this “offending” function, implemented, apart from ^C, as in MS-DOS or NTVDM, and he being the only one with this “problem”, I indeed wonder why I bothered.
DOS doesn’t access serial ports itself, it calls BIOS routines for this.
Jos
I really don't know what Jos is referring to here.
I've just reported two ways in a simple test program, freshly
compiled, in which service 3Fh of Interrupt 21h is also giving
problems because linefeed is not being detected and replaced
by carriage return by vDos, and the input terminated on finding
the first carriage return in the buffer.
As Vdos stands now, any use of these ascii buffered read-from-keyboard
services, requires an extra ctl-return keypress after striking the
return key, which slows down data entry! Operators will hate it!
That seems to be two standard input keyboard services which
don't operate according to David Williams detailed
descriptions of DOS services. Rolf's list hasn't anything
like the detail given by Williams.
And I know (can see) what happens in Windows 7 command-line
execution, and it's not the same as under vDos.
And that is the best way to determine if the emulation is correct;
not one's opinion.
Also the delete key is supposed to backspace, echo blank and
wait for the next key. And delete on 103-key keyboards
does not yield the old ascii delete of 7Fh, but a scancode
of 53E0h in both places.
So it's the compiler AND any compiled FORTRAN code that has
this problem, and Fortran programs are pretty much the
majority of commercial programs till running under MSDOS or
Windows command line O/S.
This has to be my last reply to this topic.
You mentioned file handles in conjunction with INT 21-0A. That’s a DOS 1 function, file handles were only introduced with DOS 2.
Since you first reported your keyboard problem, you came with (at least) 4 issues of vDos that should be addressed/fixed:
Only just before coming with Int 21-3F, you mentioned to have withhold that your problem already existed with all DOS versions you used. So it isn’t a matter of fixing vDos supposed incompatibility, but your Fortran programs handling keyboard input.
If you would try in Debug something basic like:
You’ll see Int 21-3F doesn’t wait for an extra <lf>, it even replaces the single <cr> by a <cr><lf> combination. Exactly like MS-DOS and NTVDM do, documented by David Williams and Ralf Brown. The same (no <cr> replacement applicable) for Int 21-0A.
Once again, there’s nothing to fix.</cr></lf></cr></cr></lf>
Your Fortran programs messes things up, not vDos.
Perhaps a bug of older compilers/libraries, incorrect compiling, a missing runtime switch/setting of just a quirk of Fortran.
You would have to look further what causes this problem. Is the linked-in library expecting a reversed <lf><cr> combination, does it always wait for a <cr> and then a separate <lf> (Int 21 call), whatever.
When you finally got it right, create some 30 liner assembly program that replaces Int 21, executes the Fortran program and satisfies it when Int 21-3F is called. Or a TSR program, though that’s more complicated and you probably would have to unload it after running a Fortran program.</lf></cr></cr></lf>
It seems quite a simple solution for your problem. Why isn’t it already done by someone if that problem is around as long as you stated. It surely doesn’t involve any modifications to vDos.
And of course, if you plan to address hardware ports in vDos, you’ll get stuck because vDos doesn’t support this. You would have to resort to DOSBox.
The Delete key deletes the character at the cursor by moving all the characters to the right of it one position to the left. So it has no function at the end of a line. Only the Backspace key first positions one character to the left. The ASCII code is not the same as the keyboard scan code, the latter is defined as 53E0h (extended key) or 5300h for all keyboards.
I can’t imagine Fortran being the most used DOS program nowadays, you’re the only one reporting a problem with it.
Jos
Last edit: Jos Schaars 2015-07-08
Jos, I'm sorry I'm not getting through.
There's no need to reply. Programmers are used to this situation.
Every Fortran executable (about 200 now) and compiler I have has the same problems under vDos in both versions 19/10/2014 and 10/4/2015.
All I want to do is present clear evidence of every problem I found.
I've spent two days organising the proof of each problem, executing on vDos (both v2014 and 2015 versions).
Here's the program being traced.
The READ and the PAUSE both need cr, ctl-cr to terminate.
Whether I can point to the reason or not, the problem is there.
801 FORMAT(A1)
END
Before the post you are replying to, I made a complete debug tracing of this program up to the and including the last 3Fh service in the program. That was 894k of trace data in 16447 lines to that PAUSE statement.
HERE IS WHERE THE 3Fh READ SERVICE IS SET UP, and where debug needs both CR and LF to pass this point, and the the similar 3Fh call for the pause statement that has the same problem.
The fortran call is via stacked register values, picked up by BP.
AX=0001 BX=12B2 CX=05C6 DX=12FA SP=12A6 BP=12B6 SI=0006 DI=13A6
DS=1BD4 ES=1BD4 SS=1BD4 CS=1616 IP=0EA1 NV UP EI PL ZR NA PE NC
1616:0EA1 8BEC MOV BP,SP
AX=0001 BX=12B2 CX=05C6 DX=12FA SP=12A6 BP=12A6 SI=0006 DI=13A6
DS=1BD4 ES=1BD4 SS=1BD4 CS=1616 IP=0EA3 NV UP EI PL ZR NA PE NC
1616:0EA3 8B4E06 MOV CX,[BP+06] SS:12AC=0001
AX=0001 BX=12B2 CX=0001 DX=12FA SP=12A6 BP=12A6 SI=0006 DI=13A6
DS=1BD4 ES=1BD4 SS=1BD4 CS=1616 IP=0EA6 NV UP EI PL ZR NA PE NC
1616:0EA6 8B5608 MOV DX,[BP+08] SS:12AE=13DA
AX=0001 BX=12B2 CX=0001 DX=13DA SP=12A6 BP=12A6 SI=0006 DI=13A6
DS=1BD4 ES=1BD4 SS=1BD4 CS=1616 IP=0EA9 NV UP EI PL ZR NA PE NC
1616:0EA9 8B5E0A MOV BX,[BP+0A] SS:12B0=0000
AX=0001 BX=0000 CX=0001 DX=13DA SP=12A6 BP=12A6 SI=0006 DI=13A6
DS=1BD4 ES=1BD4 SS=1BD4 CS=1616 IP=0EAC NV UP EI PL ZR NA PE NC
1616:0EAC B43F MOV AH,3F
AX=3F01 BX=0000 CX=0001 DX=13DA SP=12A6 BP=12A6 SI=0006 DI=13A6
DS=1BD4 ES=1BD4 SS=1BD4 CS=1616 IP=0EAE NV UP EI PL ZR NA PE NC
1616:0EAE E88200 CALL 0F33
AX=3F01 BX=0000 CX=0001 DX=13DA SP=12A4 BP=12A6 SI=0006 DI=13A6
DS=1BD4 ES=1BD4 SS=1BD4 CS=1616 IP=0F33 NV UP EI PL ZR NA PE NC
1616:0F33 CD21 INT 21
AX=3F01 BX=0000 CX=0001 DX=13DA SP=129E BP=12A6 SI=0006 DI=13A6
DS=1BD4 ES=1BD4 SS=1BD4 CS=F000 IP=12A0 NV UP DI PL ZR NA PE NC
F000:12A0 FB STI
AX=3F01 BX=0000 CX=0001 DX=13DA SP=129E BP=12A6 SI=0006 DI=13A6
DS=1BD4 ES=1BD4 SS=1BD4 CS=F000 IP=12A1 NV UP EI PL ZR NA PE NC
F000:12A1 FE38 ??? [BX+SI] DS:0006=00
HERE IS WHERE THE SERVICE WAITED FOR ONE CHARACTER FOLLOWED BY CR AND THAN CTL_CR.
The same code is also used to handle the PAUSE operation (needed cr,ctl-cr_
I'll leave this here. but add a dicussion of all the problems.
Funny you should should suggest I should hire a programmer; I've been one since 1957, and in my fields am well-known, having lectured and set degree exams on programming and computer theory in London University.
Buffered standard input only STARTED with DOS-1 as a basic service, and was updated in PC-DOS. PCDOS (Dec) and MSDOS in several variants, but the updated concepts I described (not so updated in Rolf's lists) are 1985 and later, or they wouldn't have been used in the Microsoft compilers and the complied programs of 1985 and 1986, one Fortran compiler of which I beta tested.
Fixing these niggling problems myself, needs modifying the emulator code (which I suspect is in a C variant), not patching hundreds of working programs. My commercial 'stuff' from 1976 through 2000 is still running, which is why I'm asked to work on astronomical, observational, orbit and statistical calculations, survey processing systems and language-parsing; all Fortran-based systems, and all originally written for 32 bit DOS/command-line systems. And most data needs a buffered ascii read service.
I'm well aware that you're a programmer. I was suggesting that you should hire a C programmer who can modify the vDos source code. There are a number of people in the DOSBox forum who know DOS internals very well and can probably write the needed modifications in a very short time. Some of them have been very helpful with questions I asked about DOSBox, and I know that some of them make their living writing code. This might be the best solution, especially if the people who ask you to maintain their programs are willing to pay for the needed modifications to vDos.
Thanks, Edward, for the suggestion. You can reach me at tbwright
'at' cantv 'dot' net, with any (more private) contact names.
Also I would like an e-mail address to drop off anything not appropriate for this Forum.
While using DEBUG on a minimum compiled program (with a READ and
a PAUSE and nothing else) I just found an embedded message
"DOS 2.0 or later required"; so any such compiled program needed
at least DOS 2.0 or above to work. Since this M.S. compiler is late
1985 issue, that sets the lowest conforming MSDOS version level for
ascii READ with auto-fixing cr/lf/cr-lf, and PAUSE release.
I didn't get this message; so vDos supplies a higher DOS release number.
I have the ASM code of the tiny object (and the executable) and the
object code shows that the service names not being emulated as needed
are NOT in the program, but in the compiler main library used by the linker.
The pause calls STPVQQ and the buffered READ calls GOFVQQ.
And yes, READ passes a 0001h as standard READ handle.
I'm still tracing 28K of 'tiny'code to find what M.S> actually does.
Last edit: Terence Wright 2015-07-08
I think the best thing is to post a message in the DOSBox Development forum at vogons.org. All the developers will see it; these are the people who know the most about DOS internals these days. I don't want to pass along anyone's private e-mail address without their permission.
(Edward, I suggested YOUR e-mail for any listings, data etc).
I finally was able to trace what happens in compiled M.S.
Fortran programs (1985 late version 3; V 4 had problems).
I used a tiny Fortran program and traced the execution.
The service called by the program turned out to be 3Fh of
Interrupt 21h (an alternative READ keyboard using Standard
Input Handle 0).
Interestingly it was ALSO called by the pause statement
I had the same trouble with in vDos (needs cr-lf as
separate characters to terminate).
Here is what is supposed to happen (Dave Williams again).
note 1) This function attempts to transfer the number of bytes specified in CX
to a buffer location. It is not guaranteed that all bytes will be read.
If AX < CX a partial record was read.
2) If performed from STDIN (file handle 0000), the input can be redirected
-->> 3) If used to read the keyboard, it will only read to the first CR
4) The file pointer is incremented to the last byte read.
And Yes, DS:DX pointed to where the data was put,
CX had the character string size, (I tried 1, gave 'A' cr-lf and found it).
BX contained 0000 (keyboard),
AX had 3F01h.
But vDos waited after the CR for (ONLY) a LF before completing.
It's not clear from your last post what you meant by "suggesting [my] e-mail." If it means that you posted my e-mail address in public (as you seem to imply), please go back immediately and remove it from your posting. Or at least tell where it is so that I can ask the board administrators to remove it. Thank you.
This is entirely your issue; please do not bring other people into it.
(And you might want to try a different keyboard before modifying any code; some keyboards send non-standard scan codes, especially older ones.)
Last edit: Edward Mendelson 2015-07-07
No, Edward. I DID NOT know (or publish anywhere) your e-mail
address. My note invited you to send ME an e-mail address TO MY
given address, that could be used by me to send anything of vDos
interest, but NOT appropriate on this Forum (size, technicality,
commercial problems), in order to help any future modifications.
It WOULD help, as others have noted, to be able to find a
published and updated list of Interrupt services emulated
by vDos, and with indications as what to extent, or caveats.
vDos responds to programs as being DOS 5. (Service 30h of INT 21h)
But there are still somewhat important differences.
But keep on the good work. It IS that!
Last edit: Terence Wright 2015-07-08
Thank you for clarifying this. I'm not an author of vDos. vDos is entirely the work of Jos Schaars; I merely use it for many purposes. There would be no point in sending me any code or anything else related to the program. Anything relevant to developing vDos may be posted in the forum (perhaps as an attachment; see the "Add attachments" link when creating or editing a message). vDos is indeed excellent work, but it's Jos Schaars' work, not mine!
I used debug myself on TESTR.exe to find what was happening and where.
Yes, I reported before that I have done this and showed some of the trace.
Something I noticed was that after the Interrupt 21h was 'executed', vDos took over the execution (naturally), but debug did not show that code ('obviously') so when text entry was made, it was not possible to see what Vdos did; only that after entering the single character requested, (say, 'A') a following RETURN key did nothing, and it takes precisely one return key followed by one ctl-return 'key', in that order, even if you input many of these two keys until just that order occurred, IN ORDER TO COMPLETE THE ENTRY AND FREE THE PROGRAM!
This ALSO happens on the PAUSE instruction the program demonstrates next.
Demo.exe will offer you to enter ABCDEF with or without typing errors and correcting, and show exactly what is echoed and what hex form the keystrokes have.
Then it will offer again until you abort vDos (click top right corner works).
This program will run under MSDOS and the command line of the MS emulator in any Windows up through W2000 and XP and 32-bit Windows 7; AND under vDos (either 32 or 64-bit Windows 7), but when under vDos, in order to get out of the program's cycle, you have to either click on the top-right X corner, or use ctl-alt-del to ask the task manger to quit the program. Ctl-c does NOT work here either.
Yes Jos has always said so, but I since I can detect the keystroke (a heart shape is echoed) I think there must be a way to jump to the clean-up exit and/or abort Vdos.
Secretaries and data-entry persons should NOT (nor allowed to) have to do that!
I ran under vDos, the Jos-suggested debug sample code :-
mov ah, 3f
mov bx, 0
mov cx,100
mov dx, 200
int 21
and the buffer stored the input (whatever I typed each time) plus a 0Dh code AND a 0Ah code: e.g. example followed by cr, then lf. The READ terminated with that ONE return key and stored TWO codes for it.
So what Jos/debug is doing in that code is asking for up to 100 characters input into address 200. And it DOES that. Note that it reads up to (the number in CX) characters plus a single return, stored as cr-lf.
THAT IS WHAT SHOULD HAPPEN!
Then I ran DEBUG again on my tiny TESTR program, but modified to read up to 4 characters and not one character, and traced that program in the same Interrupt 21H service 3Fh area.
as before. (Actually I have the full trace and let it stop when it wanted input).
Interesting!!
What Fortran compiles (see testrobj.txt below) asks for ONE read of the characters needed, exactly as above, but what I see emulated for the READ 4 character operation is a 4 times repeated call to get ONE character, because the same trace it repeated with CX=0001, four times, only changing DS and one or two other registers each time by one unit.
BUT IT WAITED FOR CR AND LF before proceeding!! Running under MS emulation under Windows 7, the programs runs and waits for ONLY the return key in both instances of needing one.
Is it possible in vDos, that the emulation takes the character count and repeats a read keyboard process 'count' times? And has its own 'termination' input sequence?
That's a guess and probably wrong, but I have to reconcile what I see in Debug-tracing of this code which runs as expected under connamd-line execution in 32-bit Windows 7.
I have a trace of all four character adquisitions and the single trace on picking up cr then lf, even if lf-cr-cr-cr-lf which finally works.
"3) I posted an e-mail address in order for Edward or Jos to suggest where
to ask about programming work. No response. Edward said why difficult."
"No response" is not correct. I suggested that you should post a message asking for help on the DOSBox forum at vogons.org. That is how I found help with DOSBox before vDos existed:
http://www.vogons.org/viewforum.php?f=53
I got help there by posting a message; that's why I suggested that you do the same. (I don't know what "why difficult" means, and I'm certain that I never said it. Also, to repeat, I am NOT an author of vDos, and can take none of the credit for it.)
Last edit: Edward Mendelson 2015-07-12