winfile VS MS-DOS

Ask and ye shall receive: https://github.com/Microsoft/winfile

File Manager, or winfile.exe, was the predecessor to Explorer's file management aspects. You can use it on Windows 10 and 11 (and all the others) if you want to.

Program Manager, or progman.exe, was the predecessor shell to Explorer. It was included with Windows through Windows XP SP1 before finally being stubbed in SP2. You can probably grab the binary from XP SP1 and run it in newer Windows versions, though.

> Plenty of open source apps are abandoned. The maintainers get tired, too busy, or whatever.

Other people can pick up the baton. For example my window manager of choice is Window Maker which was abandoned for literally years (fortunately since the underlying tech doesn't change every other month, it still kept working) before someone else it picked it up and nowadays there are a few developers working on it.

> If it was open source, the odds are no one would care to take over maintenance (though they could) since it’s basically redundant at this point.

When Microsoft opensourced winfile[0] (the file manager from Win3.x/NT 3.x) some developers did flock to it (i personally even added a small feature to allow for multiple file masks which was merged), so i'm pretty sure the same would happen for an opensourced wordpad.

[0] https://github.com/microsoft/winfile

There's always winfile lol. I wish they'd drop the 95 era file explorer source. That was the best one imo.

The ancient winfile (that get revived by microsoft), ctrl+shift drag to make symlink.

Joke comment: WinFile if you do not have Windows 11 22H2.

Here's the WinFile link, enjoy :) - https://github.com/Microsoft/winfile/

Good old Windows File Manager from the early 90s! In the Microsoft Store or github https://github.com/microsoft/winfile

This 4.0 code contains references to 4.00, though: https://github.com/microsoft/MS-DOS/blob/main/v4.0/src/BOOT/...

I recently stumbled across the MS-DOS 1.25 and 2.0 source code [1].

[1] https://github.com/microsoft/MS-DOS

“Despite this reduction in scope for MS-DOS 2.0, it did carry many bits of XENIX. The system adopted I/O redirection via less-than and greater-than symbols, piping, a hierarchical directory tree, file handles […]”

The source code for MSDOS 2 is available and the file descriptor stuff appears to be in https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/... and XENIX2.ASM. It stands in contrast to the File Control Block API which MSDOS 1 (née 86-DOS) modeled after CP/M’s API.

Asynchronous I/O figures in prominently in Windows NT. I was really surprised to see[0]:

Each driver in the chain defines two entry points; the strategy routine and the interrupt routine. The 2.0 DOS does not really make use of two entry points (it simply calls strategy, then immediately calls interrupt). This dual entry point scheme is designed to facilitate future multi-tasking versions of MS-DOS. In multi-tasking environments I/O must be asynchronous, to accomplish this the strategy routine will be called to queue (internally) a request and return quickly. It is then the responsibility of the interrupt routine to perform the actual I/O at interrupt time by picking requests off the internal queue (set up by the strategy routine), and process them. When a request is complete, it is flagged as "done" by the interrupt routine. The DOS periodically scans the list of requests looking for ones flagged as done, and "wakes up" the process waiting for the completion of the request.

I didn't realize that kind of forwarding-looking perspective was going into the design of MS-DOS.

[0] https://github.com/microsoft/MS-DOS/blob/master/v2.0/source/...

>Any others I'm missing?

I would suggest MS-DOS: https://github.com/microsoft/MS-DOS