Some pointless history; you're describing cooprative, or non preemptive, multitasking which was how things worked pre windows NT, maybe earlier? It's before my time in terms of windows programming anyway. And was the reason those early sytems had a hard time multitasking. Not all processes would play nice and share.
Actually it's not even "pointless" history. Even back in the days of visual basic 6, which are not far away, the GUI was single threaded and that could be enforced. While in its day I did not use it, I still recommend that model to newbies. It keeps their silly questions away, in this way: "Ah, I do not know how that code crashed and what that stack trace shows, is your GUI multithreaded? It was not meant to be, and I do not want to hear about it."
Is it harsh? Well, maybe, but I even keep threads out of my own code and do not use them unless it is absolutely necessary. As this thread also exemplifies, somehow it is very hard to explain them to beginners and when used carelessly they can cause a lot of headache to everybody, regardless of how much experience they may have, 'stay away unless it is absolutely necessary to get involved in that mess'' is a timeless advice. I know there are simple ways that result clean code that is easy to debug, well, try explain them to a beginner and we'll see how much progress can be made:)