ntoskrnl VS psst

This is part of what I read on HN:

The first thing we observe is that the directory structure is basically identical. Yes, NT kernel subsystems are identified with short codes like "Ke" or "Ex". It's plausible that someone with a lot of NT knowledge would end up creating top level directories with these exact names, as is true of the WRK. But it seems kind of unlikely: the Wine sources do not show this pattern.

If we look at the Kernel Executive (Ke) subtree, we can see that there is a thing called a "Balance Set Manager". Both source trees define it in a file called balmgr.c - not only the location of the file but also the file name is identical.

https://github.com/Zer0Mem0ry/ntoskrnl/blob/master/Ke/balmgr... https://github.com/reactos/reactos/blob/master/ntoskrnl/ke/b...

It appears from the module description that the "balance set manager" is an optimisation of some sort related to reducing memory usage. Is this really something that needs a reimplementation with identical function prototypes?

Looking at the code of the identically named KeBalanceSetManager function, we can see that not only is the function prototype identical, but the order in which it does things is also identical. First it changes a thread priority, then it schedules a periodic timer callback.

Some of the local variables in these functions have identical names: PeriodTimer, DueTime, WaitObjects. Yes, these are obvious names. It's not a smoking gun. But it's not looking good.

Finally we discover that the ReactOS Balance Manager does .... nothing. It enters a loop which starts out by doing a wait for an event (fine, it's inherent to the task), and then switches on the result. But the code in the arms of the switch are commented out (the commented out code does a subset of the stuff in the NT code). The loop does nothing, just sits blocking in a loop forever. Why does this code in ReactOS exist if it does nothing?

It's the same story for the other big function in this file, KiScanReadyQueues. The code is virtually identical, line for line, with minor formatting and occasional trivial naming differences. Even the assertions are identical.

I'm not alleging anything specific or illegal, just comparing a small part of both codebases. However given what I've just seen, I wouldn't touch ReactOS with a barge pole. The Microsoft guy's complaint is entirely understandable.

https://news.ycombinator.com/item?id=20345645

On the other hand, this Rust-based one called Psst looks awesome and works: https://github.com/jpochyla/psst

Psst but currently very limited in features and have to build yourself.

psst, https://github.com/jpochyla/psst

I don't know how can I install this open source software from github.

Would like to add that you can also use clients such as spotify-qt and Spotify TUI to control said "device". There's also Spot and psst that are standalone (librespot not required but no Connect functionality).

You can also take a look at Psst. I use Symphonia for decoding and CPAL or CubeB for output. CubeB is a bit nicer.

There's also this project, written in Rust, which is a great GUI Spotify client https://github.com/jpochyla/psst

There‘s a Spotify client, psst, which has an Async widget (with a Promise state struct) that works very well for loading states etc. That project has a bunch of other tidbits and interesting patterns for Druid, I learned a ton from the code.