I'd demo'ed multi-threading systems to a bunch of Windows developers years ago and they were unimpressed.
Uh, multi-threading wasn't available for the PC until the Pentium 4 was released. Prior to that, x86 processors were incapable of it in anything but multitasking and non-simultaneous multi-threading (same thing, really). If it can't be done simultaneously, there isn't much point to multi-threading.
That was a full year after Windows XP was released, which came with support for simultaneous multi-threading.
So I'm not sure what systems you were running with multi-threading, but they for damn sure weren't x86, so there was absolutely no point for a Windows developer to pay any attention to you. It's like saying "my sailboat does 50 knots" to someone who races motorcycles. That may be extremely impressive to a sailor, but to a biker won't be impressive in the slightest.
Actually, there a quite a few problems that are easier to manage with multiple program pointers with separate memory stacks in the same general address space, even if they are not truly simultaneous. Web servers, for example. Sure, you could have separate process communicating though shared memory- but context switching introduces a fair amount of overhead.
Anyway, thats what I was using threads for back before windows 98 was released.