> 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?!
My theory: every (I'm exaggerating, more like most) systems programmer in the company was told to join Azure or get cut. Then outsourcing or something. It's been obvious that they don't have many experienced people left to work on native windows stuff for a while now. The constant churn in the platform apis and everything getting turned into a web app was the sign.
You see this on the surviving team keeping up WinUI 3.0 / WinAppSDK.
It is quite obvious from whoever takes place on community calls, or that still answers on endless Github discussions, that their background isn't Windows development.
You see this by them usually not understanding what the framework is still missing from MFC, Forms, WPF, both in features, and Visual Studio tooling.
All the key figures from Windows 8 days regarding WinRT, left for Amazon, Google, or internally to Azure and AI groups.
Win16/Win32 is going the way of the dinosaur. Many of those devs have retired or moved on.
I am personally a huge fan of win32. I was even a ReactOS contributor at one point because of this. That being said, it wasn’t scalable without major changes. Thankfully most win32 apps still work on Windows.
Unfortunately, that means Windows XP, as most of the new OS APIs since then are COM based, and the team keeps making it harder than it should be, as all efforts to improve its usability tend to die out after whoever championed them in first place moves into something else.
It is like Windows Development team has something against nice tooling for COM, only man with hard bear are supposed to handle it. /s
Given the use of the singular pronoun “I” in the readme, I suspect that this was a one-person project within Microsoft, and that person is no longer available.
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.
This was put up as a dev at MS was using it, so this was originally at least WinFile + their fixes (apologies for not going and checking who, I'm on my phone right now).
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.
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.
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
That's total BS, unless it's MS' own code in those extensions. Very typical of them to blame others when it's their own shit code that's causing the problem.
As the other comment here notes, shell extensions have been around for a long time, and have never been a problem on older versions of Windows running on hardware that's much slower than what's available today.
At least on Windows 10, which I still run, pretty much all of the "explorer is slow" issues are caused by shell extensions.
The problem is a lot of the times they make poor assumptions (like "if a process is running it'll respond instantly") and honestly the tools that exist for determining what is at fault are... well effectively nonexistent[1]. This goes even for 1st party shell extensions. Part of the problem is these almost inherently violate what I consider one of the golden rules of GUI programming (don't block the UI thread) and there's a lot of historical reason for this, but it is often the cause of stuff like "explorer.exe uses 100% CPU" or "right-click takes 30 seconds"
[1]: There's a SuperUser post in which the recommendation is effectively: manually binary search for culprit shell extensions yourself (https://superuser.com/a/577935/312312).
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.
new w11 context menu takes "only" 5 seconds, old one 2x much, but i wouldn't call that improvement - and yea, i had some extras there, but didn't bother to troubleshoot, i was on 11 for a day before switching to linux
The newly hijacked right-click context menu I suspect is a new source of hangs, flickers and explorer.exe auto-restarts. Love they added a special “restart” context menu entry in Task Manager especially for it.
Windows 10 Explorer was a perfect vehicle then they had to go and throw a shitty wrap and other afternarket trash on it.
Edit: nevermind the times you have to manually hit F5 so the file you just renamed displays the new name, instead of auto-refreshing. What the sweet hell did they do?
The Windows 11 Explorer is also buggy as shit. They still haven't solved the issue where folders within the Download folder randomly enable grouping again. Or you know, where you could click on the address bar and see the full path to the download folder, instead you see the word Download. Great fucking Job. They butchered the W10 explorer, painted it gold, and tapped themselves on the shoulder.
Of course there are many (many) alternatives, Norton Commander being one of the first.
I work in IT (for many, many years).. support hundreds of computers, and don't have the luxury of configuring each to my liking. I have to use the tools that are available and learned a long time ago to make due with with Windows 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?!
My theory: every (I'm exaggerating, more like most) systems programmer in the company was told to join Azure or get cut. Then outsourcing or something. It's been obvious that they don't have many experienced people left to work on native windows stuff for a while now. The constant churn in the platform apis and everything getting turned into a web app was the sign.
You see this on the surviving team keeping up WinUI 3.0 / WinAppSDK.
It is quite obvious from whoever takes place on community calls, or that still answers on endless Github discussions, that their background isn't Windows development.
You see this by them usually not understanding what the framework is still missing from MFC, Forms, WPF, both in features, and Visual Studio tooling.
All the key figures from Windows 8 days regarding WinRT, left for Amazon, Google, or internally to Azure and AI groups.
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.
> I mean, who is building Windows then?
Armies of H1Bs frantically copying and pasting from Stack Overflow until something compiles.
I (very) badly want to believe this couldn't possibly be true—but sadly, if I had to guess, I'd bet money that it is.
These days it's more likely to be AI, possibly Microsoft's own Copilot.
Win16/Win32 is going the way of the dinosaur. Many of those devs have retired or moved on.
I am personally a huge fan of win32. I was even a ReactOS contributor at one point because of this. That being said, it wasn’t scalable without major changes. Thankfully most win32 apps still work on Windows.
Unfortunately, that means Windows XP, as most of the new OS APIs since then are COM based, and the team keeps making it harder than it should be, as all efforts to improve its usability tend to die out after whoever championed them in first place moves into something else.
It is like Windows Development team has something against nice tooling for COM, only man with hard bear are supposed to handle it. /s
Given the use of the singular pronoun “I” in the readme, I suspect that this was a one-person project within Microsoft, and that person is no longer available.
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.
Thankfully, it is open source! Dig in! :D
You guys really should gift some kudos to Microsoft. As crappy as they can be, they often open source stuff.
Also, TIL that this apparently been open sourced for years.
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.
TIL that Microsoft has been maintaining the original Windows File Manager for the last 30+ years.
Not continuously. They revived and open-sourced it in 2018
This was put up as a dev at MS was using it, so this was originally at least WinFile + their fixes (apologies for not going and checking who, I'm on my phone right now).
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.
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.
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.
The simplest explanation would be that those shell extensions have poor performance.
That's total BS, unless it's MS' own code in those extensions. Very typical of them to blame others when it's their own shit code that's causing the problem.
As the other comment here notes, shell extensions have been around for a long time, and have never been a problem on older versions of Windows running on hardware that's much slower than what's available today.
At least on Windows 10, which I still run, pretty much all of the "explorer is slow" issues are caused by shell extensions.
The problem is a lot of the times they make poor assumptions (like "if a process is running it'll respond instantly") and honestly the tools that exist for determining what is at fault are... well effectively nonexistent[1]. This goes even for 1st party shell extensions. Part of the problem is these almost inherently violate what I consider one of the golden rules of GUI programming (don't block the UI thread) and there's a lot of historical reason for this, but it is often the cause of stuff like "explorer.exe uses 100% CPU" or "right-click takes 30 seconds"
[1]: There's a SuperUser post in which the recommendation is effectively: manually binary search for culprit shell extensions yourself (https://superuser.com/a/577935/312312).
The worst is if you have a registered Shell Extension that lives on a network drive (true story).
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.
new w11 context menu takes "only" 5 seconds, old one 2x much, but i wouldn't call that improvement - and yea, i had some extras there, but didn't bother to troubleshoot, i was on 11 for a day before switching to linux
[flagged]
I think it's mostly because of the many registry entries like context shell handlers
> I think it's mostly because of the many registry entries like context shell handlers
Win 11 is _slow_. 10 times slower as Win10
MS hate aside, Windows 11 Explorer is a thing of beauty.
The newly hijacked right-click context menu I suspect is a new source of hangs, flickers and explorer.exe auto-restarts. Love they added a special “restart” context menu entry in Task Manager especially for it.
Windows 10 Explorer was a perfect vehicle then they had to go and throw a shitty wrap and other afternarket trash on it.
Edit: nevermind the times you have to manually hit F5 so the file you just renamed displays the new name, instead of auto-refreshing. What the sweet hell did they do?
The Windows 11 Explorer is also buggy as shit. They still haven't solved the issue where folders within the Download folder randomly enable grouping again. Or you know, where you could click on the address bar and see the full path to the download folder, instead you see the word Download. Great fucking Job. They butchered the W10 explorer, painted it gold, and tapped themselves on the shoulder.
Well, and added tabs, which is really the best part.
Hell no. There's already a taskbar --- although that's another thing they've managed to screw up in Win11.
I have that on Windows 10 for all applications instead of just Explorer: https://www.stardock.com/products/groupy/
Reminds me of the Haiku window manager a little[1]
1. https://www.haiku-os.org/docs/userguide/en/gui.html
Of course there are many (many) alternatives, Norton Commander being one of the first.
I work in IT (for many, many years).. support hundreds of computers, and don't have the luxury of configuring each to my liking. I have to use the tools that are available and learned a long time ago to make due with with Windows explorer.
There is a setting (maybe on by default?) you just click in the location bar and it turns back into an editble text field like normal.
Not what I mean