Page 1 of 1

System API methods

Posted: Tue Mar 23, 2004 4:27 pm
by mr. xsism
does win32 use interrupts to interface its API??

What other way would you interface a system API? Call gates can be used but you have to know the addresses of the functions which isnt always publicly known.

Re:System API methods

Posted: Tue Mar 23, 2004 4:56 pm
by Tim
mr. xsism wrote: does win32 use interrupts to interface its API??
Yes. Although Windows XP uses SYSCALL/SYSRET or SYSENTER/SYSEXIT where available.
What other way would you interface a system API? Call gates can be used but you have to know the addresses of the functions which isnt always publicly known.
No, call gates and interrupt gates work the same way: you either use CALL on a fixed selector and an arbitrary offset (the offset is ignored), or use INT on a fixed interrupt number.

Personally I think INT is sufficient for anything. Call gates are another bit of x86 weirdness which nobody uses in practice.

Re:System API methods

Posted: Tue Mar 23, 2004 6:00 pm
by Pype.Clicker
the main reason for Call Gates is that ints can only invoke DPL0 code ...

as noone seems to consider DPL1 and DPL2 to be of any use ...

Re:System API methods

Posted: Tue Mar 23, 2004 7:19 pm
by mr. xsism
ya that makes sense, i personally think that other rings are too much of a hassle and slow down to the system to bother with. Thanks guys. That's all i really needed to know.

Another question:
I am trying to implment plugins in Halfix. You might know what they are but in case not they are dynamically loaded modules for interfacing with hardware. Apps request to use them like DLLs but they need access to hardware.

Can i link(copy the code to share the apps space) them in as threads and give them ring3 but access to io ports via the TSS IO map??

I was looking over KMODs in clikcer and my standard is similar to KMODs. http://halfix.osdever.net/documents.php has some more info on the plugin standard although it is not complete yet.

Re:System API methods

Posted: Wed Mar 24, 2004 3:37 am
by Pype.Clicker
mr. xsism wrote: Can i link(copy the code to share the apps space) them in as threads and give them ring3 but access to io ports via the TSS IO map??
Theorically yes, though i never really tried it myself out of a VM86 task ... Note that other things that you might want to do in a hardware stuff (interrupts handling, remapping memory, etc.) will be discarded though ...
I was looking over KMODs in clikcer and my standard is similar to KMODs. http://halfix.osdever.net/documents.php has some more info on the plugin standard although it is not complete yet.
i'll have a look ;)

Re:System API methods

Posted: Wed Mar 24, 2004 3:25 pm
by mystran
The other rings don't make sense with modern multi-tasking, where every process has it's own address space. You can have different security domains just by giving different priviledges to different processes.

If you didn't have pre-emptive multi-tasking, ie. you only have one active process at a time, but still wanted to have a security model where you need to run code from several different security-levels, the rings (and intel TSS system) starts making sense. Now you have different "tasks" in different HW TSS's and they exist in one of the rings depending of the priviledges they need.

So the rings and TSS are useful for a system which acts like DOS but needs some more security. On the other hand, once you start doing time-sharing, the model no longer makes any sense. I'd say it's just a relic.

Re:System API methods

Posted: Wed Mar 24, 2004 4:31 pm
by Curufir
mystran wrote: So the rings and TSS are useful for a system which acts like DOS but needs some more security. On the other hand, once you start doing time-sharing, the model no longer makes any sense. I'd say it's just a relic.
Hmm, not sure if I agree. I think there's a definite case for using multiple rings, it just makes no sense whatsoever in a system that has a monolithic kernel (That includes monolithic kernels with loadable modules).

Re:System API methods

Posted: Thu Mar 25, 2004 3:10 am
by Pype.Clicker
it may make much sense too if you want to host several possible hostile threads in one process, under the control of a master thread ... Just imagine what a shell look like if LS, GREP, SED, etc. were such plugins :-p

The shell would be the master thread (DPL2) which would have the option of creating other threads (DPL3) for running plugin tools and the plugins could benefit from shared memory for pipelining etc. without stepping on each other's "private" parts...

(damn! i promised i would kept that sekret until released :-p)

Re:System API methods

Posted: Thu Mar 25, 2004 3:29 am
by Tim
Pype, I think the VMS developers beat you to it :).

(VMS has traditionally run across 4 rings on the VAX, and later the Alpha. IIRC the kernel is in ring 0, drivers are in ring 1, the shell is in ring 2, and applications and shell commands are in ring 3. Note that the shell is available to all applications.)

Re:System API methods

Posted: Thu Mar 25, 2004 4:04 am
by Pype.Clicker
Tim Robinson wrote: Pype, I think the VMS developers beat you to it :).
The worst you risk by releasing an idea is to learn that it is not new ;D

Re:System API methods

Posted: Thu Mar 25, 2004 10:50 am
by Therx
Pype.Clicker wrote: the main reason for Call Gates is that ints can only invoke DPL0 code ...
huh. I thought you could set the code segment selctor in the IDT entry to anything (i.e. a ring X segment)

Pete

Re:System API methods

Posted: Fri Mar 26, 2004 1:49 am
by Perica
..

Re:System API methods

Posted: Fri Mar 26, 2004 2:19 am
by Candy
Perica wrote: Do applications directly call the API interrupts? Or are there separate procedures contained in DLLs that do all the non-portable interaction with the system? - meaning, the application doesn't even need to know how to call the interrupt directly, it simply calls a procedure in a DLL that does all the work for it (the prodecure in the DLL calls the necessary interrupt, etc.) ? How does it work?
Microsoft only publishes the API, even internally (afaik), so all calls that are made are made through the API. That means, they are either in libraries you link statically or dynamically or they're macros. Two out of three options make your program not portable to a future version of windows.

Re:System API methods

Posted: Fri Mar 26, 2004 3:47 am
by Perica
..

Re:System API methods

Posted: Fri Mar 26, 2004 5:51 am
by Pype.Clicker
most of the time, you do not cope with the system call directly (only assembler programmers like to do so, as most of the time the parameters are passed through registers the HLL programmer can hardly access) but rather through "standard" libraries (be it world-wide standard or OS-specific standard) or something alike.