China DOS Union

Forgot one thing, where did you see v5? It seems like r5???

Moreover, the latest version r5 of CWSDPMI has given up support for DPMI 0.9 (incompletely compatible with it, it is said that it is an incompatibility with a SWAP command) and supports the latest DPMI 1.0. Its version number only indicates the release version. The output of its major version number is as follows:
CWSDPMI V0.90+ (r5) Copyright (C) 2000 CW Sandmann ABSOLUTELY NO WARRANTY
This clearly shows that its major version number is less than 1 (its naming rule is more similar to the habitual rule of the Japanese).

In addition, emphasize and declare. The development history of CWSDPMI. It was not originally developed for DJGPP, but after version R4, it was indeed optimized to support DJGPP. Of course, this independent development team also has activities of co-developing and exchanging materials with the famous game console emulator project MAME.

In a few days, I will post the Chinese-documented document about CWSDPMI.

Once again, does DD need cooperation?

Well, it's release 5, not v5.

Actually, for programs under DOS, what I care more about is the DOS extender. DOS4GW isn't without development, but the free ones end here. DJGPP defaults to using CWSDPMI, but PMODE/DJ also has some advantages: smaller size and faster speed. However, I still can't find a complete comparison.

Although DJGPP is also a 32-bit development environment, I've seen the source code of its runtime library, and the I/O part still uses the underlying BIOS interrupts, which means the program still has mode switching. This is unacceptable for programs with real-time requirements. I'm very interested in: how difficult is it to directly write pure protected mode I/O bypassing BIOS? I hope someone is interested in discussing this.

DOS4GW is definitely not free in terms of copyright. It has never been free.

In fact, discussing DOS4GW and CWSDPMI doesn't make much sense to us. Because the best existing implementation is still the DPMI service provided by MS. I believe most people don't even download the installation package of CWSDPMI.

Bypassing BIOS to write I/O directly in pure protected mode?????? What are you talking about? What else is there besides bypassing BIOS? Right, there are direct machine instructions, but the 80386 processor itself needs a mode switching to transfer from real mode to v86 mode. This is directly determined by the CPU instructions, and Windows 3.x is a classic example of implementation. I really don't understand what kind of thing you want to make with 80386. Do you want to write a real-time operating system???

Dos extender?? These technologies are contradictory to real-time itself. CWSDPMI doesn't support dos extender, and this is stated in the instruction file first.

The implementation of real-time systems under DOS requires other technologies, which need a deeper foundation. Such as industrial control software.

If you are doing this kind of thing, referring to old computer textbooks is actually better.

Finally, protected mode, we talk about it every day. Who can really fully explain what protected mode is? The history of the development of protected mode?

Protected mode, heh, simply put: it's not about protecting your program from being damaged, but about protecting the system from being damaged by your program. The real 32-bit protected mode was only realized after the 80386.

You didn't understand my meaning. The BIOS and DOS code are all code in real mode, while dos4gw, cwsdpmi or other various DPMI servers all run completely in protected mode. If the runtime library or the program calls BIOS or DOS interrupts, the DPMI server will switch the program from protected mode to real mode (I think there is also v86 mode?), but if the program doesn't call anything in real mode, then it's pure protected mode code.

In new operating systems (such as Windows NT kernel and Linux), after the system is loaded, it will take over all BIOS interrupts and make the system truly run in pure protected mode. Of course, what I need is not that complicated, just part of it. For example, is there a possibility to bypass BIOS and DOS for the I/O part? The only difficulty is that this implementation may rely heavily on hardware, and we don't have that much ability. But simple functions like screen output can completely be implemented by directly writing the buffer, thus avoiding mode switching. Of course, some functions may be difficult to complete. As for the input part, I don't have any idea yet.

This post has been sorted into the essence area

What concept is DJGPP? Is it a development environment or an IDE?,,,,,,