Editing Multiuser DOS (section)

==Application software==
While the various releases of this operating system had increasing ability to run DOS programs, software written for the platform could take advantage of its features by using [[function call]]s specifically suitable for multiuser operation. It used [[pre-emptive multitasking]], preventing badly-written applications from delaying other processes by retaining control of the processor. To this day, Multiuser DOS is supported by popular [[Transport Layer Security|SSL/TLS]] libraries such as [[wolfSSL]].

The [[API]] provided support for blocking and non-blocking [[message queue]]s, mutual-exclusion queues, the ability to create sub-process [[Thread (computer science)|threads]] which executed independently from the parent, and a method of pausing execution which did not waste [[processor cycle]]s, unlike idle loops used by single-user operating systems. Applications were started as "attached" to a [[virtual console|console]]. However, if an application did not need user interaction it could "detach" from the console and run as a [[background process]], later reattaching to a console if needed.

Another key feature was that the [[memory management]] supported a "shared" [[Memory model (computing)|memory model]] for processes (in addition to the usual models available to normal DOS programs). In the shared memory model the "code" and "data" sections of a program were isolated from each other. Because the "code" contained no modifiable data, code sections in memory could be shared by several processes running the same program, thereby reducing memory requirements.

Programs written, or adapted, for any [[Computer multitasking|multitasking]] platform need to avoid the technique used by single-tasking systems of going into endless loops until interrupted when, for example, waiting for a user to press a key; this wasted processor time that could be used by other processes. Instead, Concurrent DOS provided an API call which a process could call to "sleep" for a period of time. Later versions of the Concurrent DOS kernel included Idle Detection, which monitored [[DOS API]] calls to determine whether the application was doing useful work or in fact idle, in which case the process was suspended allowing other processes to run. Idle Detection was the catalyst for the patented [[DR-DOS]] [[Dynamic Idle Detection]] power management feature invented in 1989 by Roger Alan Gross and John P. Constant and marketed as [[BatteryMAX]].<ref name="US5355501"/>