• Please review our updated Terms and Rules here

DOS reentrancy, the SDA, and critical regions

cr1901

Veteran Member
Joined
Dec 28, 2011
Messages
817
Location
NJ
At least from my experience, most books on DOS programming make it very clear that DOS functions are non-reentrant (because DOS only stores one statically allocated copy of the variables reflecting it's current state when executing a service). I recently read two USENET posts (https://groups.google.com/forum/#!topic/comp.os.msdos.misc/RZj2kTObqPc) that explains that getting a pointer to the Swappable Data Area (SDA) and making a copy of the SDA, executing another service, and then restoring the original SDA prior to calling a DOS service within another DOS service makes DOS capable of reentrancy.

Curious, I checked out Ralf Brown's list and found the correct DOS service (int 21h, ax=5D06h), but something struck me as interesting while reading the usage notes:
"Swapping the data area allows reentering DOS unless DOS is in a critical section delimited by INT 2A/AH=80h and INT 2A/AH=81h,82h."

Indeed, int 2Ah contains a DOS kernel service to enable/disable critical sections that does not appear to be typically used by applications. Not having access to my books about DOS internals anymore, this raises a few questions:

1. Is the DOS stack (assuming that's what STACKS in CONFIG.SYS is for) stored in the SDA?

2. What does DOS attempt to protect while inside a critical region? Is it up to the application to make sure it knows that DOS is currently in a critical region?

3. Why bother having a concept of critical regions in the DOS kernel if the application programmer is supposed to assume DOS is non-reentrant? I know multitasking libraries exist for DOS, but...

4. In the USENET post above, Ralf Brown mentions a version of MS-DOS between 3.0 and 3.3 that can multitask. Can anyone else who was around during that era verify that there was a time that MS-DOS was being developed to multitask? Perhaps it's related to the reason DOS has concepts of critical regions?
 
Yes James, there was a version of DOS 4 for multitasking, but it's rare to find it deployed.

As far as the DOS critical area, there's a call (int 21h, function 34h) that returns the address of a flag that will indicate when DOS is currently executing a critical function. Call this function before you actually do anything that might involve a critical function.

If you want to issue a crtical DOS call while DOS is in a crtical section, save the entire DOS critical data section, zero the InDOS flag and proceed with your call, being sure to provide DOS with enough stack space. When you're done, restore the critical data section.

STACKS in the CONFIG.SYS file has nothing to do with re-entrancy. Starting around DOS 3, it became obvious that hardware interrupt handlers were putting their stuff on the interrupted task's stack. If a sufficient number of interrupts needed to be serviced, this can overrun the interrupted task's stack area. So DOS has code to swap to a new stack when servicing interrupts.
So STACKS 9,128 says to reserve stack space to handle up to 9 concurrent interrupts; each stack being 128 bytes in length.

If I'm not being too nosy, what are you trying to do?

Also, the business about the low-numbered DOS functions being "safe", a word of warning is due. If, say, ANSI.SYS is part of the configuration, there are certain display elements, such as current color, position, etc. that will still be affected by your task. So the information about DOS-critical functions is only "sort of" correct.


This is good and bad. If you have a high-frequency interrupt event, the overhead in the stack swapping can bog things down.
 
If I'm not being too nosy, what are you trying to do?

Three things:

1. I want to competently learn 286/386 protected mode, as well as fill in the gaps I have regarding multitasking... for real this time (third time I've tried learning protected mode).
2a. I want to figure out how to enable protected mode such that I can safely use DOS and the BIOS while I have access to the memory, and
2b. additionally get some insight on how device drivers and calls back to DOS on Windows 1.0-3.1 work (since information on that subject seems to be severely lacking).
3. I want to understand DOS internals... for real this time... and devise a block diagram of how I'd multitask DOS safely on a 8088, 286, and 386... it IS possible, otherwise DESQView and Thomas Wagner's CTask couldn't exist.
 
Ugh. The implementation details will likely drive you crazy. Basically, it sounds as if you want a multitasking DPMI/VCPI server.

I think that the source to CWSDPMI is a good place to start--and study up on the LOADALL instruction, both the 286 and the 386 versions.
 
Last edited:
Ugh. The implementation details will likely drive you crazy. Basically, it sounds as if you want a multitasking DPM/VCPII server.

I think that the source to CWSDPMI is a good place to start--and study up on the LOADALL instruction, both the 286 and the 386 versions.

Thanks for the hints. I guess that is similar to what I really was thinking about.

Ideally, I'd want a DOS where I can browse the Internet while writing code in another tab XD, and then switch to a full screen game while the other programs continue to run in the background... a DOS that could be reasonably used for common tasks- where the host machine is also the target DOS machine... fat chance lmao! DESQView seemed to come closest to that with it's multiple windows for multiple instances of DOS.
 
Ideally, I'd want a DOS where I can browse the Internet while writing code in another tab XD, and then switch to a full screen game while the other programs continue to run in the background...
That's called Windows 95 XD

In all seriousness, though, you're going to be limited at least as much by the applications as by DOS itself. Perfectly well-behaved DOS software is about as common as hen's teeth, and games in particular almost inevitably assume they have the run of the machine...
 
That's called Windows 95 XD

In all seriousness, though, you're going to be limited at least as much by the applications as by DOS itself. Perfectly well-behaved DOS software is about as common as hen's teeth, and games in particular almost inevitably assume they have the run of the machine...

Indeed. Ideally, you'd want to trap all of the I/O that sets the video controller, timers, etc. so you can restore the context of the peripherals used by the game you're switching in and out of. It can be done, but as I said, it's a big job.
 
Ugh. The implementation details will likely drive you crazy.

Forgot to add this...

To be fair, I think the fact that I'm 23 years old in 2013 and want to learn about DOS internals is an indicator that my mental health is already questionable.
 
If you have access to Undocumented DOS, the TSR sample lists how to use (store) the SDA. First edition, sample is on pages 319-326, DOS 3 structure is page 550-554, DOS 4 structure is 556-561. Note about half the structure is listed as unknown. Critical section is covered on 581-582.
 
Unfortunately, I do not have Undocumented DOS, and cannot find a PDF of it :(...

On an semi-related note, I have a copy of the MS-DOS 6.0 source code, but to be honest I have no clue where I got it from, other than I downloaded it sometime in mid-2011. Was it leaked by someone, or was it legitimately available from Microsoft? I probably torrented it, seeded it, and then deleted the torrent, but it's just odd that I have it lol.
 
MS sold the OEM Adaption Kit with lots of restrictions. Copies escaped into the wild as OEMs went out of business and disks were liberated. MS never offered it as a free download. I don't even think they offered it with MSDN subscriptions.

Undocumented DOS has not been reissued in PDF. Used copies were cheap a few years ago so you may want to try a search at your favorite retailer. The explanations in the book are much clearer than those provided with the OAK. Spend a few bucks and save your sanity.
 
I guess we both have the same versions of the source code.

Pity you can't rebuild the OAK source tree since it's missing the directories that OAK Technology was supposed to provide (\tools, \messages) :(...
 
I think the fact that I'm 23 years old in 2013 and want to learn about DOS internals is an indicator that my mental health is already questionable.

Well, I'll keep feeding you the wacky-pills because I think it's great people under 30 are interested in retrocomputing.

However, I do think you're nuts trying to improve on something that already has a best-in-class product (Desqview). Desqview+QEMM on a 386 is impressive enough, but on an 8088 it's downright voodoo (ie. it actually works, and doesn't require EMS (although that sure helps)).
 
Well, I'll keep feeding you the wacky-pills because I think it's great people under 30 are interested in retrocomputing.

However, I do think you're nuts trying to improve on something that already has a best-in-class product (Desqview). Desqview+QEMM on a 386 is impressive enough, but on an 8088 it's downright voodoo (ie. it actually works, and doesn't require EMS (although that sure helps)).

I wish my college-aged peers would stop poking fun at me about it XD. Though some are genuinely interested too, their head spins when they realize how hardware used to be (ST-506: 170 ms avg seek time!, 640k of RAM).

In terms of the FREEDOS project, a DESQVIEW Open Source clone would be nice... or at least a proof-of-concept (which I certainly think I could do, with some level of trouble/learning curve) to get started. JEMM386 compatibility could use some work too (although, considering it's a single programmer I believe, I give him all the credit in the world... Windows 3.1 just doesn't play nice with it though).
 
Back
Top