Prev: misc idea: PE/COFF data embedding...
Next: IDE
From: Terence on 8 Mar 2010 01:28

I use high-level languages to run programs in Windows and DOS.
All need to get keystrokes from the keyboard one by one.
These are all key combinations except those used by Windows (e.g. ctl
and Alt- TAB and ESC ).

For DOS and Windows command line, I use the DOS service call Int 16h
with 16 or 17 in AH to get any key combination (else use 0 to get and
1 to test "standard" keys).
(For Fortran programs I use the similar APIs that perfom PEEKCHARQQ
and GETCHARQQ).

I too, now find myself asking a question on this topic after posting
replies to a similar related question.

My problem is that on the MAC, running DOS emulation (VMware fusion),
all "standard" keys return the two-byte key identifier xx00h for ALT
keys and kknn or kkE0 (kk=ascii key code, nn=key number, xx=alt code)
without pause, whereas the special combinations, from the exact, same
routine, take 4 to 5 seconds per stroke (which is intolerable). Also,
some keys never return any code (e.g.ctl down); and delete is actually
backspace and there no insert, nor the quad page up or page down, Home
or End, which I hope to emulate with alt-arrow.

So: can anyone suggest a "more correct" method of getting the two-byte
scan code for the ASM method?
I had thought of examining the buffer, but I suspect that is what
interrupt 16H actually does.


From: Rod Pemberton on 8 Mar 2010 06:39
"Terence" <tbwright(a)cantv.net> wrote in message
news:d93d10a8-511b-48d0-b288-de4081532834(a)s36g2000prh.googlegroups.com...
>

[re-ordered slighly]

>
> For DOS and Windows command line, I use the DOS service call Int 16h
> with 16 or 17 in AH to get any key combination (else use 0 to get and
> 1 to test "standard" keys).
> (For Fortran programs I use the similar APIs that perfom PEEKCHARQQ
> and GETCHARQQ).

Ok.

> My problem is that on the MAC, running DOS emulation (VMware fusion),

I know nothing about VMware fusion.

> all "standard" keys return the two-byte key identifier xx00h for ALT
> keys and kknn or kkE0 (kk=ascii key code, nn=key number, xx=alt code)
> without pause,

Sigh, I reread that five times. I couldn't figure out what you meant about
not having the "pause" key. But, you mean "without delay"... Sorry, it's
late for me.

> whereas the special combinations, from the exact, same
> routine, take 4 to 5 seconds per stroke (which is intolerable).

Did you complain to VMware about their _slow_ keyboard emulation?

> Also,
> some keys never return any code (e.g.ctl down); and delete is actually
> backspace and there no insert, nor the quad page up or page down, Home
> or End, which I hope to emulate with alt-arrow.

Did you complain to VMware about their _faulty_ keyboard emulation?

I'd guess that they didn't fully emulate the keyboard. Could it be possible
they only support an 83-key keyboard instead of 101-key? You might try
ctrl- or alt- with delete to see if backspace is available that way.

> So: can anyone suggest a "more correct" method of getting the two-byte
> scan code for the ASM method?

Nope. You're aware of the main BIOS routines.

> I had thought of examining the buffer, but I suspect that is what
> interrupt 16H actually does.

Yes, I believe so...

> I use high-level languages to run programs in Windows and DOS.
> All need to get keystrokes from the keyboard one by one.

DOS users used to use keyboard stuffer TSR's to enter automated keystrokes
into the keyboard buffer which the application would then use as if the user
typed it in. Or, perhaps you could code a Mac application that accepts
input from the keyboard in the Mac OS, and then stuffs the keyboard buffer
in the VMware session. E.g., Win98 allows you to paste text into a DOS
console from Windows. When the text is pasted, it is entered as if typed.
So, I'd think something similar *could* be possible with VMware. You'd
probably need to contact them for more info.


Rod Pemberton


From: Terence on 8 Mar 2010 19:41
On Mar 8, 10:39 pm, "Rod Pemberton" <do_not_h...(a)havenone.cmm> wrote:
> "Terence" <tbwri...(a)cantv.net> wrote in message
>
> news:d93d10a8-511b-48d0-b288-de4081532834(a)s36g2000prh.googlegroups.com...
>
>
>
> [re-ordered slighly]
>
>
>
> > For DOS and Windows command line, I use the DOS service call Int 16h
> > with 16 or 17 in AH to get any key combination (else use 0 to get and
> > 1 to test "standard" keys).
> > (For Fortran programs I use the similar APIs that perfom PEEKCHARQQ
> > and GETCHARQQ).
>
> Ok.
>
> > My problem is that on the MAC, running DOS emulation (VMware fusion),
>
> I know nothing about VMware fusion.
>
> > all "standard" keys return the two-byte key identifier xx00h for ALT
> > keys and kknn or kkE0 (kk=ascii key code, nn=key number, xx=alt code)
> > without pause,
>
> Sigh, I reread that five times.  I couldn't figure out what you meant about
> not having the "pause" key.  But, you mean "without delay"...  Sorry, it's
> late for me.
>
> > whereas the special combinations, from the exact, same
> > routine, take 4 to 5 seconds per stroke (which is intolerable).
>
> Did you complain to VMware about their _slow_ keyboard emulation?
>
> > Also,
> > some keys never return any code (e.g.ctl down); and delete is actually
> > backspace and there no insert, nor the quad page up or page down, Home
> > or End, which I hope to emulate with alt-arrow.
>
> Did you complain to VMware about their _faulty_ keyboard emulation?
>
> I'd guess that they didn't fully emulate the keyboard.  Could it be possible
> they only support an 83-key keyboard instead of 101-key?  You might try
> ctrl- or alt- with delete to see if backspace is available that way.
>
> > So: can anyone suggest a "more correct" method of getting the two-byte
> > scan code for the ASM method?
>
> Nope.  You're aware of the main BIOS routines.
>
> > I had thought of examining the buffer, but I suspect that is what
> > interrupt 16H actually does.
>
> Yes, I believe so...
>
> > I use high-level languages to run programs in Windows and DOS.
> > All need to get keystrokes from the keyboard one by one.
>
> DOS users used to use keyboard stuffer TSR's to enter automated keystrokes
> into the keyboard buffer which the application would then use as if the user
> typed it in.  Or, perhaps you could code a Mac application that accepts
> input from the keyboard in the Mac OS, and then stuffs the keyboard buffer
> in the VMware session.  E.g., Win98 allows you to paste text into a DOS
> console from Windows.  When the text is pasted, it is entered as if typed.
> So, I'd think something similar *could* be possible with VMware.  You'd
> probably need to contact them for more info.
>
> Rod Pemberton

Unfortunately, I couldn't find any way to contact VMware except by
phone to USA.
Obviously I'm running DOS or Windows, and the service call (or API) is
intercepted to simulate it.
I suspect that the extended 101-key keyboard interrupt is not being
handled properly and a time-out is occuring, followed by some
programmed intervention. I can't believe any running code would take 5
seconds.
That my code runs fine on DOS and Windows but has these delays in MAC
is not that much useful.
 | 
Pages: 1
Prev: misc idea: PE/COFF data embedding...
Next: IDE