current community

your communities

more stack exchange communities

company blog
Stack Exchange Inbox Reputation and Badges
tour help
Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top
up vote 49 down vote favorite
6

Windows in its earliest days was simply a shell that ran on top of MS-DOS, which means that Windows 3.1 itself was actually just a standard MS-DOS application like any other.

Yet, MS-DOS is not a multitasking operating system, and at the same time, Windows applications were compiled native-code binaries that ran without any form of managed environment. So, how exactly was multitasking of Windows binaries achieved if Windows 3.1 was simply a regular old MS-DOS program itself? Are there any old technical documents still floating around that describe the early Windows architecture internally?

share|improve this question
9  
Not entirely true. Windows 3.1 would switch the processor to protected mode, which allowed memory segmentation and other goodies that helped manage a multi-process environment. It was not simply a "MS-DOS application like any other." (Thus, it required at least an 80286 processor for those features) – Joe Jun 7 '16 at 23:43
4  
Joe, windows 2.x and 1.x don't switch to protected mode. Even on windows 3.0 was "optional". – Zardoz89 Jun 8 '16 at 5:22
3  
@Joe Windows actually emulated "protected mode" if it wasn't available. It only really went "hardware protected" with preëmptive multi-tasking on a 386 CPU (not 286), and even then, it consisted of multiple virtual machines, some of which were "real" (for MS DOS applications) and some of which were "protected". Depending on your hardware and software configuration, Windows came all the way from "a thin GUI client on top of DOS" to "a full blown preëmptively multi-tasked OS that just happens to be started from a DOS loader instead of a bootloader". – Luaan Jun 8 '16 at 8:57
3  
Raymond Chen has written a lot about how old versions of Windows worked on his blog, The Old New Thing. I recommend a perusal of the history tag on The Old New Thing. – Michael Kjörling Jun 8 '16 at 13:37
2  
@RetroGamer Not only "modern" computers. For example, the Amiga OS used pre-emptive multitasking before even Windows 1.0 existed, and I'm sure there were at least one other home computer with a similar feature. Not to mention the big UNIX guys of course.. – pipe Jun 8 '16 at 20:18
up vote 41 down vote accepted

For win16 programs, Windows implemented cooperative multitasking. Its implementation was based upon the "message loop" architecture of every Windows program.

The duty of every program was to endlessly run in a loop in which a call to GetMessage() function was performed. This function call looks whether a message to this process is in the queue. If there is one, it is retrieved (GetMessage), optionally translated (TranslateMessage, this is done to convert keyboard shortcuts into menu actions) and finally, passed to the window procedure (DispatchMessage).

If there is no message available in the queue, Windows suspends the current task and gives the CPU to other task, which will try to retrieve a message from its queue as well, yielding the CPU to another task if no message is present.

If a program needed to perform background tasks while there was no pending messages in its queue, it would call PeekMessage instead of GetMessage. This didn't make the task to relinquish the CPU, as PeekMessage would inmediately return to the caller task informing whether a message is available or not. This was used to time-multiplex message processing with another time-consuming task (think of a 3D program doing a render, but allowing the user to cancel that render by pressing a "Cancel" button).

If this time-consumning task was actually very time-consuming, a well-behaved program should call the yield() function from time to time in order to relinquish the CPU and let other task to run.

A bad-behaved program could easily hog the CPU by not retrieving messages too often, or spending too much time in a window procedure function.

The situation was quite different for MS DOS boxes. They ran using the V8086 mode of the 80386 (if Windows was running in enhanced mode). Windows-aware programs ran in the so-called VM 0 (virtual machine 0). DOS boxes ran from VM 1 upwards.

DOS programs usually were bad-behaved programs, so Windows assigned each DOS box a different virtual machine. Virtual machines used preemptive multitasking in Windows 3.1 and thus, each DOS box could run concurrently of each others, and concurrently of any Windodws-aware program.

share|improve this answer
1  
MS-DOS programmes could be made aware of CPU sharing. The TSR functionality enabled a form of co-operative multi-tasking. – Chenmunka♦ Jun 8 '16 at 10:01
1  
In MSDOS Int 28h worked as an idle call when it was waiting for input. Also when running with DPMI hosts (such as windows 3.x) you could call int 2fh function 1680h (Release current virtual machines time slice) I added these to a Dos based application to improve the performance when running under Windows. (exact details may be wrong it's over 20 years ago now) – PeterI Jun 8 '16 at 14:07
4  
A TSR program didn´t have to do anything with multitasking. They usually intercepted some DOS or BIOS vector so they would be triggered by some event (press a hot key, the timer interrupt, activity on the disk, etc). About int 28h and int 2Fh, those mechanisms came into scene when Windows was marketed. Before that, many DOS programs were made so no one of them was aware of such added functionality. Instead, programmers learned soon how to directly write on the screen, read keyboard, etc, making the DOS world a wilder place than the old west... – mcleod_ideafix Jun 8 '16 at 17:04
2  
...Those system calls of course helped DOS programs to behave a little better in the new Windows world, but the majority of them, just didn´t use them. Anyway, my answer has been edited to not to cause misinformation :) – mcleod_ideafix Jun 8 '16 at 17:04
    
Remember that DOS+Windows 3.1 also had Standard Mode, which was somewhat different to the 386 Enhanced Mode that you describe here. – JdeBP Jun 8 '16 at 18:31
up vote 34 down vote

Found a great question on Super User that explains it really well!

Windows 3.1 uses cooperative multi-tasking – meaning that each application that is in the process of running is instructed to periodically check a message queue to find out if any other application is asking for use of the CPU and, if so, to yield control to that application. However, many Windows 3.1 applications would check the message queue only infrequently, or not at all, and monopolize control of the CPU for as much time as they required. A pre-emptive multi-tasking system like Windows 95 will take CPU control away from a running application and distribute it to those that have a higher priority based on the system’s needs.

Source: http://superuser.com/a/726367/541767

share|improve this answer
5  
HTG just scraped Superuser for that article. The original is at: superuser.com/questions/726348/… – Dan Neely Jun 8 '16 at 11:25
5  
"A pre-emptive multi-tasking system like Windows 95 will take CPU control away from a running application and distribute it to those that have a higher priority based on the system’s needs." -- this bit is only half-true, windows 95 premptively multitasked 32-bit code but it cooperatively multitasked 16-bit code and it was sufficiently reliant on 16-bit code that freezing the 16-bit side would freeze the whole UI. – Peter Green Jun 8 '16 at 13:30
2  
@Peter: »reliant« is a string word here. Windows 95 tried hard to keep 16-bit applications in the illusion that they are in complete control of the computer. That's why there were a lot of hooks that routed Windows-native things through old 16-bit layers when necessary to allow old things (e.g. DOS device drivers) to still work. Those were often the places where a 16-bit application could stall or crash the OS. However, it's not so much that Windows needed those 16-bit parts to run, nor did 32-bit Windows applications. As far as I know they were only active when a 16-bit program was running. – Joey Jun 9 '16 at 7:43
    
@Joey - no, the graphics subsystem on Windows 95 was (entirely) still implemented in the 16-bit GDI and User DLLs; the 32-bit APIs were implemented through thunks to the 16-bit libraries. That also meant every GUI interaction required the global lock for running 16-bit code. – jcast 2 days ago

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.