Hi Pete,
As scruffy said, nothing. You can call any Win32 DLL if that's the platform you're running on. In fact the .net FSUIPC SDK code does just that. It calls User32.dll and Kernel.dll just like your C example.
This is a useful thing to be able to do the moment as we're still running on Win32 OS. For example, the FSUIPC client uses windows messages which do not exist in .net. It's essential that we can call Win32 dlls for legacy reasons like this.
If one was to imaging a version of FSUIPC written in .net, you'd use the Remoting Services to exchange data between different processes instead of IPC.
Interestingly, the remoting services also work between different machines on a network. So if FSUIPC was written in .net there'd be no need for a seperate WideFS program as any FSUIPC client program could access the FSUIPC server on the same machine or a networked one. They wouldn't care. There would also be no need to write any networking code either - that's all handled by the framework.
Standard memory allocations arn't required because you don't manage your own memory - the framework does it for you and cleans up after you. Explicit memory allocations are a Win32 concept.
You can't normally use pointer arythmatic in .net because you could get into a mess like corrupting the stack or you might try to read or write memory that you isn't yours.
Having said that - if you're using C++.net or C# these do have full pointer functions available, but if you use them you have to declare your code as 'unsafe'. It's only really useful for porting existing code. There's no reason to use such techniques in .net. Ponter arythmetic is simply not required to write a .net program.
The token stuff is not nessasary. I suspect it's only there because the author was from a win32 background and didn't know enough about .net at the time. There are much tidier ways it could have been done without pointers or the token system.
The managing is not done by interpreting the code, or running it inside a 'proper' Win32 process and looking over it's shoulder. It's done by inserting calls to the various framework libraries at compilaton time.
Paul