China DOS Union

Once this problem is solved, DOS will make rapid progress, I predict!

[ Last edited by brglng on 2008-5-23 at 08:45 PM ]

Why use TSR? It is precisely the proliferation of TSRs that modify interrupt vectors that has led to irreconcilable conflicts in DOS. In fact, a better solution is to be like WINDOWS, where except for device drivers, no other programs are allowed to modify interrupt vectors and key system data areas. When a hardware interrupt occurs, the system sends messages to all running programs. Each program has a main loop and only processes messages that it is interested in. Of course, this would lead to incompatibility with previous DOS programs, but I think this sacrifice is worth it.

Well, there is some truth to that. If everyone comes to modify, it will be a very troublesome thing. But I think DOS is impossible to completely disappear, but it won't be the mainstream either.

Maybe I didn't make it clear. Actually, what I mean is there are no 32-bit "resident memory" programs. It doesn't have to use the same technology as 16-bit TSRs, but it needs to reside in memory; otherwise, DOS won't have truly practical multitasking.

My idea is to use a service program to be compatible with both 16-bit and 32-bit applications at the same time. In this way, 32-bit programs might need to run under its framework. DPMI might be like this, but it might not include the content of how 32-bit programs reside in memory. We can try to expand the DPMI standard. Of course, please forgive me if I'm wrong. I'm not very familiar with DPMI.

If it's possible to make 32-bit programs reside in memory, then we can develop 32-bit device drivers without being restricted by memory limitations.

[ Last edited by brglng on 2008-5-23 at 08:48 PM ]

Making drivers is mainly to enable others to use the hardware better in the operating system. So for 32-bit drivers, you'd better follow the rules of Linux and Windows, and DOS drivers also have rules. If you don't follow the rules, what kind of driver is it then? Also, DPMI is just to file the extended memory management library. You can also call INT 15H or directly modify the CR? in the CPU to complete it.

But there are other practical significances for 32-bit programs to reside in memory (such as 32-bit Chinese platforms, etc.). The limitation of DOS is that its 32-bit programs cannot be run as a deamon or background like in Linux or Windows. Maybe a multitask manager is needed, but with so many task managers now, no one has done this yet.

Novell has multitasking capabilities, and its function calls are also public, with good network functions.