I'm just being nosy now... How do you call OS functions on Windoze?


Back in the days of the Commodore 64, the "operating system" (I use the 
term loosely) was stored in a big ROM chip. To call the OS (assuming you 
actually wished to do such a thing!) you simply jump to the right magic 
address. Since it's in ROM, it never moves. And indeed, you could buy 
big tables of addresses and the expected parameters...


In the days of the Amiga, things became a little more complex. The OS is 
composed of "libraries". Some of these are burned into ROM, while others 
reside in files on disk. But even the ones in ROM are in a slightly 
different place depending on exactly which model of Amiga you have.

All is not lost, however. Memory address 0x00000004 contains a base 
pointer to a "jump table". If you take this base address and add on what 
they call a "library vector offset" (LVO), you can access any function 
provided by the Exec library. And, again, for a large sum of money, you 
could buy a file containing either C or assembly declarations of all the 
function names and their corresponding LVOs.

The two important functions provided by Exec are of course OpenLibrary() 
and CloseLibrary(). The former takes a pointer to a zero-terminated 
string indicating the desired library name, and an integer indicating 
the minimum acceptable library version. On return, there's a status code 
indicating whether the library could be opened, and if so, what version 
was actually found, and a base pointer to its jump table. Now again you 
need to know the LVOs for the functions you want to call.

(If the library is on disk, Exec will load it for you. When you close 
it, Exec might unload it if nobody else is using it.)


How does this stuff work with Windoze? (Or Linux, for that matter...)

Post a reply to this message

Orchid XP v7 wrote:

> How does this stuff work with Windoze? (Or Linux, for that matter...)

Dynamic link libraries (DLLs) two ways to get to them, either through 
the linker, or through dynamic loading through calls to LoadLibrary and 
GetProcAddress. The easiest way is using the linker, of course, provided 
you have the header & library files (which you should for any windows 
compiler available). The DLL loader does all of the procedure address 
fix-ups, if a DLL is loaded into its preferred address space (i.e. no 
other DLL is occupying the address space it requests), then loading is 
much quicker since all of the pointers in the function table are 
correct. Alternatively, some functions, such as those in the DirectX and 
Shell libraries use COM, in which instances of classes are loaded with 
vtables pointed to the correct functions. DirectX (and Shell, I think) 
export non-COM functions for creation of the COM class instances.

* This is simplified and largely from memory, so take it for what its 
worth (not much). This is also the case for Win32, Win16 may be 
different, Win64 should be similar, though.

Post a reply to this message

Mike Raiford wrote:
> Orchid XP v7 wrote:
> 
>> How does this stuff work with Windoze? (Or Linux, for that matter...)
> 
> Dynamic link libraries (DLLs)

Oh, yeah... the answer only applies to Windows, Linux I haven't a clue.

Post a reply to this message

On Fri, 30 Nov 2007 14:41:47 -0600, Mike Raiford wrote:

> Mike Raiford wrote:
>> Orchid XP v7 wrote:
>> 
>>> How does this stuff work with Windoze? (Or Linux, for that matter...)
>> 
>> Dynamic link libraries (DLLs)
> 
> Oh, yeah... the answer only applies to Windows, Linux I haven't a clue.

On Linux it's similar; you have a set of standardized libraries that 
interface with lower level aspects of the kernel.  As I understand it, 
architecturally, you could call those kernel functions directly (and in 
fact in many cases you would do this, for example, to do thread 
management).

Jim

Post a reply to this message

Orchid XP v7 wrote:
> I'm just being nosy now... How do you call OS functions on Windoze?
> 
> 
> Back in the days of the Commodore 64, the "operating system" (I use the 
> term loosely) was stored in a big ROM chip. To call the OS (assuming you 
> actually wished to do such a thing!) you simply jump to the right magic 
> address. Since it's in ROM, it never moves. And indeed, you could buy 
> big tables of addresses and the expected parameters...

Commodore released a manual for the C64 that had EVERYTHING about the 
machine, including schematics.  It contained everything you needed to 
write any application.

> In the days of the Amiga, things became a little more complex. The OS is 
> composed of "libraries". Some of these are burned into ROM, while others 
> reside in files on disk. But even the ones in ROM are in a slightly 
> different place depending on exactly which model of Amiga you have.
> 
> All is not lost, however. Memory address 0x00000004 contains a base 
> pointer to a "jump table". If you take this base address and add on what 
> they call a "library vector offset" (LVO), you can access any function 
> provided by the Exec library. And, again, for a large sum of money, you 
> could buy a file containing either C or assembly declarations of all the 
> function names and their corresponding LVOs.

Addison-Wesley released a very extensive set of docs for the Amiga, 
consisting of five volumes.  One concerned programming at the hardware 
level, another dealt with the Exec library, a third with the Intuition 
library, and the last with all of the others (Graphics, Layers, Sound, 
etc.).  I'm pretty sure the vector table offsets for every OS call were 
in these books.

> The two important functions provided by Exec are of course OpenLibrary() 
> and CloseLibrary(). The former takes a pointer to a zero-terminated 
> string indicating the desired library name, and an integer indicating 
> the minimum acceptable library version. On return, there's a status code 
> indicating whether the library could be opened, and if so, what version 
> was actually found, and a base pointer to its jump table. Now again you 
> need to know the LVOs for the functions you want to call.
> 
> (If the library is on disk, Exec will load it for you. When you close 
> it, Exec might unload it if nobody else is using it.)
> 
> 
> How does this stuff work with Windoze? (Or Linux, for that matter...)

For Windows, I think that the library code is mostly in DLLs, and that 
your linker will add the appropriate OS calls to get any needed DLLs 
into memory.

Dunno how it works in Linux.

Regards,
John

Post a reply to this message

Le 30.11.2007 20:59, Orchid XP v7 nous fit lire :

> (If the library is on disk, Exec will load it for you. When you close
> it, Exec might unload it if nobody else is using it.)
> 
> 
> How does this stuff work with Windoze? (Or Linux, for that matter...)

Shared lib on linux/unix can be dynamically loaded too.
The classical libdl (dlopen,dlsym,dlclose) can be used on linux &
solaris.
hp-ux have shl_load...


-- 
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius

Post a reply to this message

Orchid XP v7 wrote:
> How does this stuff work with Windoze? (Or Linux, for that matter...)

The simple way for Linux, include the header file and tell the linker
the path to object files. In fact, that should work for Windows as well.

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> How does this stuff work with Windoze?

  When you have your compiler installed, you download the Windows SDK
which contains the necessary header files. Then you call the functions
defined in these header files.

> (Or Linux, for that matter...)

  Most system-specific headers are defined in /usr/include/sys, although
these are seldom needed in practice (ie. only when you really need to do
something which you can't do with standard code).

-- 
                                                          - Warp

Post a reply to this message

"Orchid XP v7" <voi### [at] devnull> wrote

> provided by the Exec library. And, again, for a large sum of money, you
> could buy a file containing either C or assembly declarations of all the
> function names and their corresponding LVOs.
> [...]
> How does this stuff work with Windoze? (Or Linux, for that matter...)

For starters, you don't pay large sums of money. No wonder Amiga is dead.

Post a reply to this message

somebody wrote:
> "Orchid XP v7" <voi### [at] devnull> wrote
> 
>> provided by the Exec library. And, again, for a large sum of money, you
>> could buy a file containing either C or assembly declarations of all the
>> function names and their corresponding LVOs.
>> [...]
>> How does this stuff work with Windoze? (Or Linux, for that matter...)
> 
> For starters, you don't pay large sums of money. No wonder Amiga is dead.

This was in the days before the Internet revolution. Towards the end, it 
was possible to get hold of the include files from BBS and so on. (I 
think even one issue of AmigaFormat had it on a coverdisk...)

Post a reply to this message

Warp wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
>> How does this stuff work with Windoze?
> 
>   When you have your compiler installed, you download the Windows SDK
> which contains the necessary header files. Then you call the functions
> defined in these header files.

Fair enough, but how exactly does it work under the covers? As in, how 
does it ultimately find the address of the code you want to call?

(I'm sure in the normal course of events you'll never need to know or 
care about this stuff. I'm just curios...)

Post a reply to this message

John VanSickle nous apporta ses lumieres en ce 2007/11/30 16:35:
> Orchid XP v7 wrote:
>> I'm just being nosy now... How do you call OS functions on Windoze?
>>
>>
>> Back in the days of the Commodore 64, the "operating system" (I use 
>> the term loosely) was stored in a big ROM chip. To call the OS 
>> (assuming you actually wished to do such a thing!) you simply jump to 
>> the right magic address. Since it's in ROM, it never moves. And 
>> indeed, you could buy big tables of addresses and the expected 
>> parameters...
> 
> Commodore released a manual for the C64 that had EVERYTHING about the 
> machine, including schematics.  It contained everything you needed to 
> write any application.
> 
Apple did the same with the Apple ][. In fact, one of the included manuals 
included the source code of the ROM and the scematics. Still have them.
There where also several third party sources for much of what's in the Applesoft 
basic ROM.


-- 
Alain
-------------------------------------------------
A true friend is someone who reaches for your hand and touches your heart.

Post a reply to this message

Orchid XP v7 wrote:
> Warp wrote:
>> Orchid XP v7 <voi### [at] devnull> wrote:
>>> How does this stuff work with Windoze?
>>
>>   When you have your compiler installed, you download the Windows SDK
>> which contains the necessary header files. Then you call the functions
>> defined in these header files.
> 
> Fair enough, but how exactly does it work under the covers? As in, how
> does it ultimately find the address of the code you want to call?
> 
> (I'm sure in the normal course of events you'll never need to know or
> care about this stuff. I'm just curios...)

The compiler recognizes that you are calling functions that aren't being
directly compiled into the code, and leaves dummy values in the Jump
instructions. During the linking or loading phase, those values are
replaced by addresses in memory.

At a lower level, the object files/DLL have a table that instructs the
linker/loader as to how far into that file a certain function is. When
that gets loaded into memory, in the case of a DLL at run time, the
linker/loader can take that memory location and basically do a search
and replace.

There is another level of misdirection, in that most of the time the
library is loaded into the user processes' virtual memory. This means
the address isn't really the actual location of the library in RAM, but
that is more a hardware level thing.

Post a reply to this message

Orchid XP v7 <voi### [at] devnull> wrote:
> Fair enough, but how exactly does it work under the covers? As in, how 
> does it ultimately find the address of the code you want to call?

  AFAIK the system libraries perform kernel calls (in both Windows and
Linux). Basically the kernel knows the library and accepts its calls
(while it's not possible to do it directly from user code). A kernel
function call is probably little more than a 'call' machine code to
a certain address in the kernel space. A 'call' machine code is more or
less equivalent to 'gosub' in BASIC. (The CPU can be instructed to allow
or disallow such calls depending on what code is attempting to do it.)

-- 
                                                          - Warp

Post a reply to this message

John VanSickle wrote:
> Addison-Wesley released a very extensive set of docs for the Amiga, 
> consisting of five volumes.  

Yup. Or any Amiga compiler came with it. Considering I owned both the 
books and a couple of compilers in college, I don't think it was *that* 
much money.  $99 for a C compiler, if I recall. I think I still have the 
books somewhere.

>> How does this stuff work with Windoze? (Or Linux, for that matter...)
> 
> For Windows, I think that the library code is mostly in DLLs, and that 
> your linker will add the appropriate OS calls to get any needed DLLs 
> into memory.

Yep. That's what user.dll, graphics.dll, stuff like that are.

At the lowest lowest level, I'm pretty sure the libraries load up 
arguments into registers and execute an INT instruction, which is a 
"software interrupt", aka a trap, which causes a branch to an address 
loaded into a specific area of memory. I.e., just like handling an 
interrupt, or just like branching to a jump table in a library, except 
that you get privilege bits flipped around.

I don't know of any modern multiuser OS that doesn't use that technique 
to get into the kernel, as it's pretty much the only way to bypass 
memory and execution permissions in a controlled way.

-- 
   Darren New / San Diego, CA, USA (PST)
     It's not feature creep if you put it
     at the end and adjust the release date.

Post a reply to this message

Warp wrote:
> Orchid XP v7 <voi### [at] devnull> wrote:
>> Fair enough, but how exactly does it work under the covers? As in, how 
>> does it ultimately find the address of the code you want to call?
> 
>   AFAIK the system libraries perform kernel calls (in both Windows and
> Linux). Basically the kernel knows the library and accepts its calls
> (while it's not possible to do it directly from user code). A kernel
> function call is probably little more than a 'call' machine code to
> a certain address in the kernel space. 

That's called a "call gate". Not many CPUs use that any more, especially 
those with memory mapping and VM handling.

Wikipedia is your friend: http://en.wikipedia.org/wiki/System_call

(BTW, this is why C isn't particularly better than any other language 
for this stuff. There's no way to specify something like "load register 
EAX with 0x80 and then do a system interrupt call.)

BTW, even CP/M on the 8080 and DOS on the 8086 used interrupt calls to 
dispatch to the OS, even tho there were no privilege reasons to do so.

If you're not familiar with how modern systems do interrupts and 
privileges and such at the assember/hardware level, it's hard to go into 
too much detail. If you *are* familiar, then it should be pretty 
obvious. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     It's not feature creep if you put it
     at the end and adjust the release date.

Post a reply to this message

On Sat, 01 Dec 2007 11:39:20 +0000, Orchid XP v7 wrote:

> Fair enough, but how exactly does it work under the covers? As in, how
> does it ultimately find the address of the code you want to call?

A lookup table of some sort.

Jim

Post a reply to this message

On Sat, 01 Dec 2007 10:08:03 -0800, Darren New wrote:

> (BTW, this is why C isn't particularly better than any other language
> for this stuff. There's no way to specify something like "load register
> EAX with 0x80 and then do a system interrupt call.)

I don't know about GCC, but I know in BorlandC and TurboC, you could do 
inline assembler - I used to use that functionality a lot back in the 
dark ages...

Jim

Post a reply to this message

Jim Henderson wrote:
> I don't know about GCC, but I know in BorlandC and TurboC, you could do 
> inline assembler - I used to use that functionality a lot back in the 
> dark ages...

Yup. Note that inline assembler isn't C. :-)   I was thinking more of 
Ada, which actually has language constructs for hooking and invoking 
interrupts, for example. You can declare a procedure as one that gets 
executed by an interrupt at a certain priority, and where it gets its 
arguments from, and so on.

-- 
   Darren New / San Diego, CA, USA (PST)
     It's not feature creep if you put it
     at the end and adjust the release date.

Post a reply to this message

On Sat, 01 Dec 2007 13:36:42 -0800, Darren New wrote:

> Yup. Note that inline assembler isn't C.

Well, true. :-)

But it wouldn't be hard to write a function that does the low-level 
stuff, either, I don't think - just a question of linking to a library 
with an appropriate function.

Jim

Post a reply to this message

Jim Henderson wrote:
> But it wouldn't be hard to write a function that does the low-level 
> stuff, either, 

Unless you're going to do something like write into a char[], then cast 
the char[] to a function pointer, I'm pretty sure you can't invoke 
arbitrary machine code from C. :-) *Somewhere* there's assembler.

-- 
   Darren New / San Diego, CA, USA (PST)
     It's not feature creep if you put it
     at the end and adjust the release date.

Post a reply to this message

On Sat, 01 Dec 2007 19:09:21 -0800, Darren New wrote:

> Jim Henderson wrote:
>> But it wouldn't be hard to write a function that does the low-level
>> stuff, either,
> 
> Unless you're going to do something like write into a char[], then cast
> the char[] to a function pointer, I'm pretty sure you can't invoke
> arbitrary machine code from C. :-) *Somewhere* there's assembler.

I'd think that'd be true for pretty much any language, though - even Ada.

But I was thinking along the lines of what you said.

Jim

Post a reply to this message

Jim Henderson wrote:
> I'd think that'd be true for pretty much any language, though - even Ada.

Actually, no. It has an explicit construct for catching interrupts by 
invoking a routine. (The routine would be in what Java calls a 
synchronized class.)  You specify the priority of the interrupt, and 
which interrupt it is, and all that.  I am not sure you can actually say 
what registers wind up in which arguments within the language, granted. :-)

> But I was thinking along the lines of what you said.

Yeah, but that's still not actually C. That just happens to be knowing 
what your particular C compiler outputs for a program that has no 
semantics in C. It's really not C any more than inline assembler is. :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     It's not feature creep if you put it
     at the end and adjust the release date.

Post a reply to this message

On Sun, 02 Dec 2007 12:07:50 -0800, Darren New wrote:

> Jim Henderson wrote:
>> I'd think that'd be true for pretty much any language, though - even
>> Ada.
> 
> Actually, no. It has an explicit construct for catching interrupts by
> invoking a routine. (The routine would be in what Java calls a
> synchronized class.)  You specify the priority of the interrupt, and
> which interrupt it is, and all that.  I am not sure you can actually say
> what registers wind up in which arguments within the language, granted.
> :-)

See, to me, that's not much different than a function call - just a very 
directly implemented function call. :-)

But probably closer to invoking, say, INT21 than you would do from C 
using inline - though the generated code by the compiler would probably 
be very close.

>> But I was thinking along the lines of what you said.
> 
> Yeah, but that's still not actually C. That just happens to be knowing
> what your particular C compiler outputs for a program that has no
> semantics in C. It's really not C any more than inline assembler is. :-)

True; but I'm guessing you're talking at a level in the language/compiler 
that I'm much less familiar with - in the end, you end up with machine 
code no matter what you do, since that's all the machine actually 
understands.

Jim

Post a reply to this message

Jim Henderson wrote:
> See, to me, that's not much different than a function call - just a very 
> directly implemented function call. :-)

Well, yah, except you say "invoke this function when you get that 
interrupt", and you don't set up the interrupt table yourself, and you 
don't have to deal with turning interrupts on and off, generating 
special return instructions, managing the priorities, etc.

Kind of the difference between having threading or dynamic loading in a 
language, and invoking an OS-specific library for it. Functionally 
pretty similar, except you only have to learn it once and it generally 
works out better/easier to use.

> But probably closer to invoking, say, INT21 than you would do from C 
> using inline - though the generated code by the compiler would probably 
> be very close.

I'm talking about handling interrupts, like in the kernel or a device 
driver, rather than generating interrupts. If that's the confusion... :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     It's not feature creep if you put it
     at the end and adjust the release date.

Post a reply to this message

On Sun, 02 Dec 2007 12:53:54 -0800, Darren New wrote:

> Jim Henderson wrote:
>> See, to me, that's not much different than a function call - just a
>> very directly implemented function call. :-)
> 
> Well, yah, except you say "invoke this function when you get that
> interrupt", and you don't set up the interrupt table yourself, and you
> don't have to deal with turning interrupts on and off, generating
> special return instructions, managing the priorities, etc.
> 
> Kind of the difference between having threading or dynamic loading in a
> language, and invoking an OS-specific library for it. Functionally
> pretty similar, except you only have to learn it once and it generally
> works out better/easier to use.
> 
>> But probably closer to invoking, say, INT21 than you would do from C
>> using inline - though the generated code by the compiler would probably
>> be very close.
> 
> I'm talking about handling interrupts, like in the kernel or a device
> driver, rather than generating interrupts. If that's the confusion...
> :-)

Ahhhh, I was thinking you/we were talking about calling interrupts - 
chaining interrupts is definitely something different.  I think back in 
the early 90's I wrote an interrupt chain in C, and you're right, it 
wasn't very straighforward.  I'd have to pull out a couple of my old 
books on interrupt programming to remember how I did it.

I know I did do it, though, because there were some undocumented DOS 
interrupts that I used for doing various tricky things in NetWare login 
scripts in the 3.x days - things like changing the master DOS environment 
table from within a DOS login script; I'm fairly sure I didn't write them 
in assembler, but it has been 20+ years since I did that, so maybe I did 
do that.

Jim

Post a reply to this message

Jim Henderson wrote:
> Ahhhh, I was thinking you/we were talking about calling interrupts - 

Now you got me curious, and I pulled down my Ada textbook.

Turns out the interrupt procedures don't have arguments (other than, of 
course, knowing which interrupt it was). I suppose that makes sense at a 
machine level, except for the software interrupts.

You can have declarations like
   for X'address use A;
to make X get allocated at the address represented by A. Works for code 
or data, meaning you don't have to do anything funky to put code in a 
particular ROM address, for example.

You can, of course, say
   for X'address use Y'address;
to alias X and Y together, if they are, say, different types for the 
same hardware or something.

(Note: X'Y is the syntax for accessing compile-time property Y of object 
X, so in Ada, it would be something like X'size instead of sizeof(x))

There's also decomposed addresses, letting you extract the segment and 
offset from a segmented address.

There's also Atomic and Volatile declarations (with the obvious 
semantics), the 'alignment attribute, the 'bit_order attribute (to 
control the order of allocations that C would use for bitfields in 
structs), the 'storage_size expression that lets you overallocate 
storage for an object (so you can, for example, allocate one block of 
flash to a particular set of routines or data).

You can set the dispatch policies (like whether tasks are FIFO within 
the priorities, or whether they run to completion, or whatever), and 
(hey Warp) the 'Immediate_Reclamation attribute, which means storage for 
a declared object is reclaimed as soon as the object ceases to exist. ;-)

Given all that, it still can be a pretty annoying language to use.

> I'm fairly sure I didn't write them 
> in assembler, but it has been 20+ years since I did that, so maybe I did 
> do that.

I'm guessing you did the same sort of thing that old BASIC programs did, 
which was machine code in DATA statements poked into memory and then 
executed.  If your compiler translates integers to addresses in a 
straightforward way, it would be pretty easy to do that in C.

-- 
   Darren New / San Diego, CA, USA (PST)
     It's not feature creep if you put it
     at the end and adjust the release date.

Post a reply to this message

Darren New wrote:

> At the lowest lowest level, I'm pretty sure the libraries load up 
> arguments into registers and execute an INT instruction, which is a 
> "software interrupt", aka a trap, which causes a branch to an address 
> loaded into a specific area of memory. I.e., just like handling an 
> interrupt, or just like branching to a jump table in a library, except 
> that you get privilege bits flipped around.
> 
> I don't know of any modern multiuser OS that doesn't use that technique 
> to get into the kernel, as it's pretty much the only way to bypass 
> memory and execution permissions in a controlled way.

OK, that's what I wanted to know...

(PS. Is there more than one interrupt level available? Or does it decide 
which routine to call based on some other parameter?)

Post a reply to this message

Invisible nous apporta ses lumieres en ce 2007/12/03 04:46:
> Darren New wrote:
> 
>> At the lowest lowest level, I'm pretty sure the libraries load up 
>> arguments into registers and execute an INT instruction, which is a 
>> "software interrupt", aka a trap, which causes a branch to an address 
>> loaded into a specific area of memory. I.e., just like handling an 
>> interrupt, or just like branching to a jump table in a library, except 
>> that you get privilege bits flipped around.
>>
>> I don't know of any modern multiuser OS that doesn't use that 
>> technique to get into the kernel, as it's pretty much the only way to 
>> bypass memory and execution permissions in a controlled way.
> 
> OK, that's what I wanted to know...
> 
> (PS. Is there more than one interrupt level available? Or does it decide 
> which routine to call based on some other parameter?)
If my memory is good. On the 8086, there where about 256 programable software 
interupts available to programmers. Interupts 0 to 15 are special periferals 
interupts. There where also some hardware interupts, but I don't know how many. 
The "Reset" switch triggers one of them.

-- 
Alain
-------------------------------------------------
   I'm so ugly I stuck my head out the window and got arrested for Mooning.
   	Rodney Dangerfield

Post a reply to this message

On Sun, 02 Dec 2007 17:16:49 -0800, Darren New wrote:

> Jim Henderson wrote:
>> Ahhhh, I was thinking you/we were talking about calling interrupts -
> 
> Now you got me curious, and I pulled down my Ada textbook.

[...]

> Given all that, it still can be a pretty annoying language to use.

Yep, on that point we agree. :-)  I did always think the exception 
handling being able to handle things at the hardware interrupt level was 
cool in Ada.  Just not cool enough to justify the memory usage of 
machines 20 years ago (which is nearly when I learned it, doesn't seem 
possible it was almost that long ago).

>> I'm fairly sure I didn't write them
>> in assembler, but it has been 20+ years since I did that, so maybe I
>> did do that.
> 
> I'm guessing you did the same sort of thing that old BASIC programs did,
> which was machine code in DATA statements poked into memory and then
> executed.  If your compiler translates integers to addresses in a
> straightforward way, it would be pretty easy to do that in C.

Very likely that is what I did.  Either that or I did inline assembly 
since my compiler supported that option.  I used information/techniques 
from the books Undocumented DOS (1e) and the Abacus book on DOS 
programming.  Still have both of those on the bookshelf at home.

Jim

Post a reply to this message

Invisible wrote:
> OK, that's what I wanted to know...

I have learned I have a knack for figuring out what technical question 
someone is *really* asking. I wish I knew why, so I could teach others 
to do it.

> (PS. Is there more than one interrupt level available? Or does it decide 
> which routine to call based on some other parameter?)

It depends on the CPU. Often there are multiple software interrupts 
available, but most OSes only use one, with a parameter passed in a 
register to indicate which one. Under MS-DOS, for example, it
was INT 21 (hex 21) to call DOS. The BIOS had a different interrupt 
(13?) for disks, and maybe one for the other stuff like video and all.

Learning how basic CPU stuff works is often very useful. Like, 
understanding that interrupts are nothing but polling the interrupt 
hardware wire at the start of each instruction can make you go "Oh! I 
see!" :-)

-- 
   Darren New / San Diego, CA, USA (PST)
     It's not feature creep if you put it
     at the end and adjust the release date.

Post a reply to this message