Re: IRQs and interrupt handlers under Win95

[mfb@mbunix.mitre.org (Michael F Brenner)]

Dale Keim wrote:
Dale > ... how to bind code to an IRQ ...

Markus > Which OS? 

Yes, unfortunately, the Ada language has not standardized on how to 
spell this accross DOS, Unix, Windows 9x, JBC, bard board systems, and other
interrupt-driven systems.

Markus > No user process can bind code to an IRQ under Unix or
       > Windows NT, irrespective of the programming language. This is
       > left for device drivers.
 
Yes. To re-phrase this more positively (without the word NO):

Some operating systems require certain priviledges to catch interrupts. 
In addition to spelling it correctly in Ada, you must take the code, 
thus spellt and give it the proper priviledges. This may include: declaring
it to be a device driver, giving it root priviledges,
granting it access to Ring 0 memory, placing it into protected
mode, hacking the kernel, enhancing it with subsidiary assembler code,
renaming it to mimic the name of a priviledged program,
modifying the address of the interrupt vector by poking bytes into memory,
having a copy of the interrupt vector in your memory space and
redirecting all interrupts through that copy, linking your Ada code
into the interrupt handler chain manually again using some kind of 
POKE technology, purchasing a commercial operating system 
enhancement to permit user programs to define interrupts, 
replacing some of the operating system libraries, and tickling
a bit in the hardward interrupt controller chip.

These things would have to be done no matter what computer programming
language you use, and Ada is no different in interfacing to those
operating systems. 

If you are attempting this using a DOS compiler that has the 
necessary subsidiary assembler code built in, like Alsys you are
in luck. If you are using gnat, you are still in luck because
you can use the techniques of the djgpp community. In NT
there do not appear to be any free tools available to either the
C, the Java, or the Ada communities at this time, and it might
require purchasing a development license from the manufacturer,
which would include the libraries needed to define device drivers.

It is really a shame that at this late stage in computing science 
that we still need interrupts to get control of the basic input
and output of our machines, particularly key strokes, mouse strokes,
RS232 strokes, etc. 

But it is a fact that the raw strokes are not available to user
programs in most newer operating systems.

Something as simple as which keys are currently being held down,
the true location of the mouse, or lighting up a pixel on the screen
are forbidden to the programer, glorifying mediocrity in the name
of security. The word security is deprecated by this philosophy
of hiding the raw input-outputs streams from the authorized users.

Security in its original meaning was to ENSURE access to the data
by the authorized users. Now security has come to mean the opposite:
preventing access by authorized users. This has confused many
issues and lowered the quality of many operating systems, greatly
increasing the price of programming computers. The increase
in price comes from the fact that you must purchase very
expensive tools, simply to by-pass the so-called security
restriction against seeing your own data.

The only thing bringing an reasonableness at all into the
management decisions preventing user access to this data
is the game-programming community which simply cannot make
games work fast enough without this access. 

When you post the operating system and compiler you are using,
we can point out to you what facilities are available to handle
interrupts with the tools that you have.