过段时间我再发布新的源代码吧。我自己已经测试过，TASK 可以在 Turbo C 的任意内存模式下编译和使用。
Turbo C 的内存模式确实很烦人，导致发布库文件的时候都要发布多个内存模式的库。并且自己的代码在编译与连接的时候也要与库文件的内存模式保持一致，否则会有问题。

下一步的计划是为 waitfortaskobject 加入等待超时功能，以及优化 mutex 的等待队列的处理。

然后我会将其整合入 RGE 中，RGE 最近我也在改进，架构上作了调整，目的是为了优化，然会回加入 JPEGCodec ，而以前的 GIF 和 PCX 的 codec 都会重写。甚至可以将 H.264 的 decoder 加进来，不过是用的 ffmpeg 的代码，不知道能否移植成功。wavedev 也会被重写，会采用 wince 中 wavedev 的类似架构。keyboard 和 mouse 也要重写，当然这些改动一方面也是因为多任务系统的引入。

还有一点重要的，就是多任务系统中还要进入消息队列这个对象，为以后的多任务 GUI 打下基础。
另外还有一项技术就是 dos 下的共享库，其实很容易做到的比如说 Turbo C 的 bgi 图形驱动就是一例，当然我会做得比 bgi 更加的好，使用起来就像使用 windows 的 dll 一样方便。

做操作系统不如做游戏
 
一个好的游戏更甚一个普通的操作系统
 
本人目前正致力于研究游戏的 图形界面子系统(GUI system)

     我是菜鸟，不是太懂，要是我也能像你这么厉害就好了，呵呵，顶一个

RockCarry

兄，我想你可以将最核心的保存/切换寄存器工作，做一个抽象，或做一个较详细的文档说明，为将来可以移植到其他嵌入式硬件做准备

很多地方，尽量做到与硬件无相关性。我相信你这个东西有一定的应用前景。

做人不可太浮躁，我设计这个东西绝对是有意义的，如果大家没有认真研究 task 和 RGE 的代码，自然不知道我要做的是什么，那么在这里就没有进一步交流和争吵的必要。而且我们早就知道你在做游戏，不必重复声明。

[ 本帖最后由 RockCarry 于 2009-8-7 10:14 编辑 ]

回复 16楼 jig
恩，可以像 ucos 那样，将与硬件相关的代码独立出来，交给用户实现，方便移植，后面我会进一步改进。

其实多任务涉及的问题包括，代码的重入，任务堆栈，任务切换，任务队列，任务调度等。
首先要明确的就是，一个任务就是一个任务函数，在自己的堆栈上的一次执行的过程。其中每个任务都是要有自己的堆栈的，这一点相当关键。任务有了自己的堆栈，才有了自己的私有数据。
任务切换需要做得就是保存当前任务运行的环境，即全部的处理器寄存器到当前任务的堆栈。然后切换堆栈到需要调度的任务堆栈上，再从新堆栈上恢复全部的处理器寄存器，也就是从堆栈上弹出全部寄存器。
而任务队列和任务调度，基本上就是纯算法的东西了。

TC 中的 interrupt 类型的函数，会自动保存和恢复大部分的寄存器，大家可以分析 ttc -S 出来的汇编代码，因此在时钟中断处理程序中，几乎就不用手动的保存寄存器，只需要在函数返回之前切换一个 SS 和 SP 两个寄存器就可以了。
interuupt 触发时会导致 flag, cs, ip 压栈，进入 TC 的 interuupt 类型的函数，编译器会自动保存  ax, bx, cx, dx, es, ds, si, di, bp ，函数返回时会从堆栈上弹出这些寄存器。所以在时钟时钟中断中只要修改 SS 和 SP 就可以完成任务切换。

另外一个重要的地方，就是如何创建一个任务，创建一个任务，其实就需要对其堆栈进行初始化，包括压入初始的寄存器，返回地址等等。另外理解 tc 编译器在对 c 语言函数调用的处理，包括参数压栈和出栈的方式。当然还需要理解 tc 中的内存模式，对tc 的变量和函数的影响。总之就这样了。

[ 本帖最后由 RockCarry 于 2009-8-7 10:08 编辑 ]