It turned out that we were very lucky: A staff researcher at Microsoft later pointed to us that our approach to produce a wrapper DLL worked because wsock32.dll is not a preloaded DLL. Preloaded DLL is a Microsoft term for DLLs that are loaded during system startup. They cannot be replaced by any wrapper DLLs.
However, one can easily disable the preload attribute of a DLL by removing its name from a registry (KnownDLL). Using this trick, we were able to build a wrapper around kernel32.dll to build a user-level fast file system. Working with DLLs gave us the flexibility to leverage user-level communication and minimize the overhead of kernel calls.
The Linux version of VMMC sockets maintains an internal socket
descriptor table that is index with the socket descriptor. But
WinSock adds a new data type, SOCKET, because socket descriptors
are no longer equivalent to file descriptors, as in Linux. This change
forces 
to convert SOCKET values to table indices
and vice versa. A small but important detail.
VMMC sockets is thread-safe and written with support for a preemptive
user-level threads package for Linux [16]. When VMMC
sockets was being developed, support for kernel threads in Linux was
not dependable and was still work in-progress. Therefore, we decided
to use a user-level threads package instead. Using user-level threads
required that we worry about invoking system calls and possibly
blocking the process. We added functionality to the VMMC sockets
implementation to stop this from happening. VMMC sockets also
integrated support for asynchronous I/O. A special socket was reserved
through which requests were made to asynchronous I/O. All of this
additional complexity was necessary because Linux then lacked kernel
threads. Porting to NT allowed us to take advantage of kernel
threads and simplify the thread support for . We no longer
needed to support asynchronous I/O or or worry about threads calling
blocking system calls.
Recall that the VMMC Linux sockets have the limitation that sockets are not preserved across fork() and exec() calls. Windows NT eliminates this limitation because it does not support the fork/exec model for process creation. But NT introduces a the same problem in a different form because processes can ask share sockets. Still, NT is a net gain for VMMC sockets because socket sharing in NT is less pervasive than fork/exec on Linux.
Our experience with a distributed file system
(DFS) [22] led us to extend the sockets API to support
pointer-based data transfers [13]. Using pointers allows
the DFS to eliminate copying from the transfers of file data. We use
ioctlsocket() to access the pointer-based API of .
Finally, we plan to add support for out-of-band (OOB) data, scatter/gather operations, and polling with recv() (MSG_PEEK). Further we want to produce a more complete implementation of VMMC sockets that supports many WinSock 2.0 calls directly.