vscode-ripgrep VS ntoskrnl

VS Code

An example of a performance-critical feature is the project-wide text search, which is ripgrep (Rust). Microsoft publishes that library as an npm package / Node native addon.

Here how WebGL is used for the terminal in VSCode,

https://github.com/microsoft/vscode/issues/85971

Or how Rust is used for search via ripgrep.

https://github.com/microsoft/vscode-ripgrep

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