reactos VS MS-DOS

https://reactos.org/ implement some of the windows API

You can use Rufus: https://rufus.ie/en/

To modify the ISO to turn off hardware check and TPM support for Windows 11 to install it on an unsupported PC.

https://github.com/pbatard/rufus/wiki/FAQ#user-content-Help_...

Besides Linux and BSD Unix there is: https://reactos.org/ https://aros.sourceforge.io/ https://www.haiku-os.org/ and https://www.arcanoae.com/arcaos/

I know some third-world nations still use DOS and the BORLAND DOS compilers because people donate old computers to their nations.

With the right OS, old computers are still usable. Please don't throw them away, e-cycle them so they get used by poor nations that cannot afford new PCs.

ReactOS is sometimes very disappointing. Take the issue with toolbar icons, for example. Toolbar icons in at least Office 97, Office 2000 and Visual Basic 6 were affected, as was some game [0]. Microsoft Office is a complex Win32 application, making it a good guinea pig for testing compatibility. And yet, this was fixed a few months ago, and the Office bug was reported in 2016 [1]. The bug with no text wrapping for tray balloons is also an embarrassing thing to have lingering for years (I assume it was like this since the balloons were first implemented in ReactOS).

Does the world really need a buggy Windows Server 2003 reimplementation? I think the efforts of the development team could be better spent elsewhere.

[0]: https://github.com/reactos/reactos/pull/5227

[1]: https://jira.reactos.org/browse/CORE-12377

Anyone tried ReactOS recently? Supposed to be a clean-room FOSS Windows NT compatible OS.

https://reactos.org/

It's still on my TODO. Mostly cause my parents want XP back.

> It's whitespace. There's wayyyy too much god damn whitespace in modern UIs, and it's awful.

I wanted to see how LibreOffice would compare on my netbook, and frankly it's better than the new Word, but still "worse" than the old version: https://i.imgur.com/cWGYh3M.png

That said, at least LibreOffice lets you have your custom themes and actually offers a variety of different interface layouts, which I think is a nice touch: https://wiki.documentfoundation.org/Videos/User_interface

> Windows 7 with the Classic theme (which really was just a slight evolution over Win2K) was peak UI/UX, and you'll never change my mind. It's been downhill ever since, getting worse and worse with each generation.

To be honest, I'm inclined to agree with this. That's also why I rather enjoyed the Redmond theme even in *nix distros. There's just something so very usable about the old Windows look and more modern attempts, such as SerenityOS https://serenityos.org/ and even ReactOS https://reactos.org/

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