IRQs and interrupt handlers under Win95

IRQs and interrupt handlers under Win95

[Dale Keim]

I have just started using GNAT Ada and have been unable to determine how to
bind code to an IRQ. I would appreciate it if someone could send me a code
fragment that shows how this is done.

Thanks in advance

Re: IRQs and interrupt handlers under Win95

[Markus Kuhn]

Dale Keim wrote:
> 
> I have just started using GNAT Ada and have been unable to determine how to
> bind code to an IRQ. I would appreciate it if someone could send me a code
> fragment that shows how this is done.

Which OS? 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.

Markus

-- 
Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK
email: mkuhn at acm.org,  home page: <http://www.cl.cam.ac.uk/~mgk25/>

The nature of operating systems - was: IRQs and interrupt handlers

[Larry Kilgallen]

In article <6k1rq4$58t@top.mitre.org>, mfb@mbunix.mitre.org (Michael F Brenner) writes:

> 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.

That view seems particularly tied to the notion of a single-user
computer.  I certainly would not want _you_ to have access to the
bare metal on a machine where my process was running.  (But of
course, you should be willing to tolerate _me_ having such access.:-)

There are several software products (I hesitate to call them
operating systems) available for single-user computers, but when
you start paying for multiprocessing operating systems you find
the market is driven by those who want to minimize the chance
of users interfering with one another.

And yes, if you just want "character-at-a-time-as-soon-as-possible"
you _do_ have the potential to interfere with other users via timing.
Operating systems arbitrate the degree to which such interference is
tolerated, and ideally allow the system manager to vary the degree
to which it is tolerated.

Larry Kilgallen

Re: IRQs and interrupt handlers under Win95

[Robert Dewar]

Michael said

<<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.
>>

Yes, well I am sure there are people who think it is a shame that we
are still not programming in absolute, but the fact is that a modern
operating system is in the business of controlling the sharing of
resources, and you can't let people just blunder in and seize control
of "the basic input and output of our machines". When cars first appeared,
it must have seemed wonderful to be able to go wherever you wanted, and
no doubt people felt it was "really a shame" when traffic cops appeared :-)

<<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.
>>

Nothing unfortunate about this at all, any attempt to standardize this 
would be doomed to failure because of substantial differences at the hardware
level in the way interrupt systems behave (even if you stay within the PC
family, and your suggestion above seems to want to wander outside those
constraints)

Re: IRQs and interrupt handlers under Win95

[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.

Re: IRQs and interrupt handlers under Win95

[Robert Dewar]

Michael said

<<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.
>>

Michael, look at the subject line, perhaps you can figure out the operating
system from looking at it! (I know you saw it, since I just replied to your
message, and this is the subject line *you* used).

Actually to be fair, it is easy to miss critical information in the
subject header. It is good advice to ALWAYS repeat all important 
information in the body of the message.

Re: IRQs and interrupt handlers

[Chris Sparks (aka Mr. Ada)]

Since I work with Dale I have a better understanding of what he wants to do.
He feels that since Windows95 is a single user system, he should be able to
write ISRs.  He has a specific need with a card he is using and needs to be
able to write an ISR for it.  As it is, he will resort to using "C" tools that will
enable him to set up the handlers for his board's interrupt.  It is a shame
that he couldn't do this with GNAT.

Chris Sparks

Re: IRQs and interrupt handlers

[Larry Kilgallen]

In article <3565976A.D1B53EA9@catalina-inter.net>, "Chris Sparks (aka Mr. Ada)" <mrada@catalina-inter.net> writes:
> Since I work with Dale I have a better understanding of what he wants to do.
> He feels that since Windows95 is a single user system, he should be able to
> write ISRs.  He has a specific need with a card he is using and needs to be
> able to write an ISR for it.  As it is, he will resort to using "C" tools that will
> enable him to set up the handlers for his board's interrupt.  It is a shame
> that he couldn't do this with GNAT.

I always wanted VAX Bliss to add a WFIKPCH linkage so I could write
device drivers fully in Bliss.  The obvious response was that there
was insufficient market demand, and that is for a language where the
entire user base was on the same operating system.

To suggest similar special handling for Windows 95 while Microsoft
predicts the merger of Windows 95 (particularly the IO portions)
into Windows NT seems to have equal lack of commercial appeal.

Larry Kilgallen

Re: IRQs and interrupt handlers

[Jerry van Dijk]

Chris Sparks (aka Mr. Ada) (mrada@catalina-inter.net) wrote:

: He feels that since Windows95 is a single user system, he should be able to
: write ISRs.

I'm not sure what the one has to do with the other... or with his feelings :-)

:   He has a specific need with a card he is using and needs to be
: able to write an ISR for it.

He might have this specific need, but he still will not be able to do
so since there is no such thing as an ISR in a WinXX environment.

The only way will be to write a device driver. Personally I feel <g> that
ISR's are a poor excuse for a proper device driver. 

: As it is, he will resort to using "C" tools that will
: enable him to set up the handlers for his board's interrupt.  It is a shame
: that he couldn't do this with GNAT.

Well, I am most curious which C tools he is using. If it can be done in C,
it can be done in Ada too.

Jerry.

-- 
-- Jerry van Dijk  | email: jdijk@acm.org
-- Leiden, Holland | member Team-Ada

Re: IRQs and interrupt handlers

[falis]

> : As it is, he will resort to using "C" tools that will
> : enable him to set up the handlers for his board's interrupt.  It is a shame
> : that he couldn't do this with GNAT.
> 
> Well, I am most curious which C tools he is using. If it can be done in C,
> it can be done in Ada too.
> 
> Jerry.
> 
> -- 
> -- Jerry van Dijk  | email: jdijk@acm.org
> -- Leiden, Holland | member Team-Ada

But a more interesting question is whether it can be done safely and reliably in the presence of DPMI.  He'll need to lock his isr and anything it calls into memory.

- Ed Falis

Re: IRQs and interrupt handlers

[Tom Moran]

Why can't he make an ISR with Gnat?  Is it missing machine operations?
Can't he link to MASM code?  I have an old DOS program that does its
own com port interrupts that runs in a DOS box under Win95 (much of
the time).  Reliability and interrupt latency of course may be a
problem...

Re: IRQs and interrupt handlers

[Robert Dewar]

Chris says

<<Since I work with Dale I have a better understanding of what he wants to do.
He feels that since Windows95 is a single user system, he should be able to
write ISRs.  He has a specific need with a card he is using and needs to be
able to write an ISR for it.  As it is, he will resort to using "C" tools that w
ill
enable him to set up the handlers for his board's interrupt.  It is a shame
that he couldn't do this with GNAT.
>>

This is nothing to do with GNAT. Anything that can be done in this regard
can most certainly be done using GNAT, since this is not a language
dependent issue at all. Some glue code may be needed at some level, in
writing the necessary device drivers, which could for example be done
with package Machine_Code, or alternatively this may well be a case in
which a mixed Ada-C approach would make sense.

Certainly there is no feature that needs adding to GNAT to support this!
I would certainly be opposed to adding some Win-95 specific rubbish to
Ada or GNAT. We will let Mr. Gates do that if he ever feels that universal
use of Ada is threatening the ability of Microsoft to lock out non-MS
users :-)

Re: IRQs and interrupt handlers

[Jerry van Dijk]

Tom Moran (tmoran@bix.com) wrote:

: Why can't he make an ISR with Gnat?  Is it missing machine operations?
: Can't he link to MASM code?  I have an old DOS program that does its
: own com port interrupts that runs in a DOS box under Win95 (much of
: the time).  Reliability and interrupt latency of course may be a
: problem...

Yes, but you are talking _DOS_ code now, running under WinXX, not
Windows code.

Reliability is always an issue in such cases, since it will require
both a 32-bit protected mode _and_ a 16-bit real mode handler to
circumvent the interrupt deflection problem.

Jerry.

-- 
-- Jerry van Dijk  | email: jdijk@acm.org
-- Leiden, Holland | member Team-Ada

Re: IRQs and interrupt handlers

[Jerry van Dijk]

falis@ma.aonix.com wrote:

: But a more interesting question is whether it can be done safely and reliably in the presence of DPMI.  He'll need to lock his isr and anything it calls into memory.

This is assuming _DOS_ code. There is no DPMI in windows code. 

Jerry.

-- 
-- Jerry van Dijk  | email: jdijk@acm.org
-- Leiden, Holland | member Team-Ada