Microsoft plan to split OS from shell takes shape(zdnet.com)
zdnet.com
Microsoft plan to split OS from shell takes shape
https://www.zdnet.com/article/windows-10-yields-more-secrets-microsoft-plan-to-split-os-from-shell-takes-shape/#comments-fc9984be-5a89-4ec6-a980-496937d746e4
2 comments
Hasn't this always been the case already? Explorer.exe is just an executable. It has always been replaceable and therefore independently updateable.
Explorer.exe hasn't been "the shell" in a few versions of Windows now, and never as directly in any of the Windows NT family (XP+) like it was to Windows 95 [1]. For instance, the taskbar and start menu have moved into an application that Taskbar calls the "Windows Shell Experience Host".
But the big issue here is not just making the Shell replaceable, and not even just replaceable at runtime (switching/reconfiguring Shells on the fly; which was not something that was possible even in the Windows 95 INI days), but also presumably a lot more about the Windows build and deployment infrastructure. Up to this point the Shells are built together with the rest of Windows, baked into the Windows image, and deployed together as a single versioned unit (one build of Windows). Sure maybe it is just an "unsexy" "refactoring" of existing components to be more component like, and try to minimize coupling between specific versions of them, but my DevOps hat certainly thinks it sounds like a lot of work for a codebase as old and large as Windows.
[1] Windows 95 did use Explorer.exe for just about everything, and many people do remember that for compatibility reasons it supported changing the "Shell" EXE in an INI file, and you could change it into the Ghost of Windows 3.1 PROGMAN.EXE or some alternatives shells supported that. That INI has never been in the Windows NT side of the family (XP+).
But the big issue here is not just making the Shell replaceable, and not even just replaceable at runtime (switching/reconfiguring Shells on the fly; which was not something that was possible even in the Windows 95 INI days), but also presumably a lot more about the Windows build and deployment infrastructure. Up to this point the Shells are built together with the rest of Windows, baked into the Windows image, and deployed together as a single versioned unit (one build of Windows). Sure maybe it is just an "unsexy" "refactoring" of existing components to be more component like, and try to minimize coupling between specific versions of them, but my DevOps hat certainly thinks it sounds like a lot of work for a codebase as old and large as Windows.
[1] Windows 95 did use Explorer.exe for just about everything, and many people do remember that for compatibility reasons it supported changing the "Shell" EXE in an INI file, and you could change it into the Ghost of Windows 3.1 PROGMAN.EXE or some alternatives shells supported that. That INI has never been in the Windows NT side of the family (XP+).