OSDev.org

Does each API set interface via interrupts? Like to open a new window in XP, do i just call a subfunction of an interrupt? Same with Linux/POSIX?

Know of any good VM86 tutorials/specs?

ty

Regards,
mr. xsism

mr. xsism wrote: Does each API set interface via interrupts?

Erm...

Neither POSIX nor Win32 API require you to call interrupts directly, for all that I know. You call functions, some of which might actually be stubs for interrupt calls, but you don't really care since those stubs just look & feel like any other function.

The API merely tells you how the functions are called and what they do. How they achieve their task is part of the OS implementation and its ABI.

i guess the confusion comes from MS-DOS days where the API *was* the API ... or almost (i.e. if you wished to open a file, you had to call INT21)

No, no, no. When you use API nowadays, you call functions. That's correct. But those functions usually end up calling on system API. This can be done 2 ways: Interrupts or call gates.

I am wanting to know if POSIX & Win32 uses interrupts or call gates. I am basically wondering how when you call API_function(a,b,c); it runs the API function.

I need to know for porting POSIX & win32 APIs to my OS.

Come to think of it, don't they both use shared libs/DLLs? Is that how they do it?

Thanks guys...

Regards,
mr. xsism

They just tell you what the function name is and what it does. How you implement it is up to you. The main thing is that the result returned after the user calls the function is correct and matches the format of the equivalent POSIX/WIN32 spec.

mr. xsism wrote: I am wanting to know if POSIX & Win32 uses interrupts or call gates. [...] I need to know for porting POSIX & win32 APIs to my OS.

POSIX and Win32 API don't call interrupts, or call gates. They merely define what functions there are and what they do, treating the functions as black boxes.

Whether to call interrupts or call gates is up to the OS, and not part of POSIX or Win32 API.

We could tell you what Linux does to implement the POSIX API, or what Windows does to implement the Win32 API, but you don't need to know. Just implement the API functions in whatever way you are comfortable with.

mr. xsism wrote: No, no, no. When you use API nowadays, you call functions. That's correct. But those functions usually end up calling on system API. This can be done 2 ways: Interrupts or call gates.

Note: THREE ways. Interrupts, call gates and SYSENTER/SYSEXIT. On amd you can replace sysenter/sysexit with syscall / sysret, which are faster (to type & execute).

It's just that no existing OS uses it even though it would be better for them to use them. They sport these conditions: Using flat memory model, single system entry point and (which I like best), it does not dump the EIP of the process (or anything) to the stack. So, it allows for easy use

Thanks guys. I found this
but are there any other specs on win32 API???

another question, how do you create a function, asm or C, that sets CS to specific value? I posted on alt.os.development too and am waiting for suggestions.

AND...
what does sysenter and sysexit do? I just saw them 5 mins before reading the replies too.

Regards,
mr. xsism

ApiGuide is a good winAPI reference. Its written for the application developers point of view but all you need is the function defs, data types, structures and constants anyway.

-Robert

Robert Lee wrote: ApiGuide is a good winAPI reference.

If you're talking about http://www.apiguide.com/, either it's just me or the site is limitted to "A" beginning functions, which makes it ... rather ... useless .

sysenter/sysexit:

on sysenter the system stores the current eip in ecx, loads the new eip / cs / esp from some MSR's and continues executing. Don't know what it does with the esp but it would probably store it somewhere (possibly swap with the MSR esp).

Sysexit restores the esp of the process, loads ecx into eip and loads the return segment from the msr.

Aside from this, which int / iret would also do, it skips
segment checks, which are not of much use to flat mode anyway. The segment is loaded with the given number visible (should be appropriate), and no matter what the selector contains, it is loaded with CPL=3, base=0x0, limit=0xFFFFFFFF.

Syscall/sysret take it a little further, and they don't modify esp. You just keep the stack, all that is changed is the eip move to ecx, eip loaded from STAR[31:0] (an AMD MSR), cs loaded with flat mode stuff and CPL0. Upon return, ecx is moved to eip, cs loaded with flat mode stuff and CPL3. Thinking about it like that it should be about 3-4 cycles to swap from user mode to kernel mode, at most. Fast user/kernel mode swaps are good for performance

and the good thing in having your API in a set of functions (loaded as a dynamic library, for instance), is that the implementation of these function may be different depending on the running process. So you could decide that process X has no need for segmentation and will run with the SYSCALL/ENTER/LEAVE/EXIT system calls while process Y needs improved security and makes use of segments for it, but its system call use legacy INTs.

apiguide looks good. SO MANY FUNCTIONS 8|

What is an MSR? I forget.

How do you set CS to a certain selector?
jmp 8:LABEL
^ obviously works, but i need something like:
jmp var_sel:LABEL
I need it for tasking. I heard something about pushing the value onto the stack. I think the stack contains the calling CS and you modify it so when it reutrns it changes it. I just need to know. Quick explaination would be awesome.

Regards,
mr. xsism

MSR stands for Machine Specific Register ...

And for your jump problem, you could use a "jmp far [address to a far pointer]" instruction. At this address will be located both the label *and* the selector for your code segment (or TSS or whatever).

i'm not sure whether the trick would work for a gate ... it does for a code segment.

For your problem you can use self-modificating code.
For this example it would look like This way var_sel is a variable and can for example be used in a C-Function. Of course it is also possible to manipulate the Offset this way but this is normaly not necessary.