将自己编写的DLL包含到内核当中并不是难事，但是这并不意味着你的DLL能够加载到Slot 1。可能细心的你已经发现，当你用应用程序加载你自己手工包含到内核中的DLL时，这个DLL一定是加载到调用进程的地址空间中，而不是系统DLL的特有的地址空间Slot1，即使你在project.bib文件中加了文件属性NK或者S。也许你不会介意，认为只要能运行就OK。但是假如DLL加载到Slot 1，那么可用的进程地址空间就节省了。这对于本来就拥挤的进程地址空间来说是个好事。我早就注重这个问题了，可是最近才在MSDN的Knowledge Base中发现一篇文章，介绍如何将DLL加载到Slot 1。
只要符合下面两个条件，DLL就可以加载到Slot 1：
1、这个DLL包含在*.bib文件的MODULES中，且不能具有压缩属性。
2、在内核编译期间，一定要存在一个和DLL同名的.rel文件，且处于同一个目录下。
对于第一个条件，很轻易实现，在PB中包含的模块默认就是不压缩的。假如你不会加入DLL到.bib中，可以参考我以前写的文章。对于第二个条件，也轻易实现，只要在编译前在链接选项中加入一个选项和修改一个选项即可。假如是EVC，在“link”－“project options”中找到“/incremental”，改为“/incremental:no”，假如原来是就不用改了。接着添加一个选项“/savebaserelocations:filename.rel”，其中filename指的是你编译的DLL的主文件名。比如我要编译的DLL为abc.dll，那么在此添加“/savebaserelocations:abc.rel”。编译后就能找到这个文件。记住一定要把这个文件和DLL放在同一个目录下，这样PB才能找到这个DLL对应的.rel文件。至于.rel文件的内容，用记事本就能查看，也能看的懂。
到此这篇文章的内容就讲完了。另外我碰到一个问题，想麻烦所有正从事CE开发的网友，问题如下：
Windows CE答应PB开发者创建一个可信任的环境。其中有一种机制：在定制的内核启动后，只答应加密过的EXE、DLL运行，而非加密的EXE、DLL运行会失败。简略的说明这种机制原理，就是利用内核在加载EXE、DLL之前，先运行验证函数来验证EXE、DLL是否具有数字签名，并且签名是否合法。假如合法就可以运行了，不合法就不加载执行。验证函数能够访问一个全局Public Key，在EXE、DLL中包含Private Key。其中PB工具“signfile.exe”用于将数字签名附加到符合PE格式的EXE、DLL上。
这种机制正是我需要的，我想它也是很多PB开发者非常感爱好的。可是我查看了帮助文档，卡在了最后一个环节“signfile.exe”上。需要了解加密的基本知识，而帮助文档在加密方面讲的不细致，我又不了解，所以在此请了解这方面的网友指教，大家可以在CE的帮助文档中搜索标题为“signfile.exe”的文章，假如您了解，希望能够发邮件赐教，本人不胜感激。
