>>81
A lot of it
is userland code. For example, everything having to do with DLL's(Dynamic-link library) goes in the userland (of course, kernel mode code(kernel, drivers and others) has its own APIs for loading those). It's actually so well known how this works, that an user could easily implement his own DLL loader/API resolver without calling a single Windows API (it does however depend on some structures being present), it's also possible to do API resolving fully portably(offsets in structures are slightly different for windows 9x and nt, as it's a completly different kernel architecture, but that can easily be solved by checking the OS version in the same structure), for library loading you would actually need memory allocation/protection APIs, so you'll have to use some syscalls if you don't want to use the APIs directly. The actual APIs implemented in kernel-mode go through a mostly well-known interface(documented officially, but subject to change as OS version increases, however the usermode interface is usually not subject to change), and their numbers are not that high(for non-GUI stuff, ~150-350(nt4->nt6)). As for the GUI stuff, they did implement a lot of it in the kernel, but I'm no expert about that, I only care about the essential OS functionality (which means kernel32.dll in user mode and ntoskrnl/win32k in kernel mode).