The control used is a ListBox, and not a ListView, because we're dealing with pre-Windows 95 software here. As a consequence, you can't use Ctrl+Arrow Keys to move the selection, and Space to toggle selection for a file. Yet you can ctrl+click files.

Good. There wasn't much that needed changing anyway, it was nearly perfect as-is.

True, probably pretty feature complete after all these years although a pretty major lacking feature for any serious use is no UNC path support.

Quite fast. Faster than the current explorer.

> We realize this may come as a shock and disappointment to our contributors but we simply do not have the expertise or resources within the organization to continue to maintain this project.

Resources ... Okay. What truly comes as a shock is the fact that Microsoft says they don't have expertise to continue this project. I mean, who is building Windows then? It's the same building blocks, no?!

They pretty much say that the company gutted their team to the point they cannot support the project anymore.

Given the latest layoff rounds there is also good chance that indeed they fired the people who had the expertise on this.

Who would want to work on this thing? It hasn't been a standard part of Windows for at least a decade.

Well, and added tabs, which is really the best part.

I have that on Windows 10 for all applications instead of just Explorer: https://www.stardock.com/products/groupy/

they don't have the expertise? oh right, since it takes 10 seconds to load a right click context menu on the desktop in w11, no wonder /s

Only about 1s here. Wasn't the 10 second thing because it was looking for a now-absent floppy drive?

That's still billions of CPU instructions being run. If you spent the rest of your life locked in some Tibetan monastery, going through all the steps by hand on paper, you wouldn't even get 1% of the way to rendering this single context menu.

The amount of bloat in modern software is simply obscene.

It depends on how many shell extensions you have installed. How something so basic can drag a supercomputer to its knees is puzzling but MS never fails to deliver.

One wonders if it would be possible to invoke those extensions asynchronously and put a little "loading" icon where any new shell items might appear. Or have a hard 2s timeout after which any latecomers get shoved behind another layer of menus.

If you turn off animations they ARE loading the menu asynchronously. You'll see a basic menu with the extensions added on as the menu continues to grow and reflow. It's worse if you right click on a file. It also DOES use "loading" placeholder text

(e) added the bit about the loading text.

They'd probably implement that by launching a new Electron process to keep up with the times.

Its a disease all over software engineering. We add just enough layers of abstraction, but no more, to make it about ten times slower than a Commodore 64. The excuse is that it's to avoid having to think end-to-end as one human can't possibly think end-to-end these days. The reality is the reason they can't is because of all these useless indirection layers in the middle and if those were deleted, they could.

The simplest explanation would be that those shell extensions have poor performance.

1 second is still an order of magnitude too long. Windows XP context menus were much snappier, on much weaker hardware. And XP was rather notorious for being bloated and slow at the time of its release...

Right clicks on my MacBook are perceptually instantaneous.