qkc库是windows下的libc库，兼容posix标准，并实现linux下特有的API接口。它可以被visual studio直接使用，用来编译linux下的c源码。经过半年的开发，基本完成代码总体框架，还没有经过调试验证，也算告一段落。qkc的实现参考了glibc/linux/cygwin以及网络上的许多博客，感谢这些源码的作者。
在windows和linux的底层API中，功能上基本相似，但在细节处中有诸多不同，为了完全兼容，除了需要在性能上容忍损失，还是有不少难点。
1、难度最大的是跨进程通讯。Linux下的跨进程通讯方式，windows都有对应的接口，共享内存，信号量，互斥量。不同的是，linux是以一个整型变量来标识，而windows是以字符串来标识，导致这需要一个映射管理器来管理这个对应关系。一个取巧的办法是，让这些字符串按照prefix + id的格式拼接而成，就可以省去管理。
linux下当进程退出时，会自动释放这些资源。但是qkc因为是用户层的库，在系统API上做了一层封装。当windows退出时，会自动释放系统资源，不会自动释放qkc为封装而申请的资源。其他进程也无法感知该进程的退出，如果此时在竞争一个锁，就可能导致死锁。
2、文件系统。在linux下一切皆文件，比如跨进程通讯的/dev/shm，比如管理进程的/proc。在windows下，提供普通文件的接口，这些信息涉及到全系统公共信息，只有一个动态库中难以模拟。这个问题，其实和跨进程通讯类似，需要有个全局性的管理器。
3、epoll的实现。和epoll对应的是IOCP，但是epoll模型是reactor模式，而IOCP是preactor模式。这个模拟方法在《epoll移植到windows的可能性》中提到。与此类似的，还有inotify。inotify的难点同时也和文件系统相关，/proc/sys/fs/inotify其实也是一个虚拟文件系统。
4、syscall，syscall的实现并没有特别的难度，关键是量大，有几百个。
5、errno和GetLastError的对应关系，和syscall一样，量大而且还不能完全匹配。
网友评论