我想谈谈我的两个设想：

1. 我们知道，DOS下可以通过扩展程序进入32位保护模式，但目前最大的问题就是难以实现32位的内存驻留程序，最终导致内存管理上的困难。DOS下有多任务管理器，一个多任务管理器既然能实现多任务，必也能在其框架下开发类似于16位TSR程序的程序（本质上只是一个进程，和普通程序区别不大，就像win3.2、win9x实现多任务一样），问题只是目前的多任务管理程序，各不相同，互不兼容，无法开发出通用的程序。所以我认为，如果为多任务管理制定统一的标准，那么DOS的32位扩展应该能更顺利地进行，这样就能更方便地扩展DOS的功能。如果可能的话还应使这个标准与DPMI相互合作。我的想法是，开发或者参与协助开发一个多任务管理器，并以GPL发布。

2. 现在DOS下也有各种GUI，且互相之间不能兼容，架构上差异非常大。我觉得较好的方案应该是类似于Linux，为DOS开发一个GUI Server，这样为GUI标准化就能为DOS今后的发展铺平道路。

最后想说明，以上这两个设想其实是相辅相成的，比如GUI Sever可以利用多任务管理器的接口来进行应用，而不必另外开发多任务方面的内容。

我认为：我们更应该鼓励为DOS开发32位程序。我们要让DOS跟上时代的步伐！

欢迎大家讨论！不要让这个帖子沉下去啊！

Last edited by brglng on 2008-2-18 at 09:49 PM ]

没人顶？

别着急，我刚看到。

先来谈谈你的设想：
1. 我不明白你说的“多任务管理程序，各不相同，互不兼容”是什么意思。多任务管理程序之间要什么兼容性？执行的话只能有一个多任务管理程序在运行，各个多任务管理程序之间要什么兼容性？

2. 同理，我也不明白DOS下的各种GUI，互相之间要什么兼容性？

我的意思是说：
对于多任务管理器，可以在其平台下开发相当于16位TSR的32位驻留内存程序（利用现在的DPMI无法开发出这种程序，所以一定需要多任务管理器提供相关功能），但是这个程序肯定只适合这一种多任务管理器，换了一种多任务管理器就不能运行，所以就需要兼容，即让某一套多任务方面的API成为标准，这样就可以用一种通用的方式来开发32位程序，真正使DOS扩展到32位平台上。
对于GUI，如果你用过Linux，你就会发现Server+Client的模式非常好。Linux下不管是Gnome还是KDE，他们虽然是不同的桌面，但是都是X Client，相互很容易兼容。这种兼容是很有好处的。况且用Server+Client的模式可以使GUI程序不需要一个桌面就可以运行，而且能够减轻GUI程序开发者的工作量。图形程序直接与GUI Server通信来完成相应操作，不再需要开发底层图形代码。
这两个其实最主要就是提供一系列接口，以供别的程序使用。这是模块化的设计。

Last edited by brglng on 2008-2-23 at 01:05 AM ]