Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

Memory usage, AMIS(!) (Developers)

posted by bretjohn Homepage E-mail, Rio Rancho, NM, 15.05.2011, 17:26

I was simply going to stop responding to this thread, since it was proving fruitless. However, I can't let Ninho's comments simply pass for fear that someone might actually try to implement something based on what he says.

> You do realise int 15/4F handlers execute as part of an int 9/IRQ1 handler.
> Actually, one could in theory duplicate or replace almost the entire int 9
> functionality with an int 15 4F handler which would always return a clear
> carry flag to the BIOS - in effect leaving to the original BIOS only the
> actual in/out interactions with the interrupt and keyboard controllers.

This is not true. INT 15.4F is indeed called by the INT 09 handler, but that is not the only time it is called. It can be called by any program at any time. Because of this, an INT 15.4F handler is not allowed to actually "process" any keystrokes or make any system changes at all (put ASCII codes in the keyboard buffer, make changes to the BIOS Data Area, etc.).

E.g., Some of my "keyboard simulation" programs may call INT 15.4F in order to make sure they are simulating a valid scancode. I think I've also seen references to programs that simulate a Ctrl-Alt-Del through INT 15.4F in order to flush the caches of a disk caching program like SMARTDRV (more on this further down).

> Therefore there will always exist problems with programs that must bypass
> the BIOS altogether for part of their keyboard processing. Ordinary
> programs (i.e. not full keyboard handlers) which get scancodes by way of
> "in al,60h" whether polling or installing their own IRQ driver, should not,
> IMO, call int 15/4F. The latter should be called /only/ by a BIOS IRQ 1
> handler (or replacement thereof).

Not true, as stated above. INT 15.4F is allowed to be called by any program at any time. That is why it is a separate interface and not actually required to be part of the INT 9 handler.

Regarding your specific implementation, it has problems. I haven't look at all of the details, but your INT 15 handler is incorrect. There are programs that "monitor" keystrokes by trapping INT 15.4F. E.g., SMARTDRV monitors INT 15.4F for Ctrl-Alt-Del, and flushes its write caches when this occurs. Since your program does not chain to the old INT 15 handler, there is a potential for drive corruption during a reboot if the user installed a disk caching program (like SMARTDRV) before they installed your driver. You must chain to the old handler even if you are the one processing the INT 15 Request. Because you must chain, there is also the possibility that the user has installed more than one INT 15.4F handler (either inadvertently or on purpose), which you must handle correctly.

Your INT 15h handler should look something like this. Note that this is in A86 syntax, and is untested, so there might be errors/problems with it, but you will hopefully get the idea:


  PUSH AX              ;Save Original AX
  PUSH BP              ;Save used registers
  PUSH W SS:[BP+8]     ;Call the
  CALL [OldVector]     ;  Old INT 15h Vector
  PUSH BX              ;Save used registers
  PUSHF                ;Put return flags
  POP  BX              ;  in BX
  STI                  ;Enable interrupts
  CMP  B SS:[BP+3],4Fh ;Is this call for us?
  JNE >F80             ;If not, jump to handle it
  MOV  AX,SS:[BP+2]    ;AX = Original AX

  ;Process here, setting return CF (at SS:[BP+8]) and modifying AL as needed
 
  JMP >F90             ;Done
F80:                   ;Call was not for us
  MOV  SS:[BP+8],BX    ;Set return flags
F90:                   ;Done
  POP  BX              ;Set return BX
  POP  BP              ;Restore used registers
  ADD  SP,2            ;Skip over the original AX
  IRET

 

Complete thread:

Back to the forum
Board view  Mix view
22755 Postings in 2121 Threads, 402 registered users (2 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum