中国DOS联盟

首先有一个额外的想法, 如果一个机器(真实或虚拟), 若是能限制能力就好了(例如, 限制为只能使用 8086 指令, 只使用一兆内存等等)

8086 意味着只能有实模式, 常规内存 640 K, 任务切换需要自己实现.

目前对我来说, 任务切换是难点,我也不想实现得很彻底,或者说我仅仅是"假的"多任务,或者模拟多任务,因为我是想让各个任务按时间片轮换的,每个任务都在规定的时间内必须结束(自己结束). UC/OS-II 应该实现了任务切换,一来我还不是很懂,二来我也有点恐惧,因为我对被强行切换掉的任务继续执行总感觉有点不舒服.我希望各任务是协作式的,而不是强行剥夺.当然,我这里实际上也类似强行剥夺,因为我在每个任务中会判断自己的剩余时间,到了的话自己结束(这和被强行结束不同的是,这个任务的一次调度被完成了,而不是被"粗暴地"中断了).但是显然,这样增加了各个任务的书写复杂度,因为每个任务自己都要盯自己的表,而且下次被调度的时候必须考虑能接着执行,这样,一个大的任务可能需要分片,类似重入.我对多任务懂得不多,所以,这样的想法应该不是很好.也许是最糟的多任务处理方法之一!

然后说说 GUI, 我希望是一个"跨平台"的层,可能有点象 SDL, 但是, 我希望图形对象都是用矢量描述的, 而且希望借鉴 *nix 的 c/s 模式, 这样, 实现起图形终端可能比 vnc 以及 rdp 等可能更少占用网络以及其他资源, 初步考虑还是使用比较标准一点的 xml 样的东西. 另外这样可以使 server 端不必和 client 端同等的显示能力, 甚至如果可能的话, 各个 clients 的图形对象也根据显示设备而重新布局过, 当然随之改变的还可能有颜色, 甚至风格(观感)等(这些可能属于 client 端的配置, 但"不强求", 也可以有一个选项使各 clients 的显示结果尽可能相同, 为了一致性). 但是这要求矢量描述中可能会加入事件, 还要考虑是只传送剪切域, 还是"全部"传送, 这里的全部有可能有多个虚屏. 这里可能可以参考 mozilla. 另外, 我想为了效率, remote clients 和 local clients 的实现可以不同.

在这里可能会提供一些"内置的"基本组件,例如 button, lable 甚至更高级的组件等等, 也可能允许安装自定义组件.

关于显示的另一个问题就是设备驱动, 通常使用的类似 BGI 的驱动, 但是有些设备并不提供类似的驱动, 而且更糟的是, 它完全不是 VGA 兼容的, 它也许提供一个库让你使用, 所以这时候为了可重用,可能还得加一层,或者有可能为之写一个 BGI 驱动么? 另外, 我希望这个层之上的应用是尽可能跨平台的. 看来它只好在各个平台下有不同的实现了,因为,BGI并不能应用在 linux 上. 虽然 linux 不能运行在 8086 上, 但是, 我总想尽可能地复用.

关于观感, 我想已经有很多可以借鉴的了, 但是面对极其有限的资源, 必须使代码尽可能地紧缩. 我觉得 windows 系统的已经比较可以了(其实这里可能缩小范围到显示风格或方案了), 它提供了有限的改变, 例如按钮各个部位的颜色等等.

为了可移植, 我想不用 c++, 而用 c, 而且觉得 c 的目标代码可能更精巧, 当然了, 我对 c++ 的理解也不是很多.

快吃饭了, 我先捡要紧的说. 其他的时候再补充!

最重要的是, 我希望搞个 RAD 工具来, 一个目标系统很好, 但是开发工具很差的东西, 并不完美, 不是吗?

好了, 午饭过后再说!

[ Last edited by jawbin on 2006-5-30 at 10:36 ]

我把假设的这个东西称为 A, 那么, 按我所说, 可能事件都要自己处理(重要的是,比如按了某个 button, 不是由 os 告诉你, 而是自己判断得到, 而且这些组件都不用 native 的), 这其实仅仅有一个可能微乎其微的"好处":"anti-crack". 但是却大大增加了复杂性, 也许可能多个应用共享一个虚拟机.

[ Last edited by jawbin on 2006-5-26 at 11:57 ]

回来了:)
另外还有字体问题, 通常是用 GB-2312, 有无必要使用 unicode 呢? 用点阵字还是矢量字, 全角半角混排....

对了, 对于"快速开发"(而不是长远考虑), 或者无论如何, 有无现有的系统可以达到或者超过类似的目的?

可以比较一下 windows 286 - (windows 286 从名字就可以看出, 应该是不能运行在 8086 上的), UC/OS-II, 以及其他的 os'es 或者 platforms 或者 frameworks.

当然一个系统通常还需要网络,这个,在 dos 下倒好解决(我上面所说的都是基于 DOS 或者另一个具有比 BIOS 更高级一点功能的系统的, 否则只能使用 BIOS 功能的话就增加了很多难度, 使用 Packet driver 就可以了, 当然上层一点的使用什么为好了, WATTCP? 如果能和伯克里 socket 兼容的话, 也能增加点移植性, 但是它又太基本了, 应该有更高层一点封装, 以免每次都做轮子：）

[ Last edited by jawbin on 2006-5-27 at 08:57 ]

另外我考虑了一点关于类似 MVC 样的东西, 举例来说, 诊断调试的输出对象不是早绑定的, 它可以随时根据需要改变. 例如字符模式,图形模式(图形模式还有各种不同的显示设备,但那由 client 端的具体设备决定),以及输出到文件,等等,甚至可以重定向,例如重定向到短信.

其他有关输出的也类似.

[ Last edited by jawbin on 2006-5-26 at 13:38 ]

具体在内部,可能还有缓冲区的实现(用链表则增加空间,因为每一项多一个指针,甚至指针的长度比实际用的数据的长度还长,而用条件判断使成环形则似乎每次都需要判断,"降低性能“),如果再复杂一点可能还需要为常用数据缓冲.数据迟载入(Data Late Loading, DLL *^_^*), 分成几块是否可以避免远指针的开销.

任务切换不难，在计时器中断中保存/恢复关键寄存器就行了
关键在于DOS下所有中断服务程序都是堵塞执行的，严重浪费CPU资源，而且处于DOS忙状态时不能切换（要不然会发生重入导致系统崩溃）
所以最好是实现一个API接口层，代理一切中断调用，并使用消息机制，这样的多任务才有实际价值


编写图形界面系统是很复杂的（我一直不知道怎么实现高效的窗口剪裁算法，好恨啊），特别是还需支持MVC模式，感觉不是一般的复杂

编写图形系统最基础的是需要一套设备无关的图形设备接口函数库，如windows中的GDI函数库，可这套函数库很难设计
这是因为图片数据量很大，640KB的基本内存不够用
用XMS？XMS是靠80386保护模式实现的，调用XMS功能时会切换到保护模式执行操作，效率非常低
实模式下访问显存是很痛苦的，不是位平面就是分页。特别是内存不足，一般是逐行的处理图像数据，处理好一扫描行后提交，再处理下一扫描行。
而进了32位保护模式，是线性地址，32位平面内存，完全可以直接对整幅图片进行处理。如果再采用扫描行方式会存在多余的内存移动操作。



绘图还不是最难的，最难的是文本绘制
字符编码我觉得使用UTF-8最好，GB2312早就过时了
然后得提供一套函数集，将不同编码的字符串 与 UTF-8字符串 进行转换
点阵字库有太多缺点了，所以最好使用像TTF那样的轮廓字库。但是TTF是使用贝塞尔曲线描述字符轮廓，而实时计算贝塞尔曲线貌似很难。
为了unicode排版，TTF是不够的。所以Microsoft现在使用OpenType字库，OpenType字库存放了许多unicode排版细节信息。



看看Windows系统提供了多少种多语言处理API吧（严重打击我的智商，特别是Uniscribe）：

• National Language Support: 本地语言支持。提出了Primary Language、LanguageID、LocaleID等概念提供本地化支持。Windows 95、Windows NT 3.5
  
• Unicode and Character Sets: Unicode字符集函数。使用CodePage概念将不同编码的多字节字符串与Unicode字符串进行转换。Windows 95、Windows NT 3.5
  
• Fonts and Text: (GDI)字体与文本。提供了基本的字体与文本排版功能。Windows 95、Windows NT 3.5
  
• Font Embedding: (GDI)字体嵌入。从OpenType字库得到Unicode排版的许多细节信息。Windows 98、Windows 2000
  
• Uniscribe: Unicode复杂文本排版。组合字符、预构字符的排版处理已经非常麻烦了，再加上还有阿拉伯文那样的双向文本，所以专门提供了Uniscribe函数集来处理复杂文字排版。IE 5.0，Windows 2000内置。
  
• Keyboard Layout: 键盘布局。处理西方字符，只是一个简单的键盘按键映射机制。Windows 95、Windows NT 4.0
  
• Input Method Manager: 输入法管理。与输入法沟通一套API，使用该API能使你的程序像微软拼音在Word中的表现一样——与文本编辑器文美融和。Windows 98、Windows 2000
  
• Text Services Framework：文本服务框架。处理键盘、输入法、手写、语音输入的通用框架。Windows XP内置，但其它平台可以安装TSF支持包。
  
• Active Input Method Manager: 活动输入法管理。IE提供的的输入法管理增强型解口，比如在简体中文Win98平台下可以在IE中使用仓颉输入法。IE 4.0
  
• MLang: 多语言。IE中用到的一套多语言编码转换API。IE 4.0
  

最后，坚决BS RAD 工具，API才是王道

好长啊，刚看了第一段，jawbin兄说的这个叫协程，Win3.1用的就是这种协作模式。这个模式的主要优点是线程/进程间同步比较容易，大大减少了临界资源争抢和同步访问的问题。不过缺点很多，主要是：
1. 协程间必须严格自律，否则会出现一个协程完全不释放CPU的情况（比如存在缺陷或者恶意代码）
2. 时间片颗粒太粗，协程间切换不够平滑，在很多情况下用户能明显感觉到运行不流畅
3. 操作系统无法控制资源分配，也无法解决死锁等问题。

协程现在基本用在较多用在来源可靠，组合固定并且经过全面测试的场合，比如嵌入式应用和嵌入式角本引擎等等。

很兴奋zyl910来相助,我先回再细细体会!
不过我觉得拒绝 RAD 就是自绝于效率,而且如果整个系统都是自己开发的,那么,不用担心封装造成的黑盒子问题!这不是噱头,而是实实在在的生命(时间)啊!

哇, asbai 兄也来了, 我 high 疯了快!

asbai兄, 我肯定是要各任务严格自律的,因为任何一个循环,必定要给以给极限次数或者时间,每次循环都检查,以防阻塞.

另外,一些延时函数我想利用起来,让别的等待的任务运行,而不是让 CPU 空等.

目前我搞的一个很粗糙的,任务还是很协调的.

另外,还需要加入错误处理,例如截获 int 24h, 然后给用户更友好的信息(Windows 的蓝屏总比没有好,呵呵)

接着消化 zyl910兄 的内容!

[ Last edited by jawbin on 2006-5-26 at 14:50 ]

Originally posted by jawbin at 2006-5-26 14:46:
asbai兄, 我肯定是要各任务严格自律的,因为任何一个循环,必定要给以给极限次数或者时间,每次循环都检查,以防堵塞.

另外,一些延时函数我想利用起栮..

这样只能开发诸如嵌入式应用这种封闭式系统，开放式系统允许第三方自由开发应用，这样光严格自律就不够啦，还要想办法律人才行，呵呵

Originally posted by asbai at 2006-5-26 02:50 PM:


这样只能开发诸如嵌入式应用这种封闭式系统，开放式系统允许第三方自由开发应用，这样光严格自律就不够啦，还要想办法律人才行，呵呵

千真万确,我前面也说了,这样协作的话,增加各个任务书写的复杂度,当然可能也增加了代码以及降低了效率. 所以这是个必须注意的问题. 只能自己用可以...哎

[ Last edited by jawbin on 2006-5-26 at 14:53 ]

"任务切换不难，在计时器中断中保存/恢复关键寄存器就行了"
我通常是不敢在中断中做事的,怕出问题,一般做的可能就是 ++i 这样我感觉起来高枕无忧的事情..
但我目前其实尽可能少在中断里做事


对了,由于异常提示(例如类似蓝屏)是必须让用户看见的,所以,考虑点 MVC 我觉得还是应该的.

[ Last edited by jawbin on 2006-5-26 at 14:58 ]

消息应该要使用,毕竟已经证明很不错.