基于操作系统设计的开发环境的设计概要(下)

这部分写的粗略了点抱歉

四、调试模块(续)
5、单CPU多进程调式
前面讨论的各种复杂情况均可以化解为这个情况，即单CPU多进程，而多CPU多进程和多机多进程只是增加了通信同步上的困难，它们的基础都是单CPU多进程
在此讨论的进程，均为含有调式代码的进程，并非一般的软件产品，而且调式器进程是一直处在运行状态

单CPU多进程的调式困难在于不同操作系统对进程生成的方式变化太多，没有多大的定论
如果进程只能通过运行可执行文件来实现则会变得简单，只要在编译阶段将相应的调式代码融入可执行文件中，中间采用一种系统提供的进程间通讯方式，即可完成和调式器的连接
但有一个特殊的地方，如UNIX类的操作系统均采用了一种FORK方式来生成新进程，这为调式自动化造成了一定的障碍
因为在编译阶段要自动判断出用户代码具体生成新进程位置并进行相应的处理，会使得编译器成为操作系统的附属品，而且实现中有一定的难度，用户调式中可能仅对某个进程感兴趣，无须为调式，造成太多的资源耗费，希望各位能帮我想想，有没有好方法实现
一个方法是，编译器不考虑FORK方式，而是提供一种进程标签，由用户自己的标明生成新进程的地方，提示编译器去该处添加处理代码，这样即使对付FORK变种形式也很轻松了
缺点：需要人工实现，显得智能不够

但由此可推导出很多新的调式标记，如记数标记等，希望各位能多想出点好标记

6、调式系统
由前面的讨论可以看出，要实现强大的调式功能，最好是将调试模块做成一个大的调式系统
编程的人遇到这样的困难很多吧，就是打开了一大堆的代码窗口，调式的手忙脚乱，而在WINDOWS基础下，一些鼠标动作和窗口切换会导致不必要的消息处理，使得调式器狂跳一阵
个人认为最好的调试方式是C/S方式，将被调式应用和调式界面分在两个机器中，可以避免使用者在调式界面上的一般操作如鼠标移动等会影响被调试程序
也许有人说，用双屏幕就能解决
不过用C/S或者说是分布式调式系统，可以使得多人同时调试一个系统成为可能，甚至通过广域网来协同调试也行，只要速度不是关键，这样的方式对调试一般的非操作系统式系统会很有帮助的，因为可以跨系统调式，因为中间是通讯接口，不存在操作系统的差异而产生的无法调试
前面讨论的仿真调式方式、子母系统调式方式和内嵌调式器方式均能做成分布式调式系统

五、编译模块
编译理论的发展史远大于我的年龄了，已经成为一门非常成熟的理论，但不完善，毕竟还不能做到自动化编程，希望有生之年能看到自动化编程的实现，最好是有我的功劳，不好意思
在这个设计中，突出考虑的灵活度，而从前面的视图分析和调式分析可以看出，将编译器从铁板一块，分成多个子模块的重要性
至少词法分析和语法分析的分别独立是非常重要的，这可以使得整个系统的功能设计上的灵活度大大增加。它们是形成视图的基础，和进行调式的数据来源
而对编译器自身来说，将其能分割的各个模块尽量的独立，只是用一个大的框架来组织起来有如下优点：
1）便于多种语言的使用同一个编译器，差别可用语言描述脚本来叙述
2）便于移植，不同的硬件体系的运行代码差异可以在目标代码层中兼容，这点和C#语言的想法有点类似
3）便于所有的爱好者将自己的算法添加入系统进行比较，解决编译课程局限于理论的局面

现在写编译器还是有一定难度的，虽然GCC的代码已经公开，但相关的分析文章很少，我也准备在有条件的情况下去分析，因为几个月粗略的看过，发现它写的很乱，使我对GCC的好感大跌
希望有更多的人加入分析编译器代码的行列

对编译器的分解可以很轻松的按照现有书本上的理论大肆分割，越细越好，在写正文前，我也要再看一遍相关的书了

六、类库设计
类库是现代开发系统必可少的部分，也是决定该系统是否实用的关键
但关于整体类库设计的资料几乎没有，连关于为什么MFC会是现在这个样，都没有人来解释
一个基于操作系统设计的开发环境，是不能按照现有的类库方式设计的（而且也不知道它们的设计考虑的初衷）
现有的类库如著名的MFC，它仅仅是操作系统的一个附属，主要是用来开发应用软件的，其本身受到WINDOWS体系的限制太多
在此将从操作系统的理论基础来分析类库的设计思路，毕竟现在的应用软件是建立在操作系统上的，由此推导出来的类库，对应用软件的设计同样适合
操作系统现有理论是按功能模块来分的，实质是每个模块都是一种大的资源类，因此这里将从资源的角度来分析

操作系统资源
|
|—— 启动必须的资源，基本硬件资源（如CPU时间片，硬中断，存储器）
| （核心资源，一级资源）
|
|—— 为应用软件提供的应用接口资源（如API）
| （第二级资源，一种由操作系统定义的协议资源）
|
|—— 应用软件产生的应用资源（如各种控件）
| （第三级资源，最常见的就是图形界面，它本身是操作系统的应用软件)
| (然后从视觉上取代了操作系统,给人感觉操作系统就是视窗)
| （现在正逐步发展成一种应用协议资源）
|
|—— 第三方协议形成的资源（如网络协议）
（独立资源，常和相应的硬件一起存在）

还有一种是真正的基础资源，就是语法和数据结构及相关的无数痛苦的算法
也就是把编译器的基础分解后的结果

基础资源（逻辑资源）
|
|—— 语言定义规则
|
|—— 简单的数据结构（如数组、列表、图等）
|
|—— 其他（为我现在还不知到的东东预留的位置）

现有的类库已有这样的发展趋势了，所以大家努力，还是很容易超过老外的

一点说法
屏幕是视窗类存在的基础，因此视窗类虽然占有了现在多数类库的大半江山，但它不过是操作系统的一个小资源，而且不是必不可缺的资源
曾考虑过关于声音空间的一些概念，最后发现有类似产品出现，但好象很少听得到
听觉是一种唯一能和视觉相比的人信息接收功能
而声卡的功能还远远没达到屏幕那样的地位，等到真正的空间地位声音编辑系统产生的那天，我们就能象处理视窗那样，定位编辑我们耳朵能听到的三维空间的声音了

七、文档管理
关于文档重要性的书和资料是铺天盖地的，此处仅以开发环境设计的需求角度考虑对文档管理进行分析
1、附属的地位
长期以来文档编制都是一个难题，因为很难方便的融入编码过程中，往往是编码结束甚至是调式结束后才编制文档，使得大家都说文档重要，而实际上它是个附属品
作为一个大系统的开发，文档从开始的调研、建模、编码、调式和最后的产品生成都分不开的
而从前文可以看到相应的逻辑视图也是相同的地位，甚至是一一对应的，如将文档和视图结合，则可以将文档的附属地位改变
最简单的考虑就是，文档从某种意义上讲是各种视图的文字注释
所以产生的需求就是，要将文档从现有的长篇大论型的独立结构变成无数细小的文块，将其融合进视图中
另一种客观原因也导致了文档难被重视，就是现有的开发环境本身就没有考虑文档的位置，只是让开发者用一般的文本方式处理，并不对文档进行系统的管理，使得从使用开发环境之初，就很容易忘记了文档编写，而精力都在代码编制上了
文档是系统设计中一个特别环节，它需要更多的人为管理，自己的约束力较弱，将文档分成细块融入视图，便能从一个角度上形成了文档对比，是一种驱动文档编写质量提高的方式
2、文档管理目标
1）克服从属地位
2）即时文档编制
3）形成文档对比
细分文档不可变更，只能更换，但被更换文档必须保留
环境设计中能考虑到的就是尽量将无须人为干涉的功能作好
而文档的人为管理，在很多资料中都有
（关键是我还没怎么去细看过）

3、设计方式
从前面的分析过程可知，是一种先分后合的方式，细分是让用户对各技术细节独立编写文字，要能做到，想到啥就能写入，是一种简单积累方式，配以视图的可视效果来表示，在每个阶段完成后，这些文字片段就是原始资料，编写相应的长篇大论也能得心应手。
作为整体的一部分，文档编制模块就有了一定的难度，因为是细分，选择数据库为存储基础变成为方便之选，为了写入方便，难度是增加在编辑模块上了，幸好编辑模块是最最成熟的工具。
一般情况下，编程时间的文档融合对整体设计的要求不高，而调式中的调试文档的生成，因为调式模块结构变复杂了，相应的文档编制设计也复杂了
当调式模块成为分布式系统时，文档编制也将成为一个分布式系统
即选择集中式存储管理方式，分布式写入。

八、简单的总结

总得来说整个开发环境应做成分布式结构，当然也能只在一台机器上运行，这中间并没有冲突
以协同开发环境为基础，如协同编辑系统的实现，已经有很多文章了，可以很好的借鉴
最好的管理方式是帐户式管理，每个开发小组的成员一个独立帐户，满足系统开发的整体安全性

九、后记
这是一篇概要，很多地方写得粗略了，因为赶时间，希望能得到更多人的意见
最近在书店发现不少相关的好书，又厚又贵的，实在是囊中羞涩，打算天天泡书店了，这就是没工作的唯一好处，空闲的时间特别多，为了写正文，得大量充电了
希望各位多提意见，啥都可以，或者是你的一些不相干的设计思路，因为系统思维本质上是相通的，只是看到的表现形式千变万化
再一次写上我的邮箱：
估计在圣诞前能完成正文，要看各位能否帮我了