操作系统平台及扩展

          一个可调试的系统是异常处理的集合，如常见框架结构中Assert产生异常中断和window平台中的seterrormode控制的异常处理方式，用以告诉开发者系统中产生了不可处理的错误，一方面准确定位，另一方面使系统不会在未知的状态下运行，导致随机性的错误。因此只有稳定的debug工程，才能提供稳定的realease。

平台数据加载扩展

          系统平台一般有以下两种方式扩展：

                         1.提供平台接口，用户可在此基础上开发平台功能插件。这样做的后果是，导致了插件与系统这个的强相关。同时，平台在提供接口的同时暴露了自己内在的漏洞缺陷。因此接口导致了系统的自封闭性降低。

                         2.平台通过指定的数据流通道扩展自身属性，如文件读取或协议数据包。window内核通过符号链接方式获取到指定的文件映射加载sys文件，win32子系统响应用户请求加载指定exe文件。

                            以exe文件为例，一个平台相关的编译器cl或者gcc，查找用户开发工程中main，以一定规则生成编译器所自定义文件（在此用户可以调用编译器指定的开发语言，开发出操作系统平台无关的程序，而无论怎样，编译器却是平台相关的，当然java虚拟机可以看做是很特殊的编译器），接着win32响应文件加载请求，加载exe文件，分析文件头部PE，找到指定的OEP，即程序最原始的main。至此平台扩展出对用户包含main文件的支持，而不是一系列的接口文件，耦合度可以说降到最低，同时系统内部自封闭性较好，同时也让入侵者，只能看着一堆未知数据，望其生畏。

平台数据维护

           系统平台加载文件定义数据，都会在程序加载前生成，或者堆栈开辟时导入（姑且称之为静态数据，相反则为动态数据）。因此平台的运行时数据管理尤为重要，而相比于代码的稳定性，数据管理更倾向于如windowns平台的资源泄漏，内存数据的动态请求。一个耗尽操作系统平台资源的平台也必然是自取灭亡的。windows平台中通过不同pe节点，划分代码和数据，因此静态数据和动态数据（运行时数据）的分离也是必然的，而对于这一部分的数据认识，或许就是传说中的黑盒。