Re: Just to know: system calls on windows...

João Jerónimo wrote:
If I want to do ASM programming in Linux, I just have to use it's form of the POSIX standard (passing the system calls to the kernel in the registers)... (not consedering the C library)

You're surely confused. POSIX and the kernel are on separate levels. Calling POSIX functions has nothing to do with the kernel, and vice versa.

Those POSIX functions will ultimately be implemented by kernel services, that's true. But as a userland program you shouldn't see or care.

But recently, I've read that the Windows' kernel's ABIs are secret,

Define "secret". Windows is not open source, so you cannot just peek in the code to see what functions the kernel exports. Because Microsoft is the only maintainer of the Windows kernel, they don't need to give anyone else access, so the kernel is fairly self-contained.

That said, drivers of course need to use the documented facilities of the kernel, and those are not "secret". Anyone with a copy of the Windows DDK can develop against the kernel.

so one has to use the user land libraries when accessing kernel functions... is it true?

Not exactly. The mechanisms for accessing the kernel depend on the processor (Windows is available for multiple architectures), but it's typically an INT or SYSENTER instruction with the registers appropriately filled.

However, it is true that you cannot depend on this interface. Only NTDLL.DLL (which implements the native API) is supposed to do this, and that's maintained along with the kernel. You are not supposed to call NTDLL.DLL from your code either, but instead one of the subsystems (like Win32).

OTOH, I know that many people do what they aren't supposed to do (such as doing direct Windows' syscalls), but this doesn't count!

What do you mean? What's wrong with just calling the Win32 functions? If you're writing a driver, you should use the functions supplied in the DDK, which include a well-defined subset of the kernel functions.

If you're a userland program, you have no business going directly to the kernel. Use the Win32 API, that's what it's there for.

Besides, there is ReactOS, which has an open system call interface... But
it can be different from from Windows' while still presenving binary compatibility, given that the applications are dynamically linked against
the libs...

That's exactly why there are multiple levels separating Win32 programs from the Windows kernel.

S.

.

Relevant Pages

  • Re: Windbg: Disable user mode debugging
    ... >> This group is not applicable because of the win32 in the title. ... So you don't have 64-bit Windows. ... debugger is an extension to ntoskrnl and maybe the hal too. ... I do know that the kernel does not have ...
    (microsoft.public.win32.programmer.kernel)
  • Possible 2.6.24-rc7 issue w/respect to pthreads
    ... After I patched my 2.6.23 kernel to 2.6.24-rc7 this morning, ... some odd behavior with respect to POSIX threads in a test program I had ... According to the POSIX ... What I'm seeing is that the main thread terminates immediately. ...
    (Linux-Kernel)
  • Re: [patch 7/8] fdmap v2 - implement sys_socket2
    ... in any way that later becomes inconvenient to us. ... This fds will be out of POSIX definition in any case. ... by POSIX rules for internal communication with the kernel. ...
    (Linux-Kernel)
  • Re: UDP recvmsg blocks after select(), 2.6 bug?
    ... > against having a socket operation block is found in non-blocking sockets. ... It is one thing to implement select/recvmsgin a non POSIX compliant ... So any such behaviour would be a kernel bug. ... then checks the UDP checksum. ...
    (Linux-Kernel)
  • Re: [9fans] mv on directory
    ... UNIX in general does guarantee certain things about rename of the ... but the price they pay in the kernel and elsewhere ... The behavior of mvas defined by POSIX seems to build on top of the ... we lack one of the basic building blocks that makes it behave like it does on UNIX. ...
    (comp.os.plan9)