你好啊，端午节快到了，提前祝你节日快乐，进去看一下吧，里面是我送给你的祝福，http://duanwu.8wish.com/?stra=%20%20%20%20%u51B0%u96EA%u871C%u513F希望你多多光顾我那里哦

是啊，我刚吃完饭也想到了DriverStudio里那个受限的STL实现，或许可以考虑移植一下！

filedisk作者页面上那两个库，正在看代码，DRIVER STUDIO的STL也在看，希望能解决问题。多谢

最新的DDK所用的C++编译器是Visual C++ 2005(VC9)的编译器，其与标准的兼容度可想而知，主要还是因为编译环境的关系吧，而不是编译器的问题。如果大量使用了STL模板容器，代码又不太好替换成其它的数据结构进行管理，那我只能表示遗憾了。我通常在驱动中连CRT都不用，因为它们不是多线程多处理器安全的，Native Rtl中有如此多的支持函数可以实现相同与STL的功能，难道你不能单就这一个模块重新实现一下吗？

参考一下http://www.acc.umu.se/~bosse/的libcpp实现代码吧！它在驱动中实现的RTTI和C++ EH，或许再进一步修改一下就支持编译通过使用STL的代码。主要是STL的模板容器指望着在内存分配失败时new会抛出异常，然后所有的错误处理都交给应用程序，Native或是Kernel中整个不是这种思想。

这是一个包含界面的较大规模的、多人完成的、跨平台程序，可以在WIN32或LINUX下正常运行，并通过了严格的测试。由于功能上的需求，这个程序在某些情况下，需要先于操作系统外壳运行，以便不受约束地操作系统分区，比如C盘，也就是说这个程序在WINDOWS平台下还要能编译成NATIVE程序。程序中大量使用了STL，而NATIVE程序通常都是用C写的，并在DDK中编译，应此最初编译都无法通过，后来想办法自己实现一些C++底层机制并修改局部代码后，仍然不能完全编译，因为其中有个模块的编写者自己实现了一套类似于COM接口的机制，这个模块是如此复杂，包含了大量使用宏、模板、STL的一些“巧妙”的代码，以至于DDK的C++编译器无法理解，没有一个编译器是百分之百地符合C++最新标准而。最初写这个模块的程序员，因为地震再也不会继续写下去了。如何在NATIVE下编译出这个程序，并稳定地运行？别说用C重新做一遍，那是不可能的。