>>Not necessarily. You may have a thread which does some disk/floppy/other HW operation, and these may use little processor time, so if it happens in a separate thread, the original thread may keep singing almost undisturbed. It doesn't have to wait for the HW issues to get done, so there's still some gain.

>I, too, was going to respond to Barbara similarly to yours, but then it occurred to me that the OS (Win in our case) has to be designed to handle such "wait states" appropriately. Personally, I have never heard of anything except timeslicing in relation to Win. This *could* mean that Win would simply continue to wait out the slice even in the (non)event of a wait state in the currently dispatched program. Do you happen to know more details (or even have some observations that suggest more smarts than this in Win)???

No secret sources of information, just experienced guesswork, aka WAG.

Just yesterday I spent some time playing my solitaire (it's in the Files) and observed one thing again: when I finish the game, a modal form pops up (a "another game" "yes;no" type) - and it pops up before the last move was actually shown - and the amount of code which happens between clicking the last move and the appearance of this modal window is not neglectable. You can actually see the main game window still being updated in the background. I'm not saying I've observed multithreading or anything of the kind, just that there's some queueing of paint events which doesn't necessarily reflect the chronological order of the events which cause them. I think the request for drawing a new form has a higher priority than the refresh of the background form - and I really don't know what does it mean in terms of threads, timeslicing, OS and whatever. Just had to make a mental note that this may happen again under some other circumstances, and that I shouldn't be surprised.