Yep, explorer.exe has always started up in the background. Pure speculation here, but this change likely involves preloading the UI surfaces and supporting bits such as disk free space, network share status, thumbnails etc.
Explorer.exe is not file explorer, it is the Windows UI system. It’s harder to see on modern Windows versions (since Windows will reload it automatically), but if you go into Win98 and kill the process, you’ll see your taskbar, desktop icons, right click menu, etc disappear.
File explorer is a part of that process, but consists of additional dynamic libraries and COM components that are loaded on-demand.
Old desktop replacements (like Litestep) specifically modified Windows to block explorer from loading the desktop to replace it (though, would still spawn it for file explorer).
Did you even read the blog post? It's almost a direct quote
> We’re exploring preloading File Explorer in the background to help improve File Explorer launch performance. This shouldn’t be visible to you, outside of File Explorer hopefully launching faster when you need to use it.
explorer.exe is both the shell and the file explorer which is an unfortunate state of affairs.
There's long been an option to make it multi-process, but the cost of that option has increased with every release since 95. If I remember correctly, back in the 95 days that would spawn a new explorer process per window.
These days, probably since tabs or so, when you check this option it spawns exactly one other process, even for many windows. The second process has over 100 threads, the shell process normally spawns around 40 when you open a window, only 20 of which exit immediately when you close the window, the rest stick around for fairly arbitrary periods of time.
Note though about 2/3rds of the threads on my system are rooted in the nvidia driver thunks, I really don't know why so many - is it a side effect of the xaml port?
anyway, no idea what the preloading exactly will be doing, but it does sound like a hack over debt. it'd feel better if there was more process isolation being added to the desktop environment, but you know, it's an old desktop OS, so if one window wants to screw with another window, YOLO! On the flip side making stuff like komorebi is trivial on the platform and there is some nicety to that as long as you trust everything you ever run.
Explorer.exe is technically the Windows UI. File Explorer is a part of that, but has additional COM and other components that it consists of. Those are loaded on demand, now the OS is keeping them resident.
Yep, explorer.exe has always started up in the background. Pure speculation here, but this change likely involves preloading the UI surfaces and supporting bits such as disk free space, network share status, thumbnails etc.
Explorer.exe is not file explorer, it is the Windows UI system. It’s harder to see on modern Windows versions (since Windows will reload it automatically), but if you go into Win98 and kill the process, you’ll see your taskbar, desktop icons, right click menu, etc disappear.
File explorer is a part of that process, but consists of additional dynamic libraries and COM components that are loaded on-demand.
Old desktop replacements (like Litestep) specifically modified Windows to block explorer from loading the desktop to replace it (though, would still spawn it for file explorer).
Did you even read the blog post? It's almost a direct quote
> We’re exploring preloading File Explorer in the background to help improve File Explorer launch performance. This shouldn’t be visible to you, outside of File Explorer hopefully launching faster when you need to use it.
explorer.exe is both the shell and the file explorer which is an unfortunate state of affairs.
There's long been an option to make it multi-process, but the cost of that option has increased with every release since 95. If I remember correctly, back in the 95 days that would spawn a new explorer process per window.
These days, probably since tabs or so, when you check this option it spawns exactly one other process, even for many windows. The second process has over 100 threads, the shell process normally spawns around 40 when you open a window, only 20 of which exit immediately when you close the window, the rest stick around for fairly arbitrary periods of time.
Note though about 2/3rds of the threads on my system are rooted in the nvidia driver thunks, I really don't know why so many - is it a side effect of the xaml port?
anyway, no idea what the preloading exactly will be doing, but it does sound like a hack over debt. it'd feel better if there was more process isolation being added to the desktop environment, but you know, it's an old desktop OS, so if one window wants to screw with another window, YOLO! On the flip side making stuff like komorebi is trivial on the platform and there is some nicety to that as long as you trust everything you ever run.
Explorer.exe is technically the Windows UI. File Explorer is a part of that, but has additional COM and other components that it consists of. Those are loaded on demand, now the OS is keeping them resident.