DOS ain't dead - NetShow Player 2.0 for Windows 3.1

segin

Springfield, MO, USA,
12.08.2023, 09:55

NetShow Player 2.0 for Windows 3.1 - there's multithreading? (Developers)

Or at least, this appears to be the purpose of NSTHRD16.DLL.

There's a number of exported functions related to threading, like CREATHETHREAD(), GETCURRENTTHREAD() and GETCURRENTTHREADID() (which are identical to each other, opcodes and all), etc.

There's also exported versions of various Windows API functions that are implemented elsewhere, like CREATEFILE(), READFILE(), WRITEFILE(), etc. Most of these reimplementations are simple wrappers around the DOS interrupt vector API.

I'm trying to reverse engineer the threading code to determine how it performs it's magic, but while I'm doing that... does anyone here have any clue as to how it works? Or even how it might work? AFAIK, VMM only multitasks VMs, not individual Windows programs (which all share the root VM.)

bocke

20.08.2023, 00:33

@ segin

NetShow Player 2.0 for Windows 3.1 - there's multithreading?

Post reply

> Or at least, this appears to be the purpose of NSTHRD16.DLL.
>
> There's a number of exported functions related to threading, like
> CREATHETHREAD(), GETCURRENTTHREAD() and GETCURRENTTHREADID() (which are
> identical to each other, opcodes and all), etc.
>
> There's also exported versions of various Windows API functions that are
> implemented elsewhere, like CREATEFILE(), READFILE(), WRITEFILE(), etc.
> Most of these reimplementations are simple wrappers around the DOS
> interrupt vector API.
>
> I'm trying to reverse engineer the threading code to determine how it
> performs it's magic, but while I'm doing that... does anyone here have any
> clue as to how it works? Or even how it might work? AFAIK, VMM only
> multitasks VMs, not individual Windows programs (which all share the root
> VM.)

Maybe it's a user-space implementation of the threads? Well, multithreading can be implemented on top of other APIs in the kernel (like in early Linux kernel). But, I'm not sure if Win16 exposes anything but cooperative multitasking to Win16 apps. So, maybe this threading code also use some kind of cooperative model using appropriate functions in Win16 API.

Just guessing. Sorry if I didn't help. :)