Windows (not only the 16-bit 3.x, but going as far as the newest 64-bit ones) uses an event loop for the GUI: your program runs a loop calling the GetMessage function, which blocks until the next window message is available. As long as you don't take too much time processing each window message, you don't have to even think about cooperative task scheduling, since Windows will do it for you while waiting on GetMessage.

(In fact, AFAIK even in modern Windows you should avoid taking too much time to process each window message, since blocking the event loop thread makes the UI for your program unresponsive.)

I remember the user experience, I was wondering about design decisions during development.

You are guaranteed no context switches unless you explicitly request one - did it simplify some parts, or alternatively made it more complex? It's an asynchronous application.

Windows NT and Windies 95 were the first versions to have preemptive scheduling. Windows 3.11 and older would only switch tasks when he program requested new messages from the queue. Thus was totally annoying because most applications were written badly and had moments where they would go off and do things and not return to their message loop for several seconds or worse, hanging the entire system during that time. Windows felt very sluggish because of that.

And in Win95, your 16-bit apps could still do whatever they want as they were only cooperatively multi-tasked

You'd only notice if it an app crashed, at which point your only option would be to hard-reset the whole system losing all unsaved state.