Windows 95. Old style gui programming meant sitting in a loop, waiting for the next event, then handling it.
The GUI worked in a single thread, but your whole program didn't need to do that.
Being able to copy a file and type at the same time was a big deal.
That's not correct. You just needed to create a separate thread for the file operation. For some programmers that was a big deal indeed, the same could be said for some programming tools. But that wasn't a general case at all.
There were some ugly things, like the way file operations were treated down the OS level, but it wasn't impossible to make your application responsive. It wasn't even difficult... if you knew how to do it.
I am not sure about Windows95, but the MSDOS legacy is single threaded, so you did not have the luxury of having the abstraction represented for you by the operating system.
Some people wrote very inventive software to get around it.
In Windows there is a fundamental concept of the message loop.
The message loop is an obligatory section of code in every program that uses a graphical user interface under Microsoft Windows.
Windows programs that have a GUI are event-driven.
Note that WindowsNT is fully multithreaded, but there is a
thread sitting there listening to the event loop still.
(of course other threads can do other things).
OP is talking about what you could do using the built in Windows utilities, not what is possible if you write your own file copy-and-note taking utility (which some people did, like Borland Sidekick.)
I guess what you call "built in Windows utilities" is making a call to the GUI shell. It's actually a very complex inter-process communication that happened to be a one-liner from VB and showed that fancy flying folders animation. Not very flexible though.
Writing "my own" code for file copy was not really so low-level, it's what most people understood as programming at the time. Locating the file, opening it, using a descriptor and a loop to copy blocks through a buffer, closing the file, managing errors... that kind of thing.
If you wanted to do the file operation in the background and keep using the GUI for input, you did need to create a separate thread. But that wasn't some black art feat, you just read a book or searched Altavista for a snippet, if in a hurry.
The GUI worked in a single thread, but your whole program didn't need to do that.
Being able to copy a file and type at the same time was a big deal.
That's not correct. You just needed to create a separate thread for the file operation. For some programmers that was a big deal indeed, the same could be said for some programming tools. But that wasn't a general case at all.
There were some ugly things, like the way file operations were treated down the OS level, but it wasn't impossible to make your application responsive. It wasn't even difficult... if you knew how to do it.