Inline Assembly - Interupts & DPMI

[ctype]

Hi All,

Just a little query...

Does DPMI have anything to do with why I can't call DOS interrupts from inline assembly? I guess I have to be creating a 16bit DOS program? But MSVC doesn't do these, even if I compile a console application.

I even resorted to Turbo C, but that didn't work either. Same problem in Delphi. Any ideas?

[Eibro]

I had to look up DPMI but it doesn't seem relevant. Windows will not allow you direct access to hardware in user mode. Period.

[ctype]

Is there any way to get around it at all? It's a real pain in the ass.

What's Windows problem anyway? It's preventing us good ol' programmers from having fun. Programming completely in Assembly is fun if you've got nothing better to do for a few months - I'm learning A86 Assembly right now, only to grasp knowledge of how to utilise it Inline with C/C++ Code. Windows spoiling all my fun. Again.

Well, I'd rather stick hot needles in my eyes than program for Windows in pure assembly (I'd like to know how, though).

[Eibro]

Is there any way to get around it at all? It's a real pain in the ass.

What's Windows problem anyway? It's preventing us good ol' programmers from having fun. Programming completely in Assembly is fun if you've got nothing better to do for a few months - I'm learning A86 Assembly right now, only to grasp knowledge of how to utilise it Inline with C/C++ Code. Windows spoiling all my fun. Again.

Well, I'd rather stick hot needles in my eyes than program for Windows in pure assembly (I'd like to know how, though).

What, would you prefer that windows allow you direct access to hardware? That would mean one program (eg. yours) could/would bring down the whole system if it did something it shouldn't have. If you want direct access to hardware i'd go get an emulator like bochs and play around with it in emulated real mode.

[MyndFyre]

Eibro is perfectly correct here: directly accessing hardware can cause you to bring down the entire system (have you ever seen a poorly-written video driver, for example?).  In any case you can get the Windows Driver Development Kit and assemble to your heart's content.

Windows NT-based systems operate what is called the HAL, or Hardware Abstraction Layer.  It provides a multi-layered system of drivers by which the lowest-level of drivers provide higher-level functionality to the next level of drivers.  The lowest level might be a simple bus controller -- BUT, that driver might expose the same set of functions regardless of whether the bus was AGP, PCI, or ISA.  A driver might sit on top of that which controls the hard drives; it interacts with the PCI-to-ATA bridge only through the driver below it.  This way drivers become something reminiscint of "interchangeable parts," but it simplifies driver development for device manufacturers.