Raymond Chen published a blog post about how a crappy uninstaller on Windows caused a mysterious spike in the number of Explorer (Windows’ graphical shell) crashes. It turns out the buggy uninstaller caused repeated crashes in the 32bit version of Explorer on 64bit systems, and – hold on a minute. The how many bits on the what now?
The 32-bit version of Explorer exists for backward compatibility with 32-bit programs. This is not the copy of Explorer that is handling your taskbar or desktop or File Explorer windows. So if the 32-bit Explorer is running on a 64-bit system, it’s because some other program is using it to do some dirty work.
↫ Raymond Chen at The Old New Thing
So I had no idea that 64bit Windows included a copy of the 32bit Explorer for backwards compatibility. It obviously makes sense, but I just never stopped to think about it. This made me wonder though if you could go nuts and do something really dumb: could you somehow trick 64bit Windows into running this 32bit copy of Explorer as its shell? You’d be running 32bit Explorer on 64bit Windows using the 32bit WoW64 binaries where you just pulled the 32bit Explorer binary from, which seems like a really nonsensical thing to do.
Since there’s no longer any 32bit builds of Windows 11, you also can’t just copy over the 32bit Explorer from a 32bit Windows 11 build and achieve the same goal that way, so you’d really have to go digging around in WoW64 to get 32bit versions. I guess the answer to this question depends on just how complete this copy of 32bit Explorer really is, and if Windows has any defenses or triggers in place to prevent someone from doing something this uselessly stupid. Of course, there’s no practical reason to do any of this and it makes very little sense, but it might be a fun hacking project.
Most likely the Windows experts among you are wondering what kind of utterly deranged new designer drug I’m on, but I was always told that sometimes, the dumbest questions can lead to the most interesting answers, so here we are.
For all the hate Microsoft gets, can we stop and appreciate how flawlessly 32-bit applications run in 64-bit Windows? The only problems are with apps that try to install 32-bit drivers (which obviously fails), such as games that come with StarForce DRM, but otherwise it’s been smooth sailing for me.
Tricks like the one mentioned in the article are the invisible things Microsoft did so you don’t even notice when your 64-bit Windows runs a 32-bit app.
Wish they did the same for win16 apps.
kurkosdr,
Well, they made some particularly bad technical decisions and introduced totally unnecessary complexity and bugs that were very confusing for users. For example software would complain about missing DLLs despite the fact that the files were present exactly where the error messages said they were missing from. Because of those design faults, I won’t give microsoft high marks on it’s handling of the 64bit transition.
Other operating systems handled the transition cleaner without the hacks that would plague windows. Still though, I do agree it’s nice to be able to keep running older software.
For better or worse, AMD decided to drop 16bit from 64bit. The CPU still physically supports 16bit modes but AMD designed x86_64 to disable them from long mode. Obviously Intel were focused on IA-64 (itanium) at the time and didn’t weigh in on x86_64’s design, but it would have been out of character for intel to break backwards compatibility like AMD did. I suspect that if intel’s engineers had designed x86_64 instead of AMD, 16bit mode might still be supported.
Haven’t seen software complain about missing DLLs, must be some really crappy software.
Also, win16 doesn’t run in real-mode (or Virtual8086) in 32-bit Windows, and Wine also supports win16 without using Virtual8086. So, win16 could have been done on 64-bit Windows too.
DOS 16-bit indeed can’t be done on 64-bit Windows without virtualization or emulation of some kind (in fact, Microsoft kind of offered that thing with “XP mode” in Windows 7, since you could spin up a virtualized pre-activated copy of Windows XP 32-bit and run your DOS software there).
kurkosdr,
It wasn’t the software that was defective but that the windows API would lie to 32bit software. Ergo microsoft created these bugs that genuinely didn’t exist before. Of course most of these errors have long since been rectified, but at the time microsoft was at fault for the breakage. It wasn’t just file paths either, some applications using the registry were broken as well. Sometimes software uses both 32bit and 64bit components (like 32bit software with 64bit installer) and in this scenario microsoft’s hacks subvert people’s natural expectations for consistency.
My point is that the hardware has the mode, but AMD chose to disable it from 64bit OS. Of course microsoft could have written an emulator, but being that AMD are the ones who broke the compatibility in native hardware, I don’t blame microsoft for that.
Can you provide an example of such software? Because even horrible disposable code like 32-bit games have no problem running on Windows 64-bit. If some software is using hardcoded paths or registry values that it shouldn’t be using, that’s on the developers.
Hmm… now I am confused. Does otvdm use virtualization or emulation?
kurkosdr,
I could have decades ago, DLL hell wasn’t so uncommon. These days even 32bit software is designed for 64bit windows. It’s more likely to come up with ancient software.
I do have an example though that I hit recently though: cryptolicense is a software activation library that one of my windows clients uses. We discovered that after upgrading to 64bit using the same activation keys, customers with earlier activations stopped working. At first we thought there were bugs with crypto license itself, but when we dug into it microsoft’s 32bit/64bit hacks were the cultprit. Despite accessing the “same path” results were inconsistent because the windows registry API was lying to the software.
Long story short, software publishers are creating workarounds to mitigate these API breakages so that end users don’t have to experience the bugs, but some mitigations may be necessary to compensate for the mess created by microsoft under the hood.
I guess AMD still supports 16bit code may work when virtualizing a 32bit OS under a 64bit OS? I’m not sure but that’s possible.
I don’t know the specifics of what goes on under the surface, I’m primarily a hardware person first, but I can see over time things continue to improve regarding legacy software. I do not know why this is the case, I know it’s something I’ve bleated about long and hard. I suspect there are some significant major players that demand better support for legacy software platforms, and as a result over time I’m seeing improvements across both Win 10 and Win 11. I do know that there are defence systems still running Win 7 because devices were deemed unreliable on Win 10 for whatever reason.
But recently things have improved so much in some cases my biggest hurdle has become convincing end users(customers) it’s safe to finally get off Win 7 or XP.
I’m not saying there aren’t bugs, there are always bugs on any platform, the bugs might be different but at least a more modern base leaves you with some chance of finding longterm solutions for legacy hardware.
OTVDM uses MAME’s 386 emulation core to execute 16- bit code.
The problem is that you have filesystem and registry virtualization…
So your 64bit binaries live in system32, and 32bit ones live in syswow64, but when you run a 32bit program it transparently maps system32 to syswow64 (and the same with the registry).. So if a 32bit program claims that a dll is missing from system32 it actually means its missing from syswow64 but if you run the 64bit explorer and look in system32 you’ll see the 64bit dll of the same name that’s there.
It’s a lot of added complexity, and i’m not entirely sure why they didnt just go for a system64 directory for the new version?
bert64,
Yes exactly.
I’m pretty sure the reason this happened came down to engineers building a 64bit prototype of windows by simply recompiling everything as 64bit without designating any new locations for 64bit resources. Then when it came time to add 32bit software to the working 64bit prototype, they kept the 64bit resources in 32bit locations and created new syswow64 locations for 32bit resources – completely subverting logical expectations. And in order to make this work, microsoft remapped the resources virtually to where is was supposed to be. The end result is dumb and confusing, however I believe this is how it came to be. And they repeated this dichotomy with the registry and program files as well as system32.
With better planning, it would have been sensible to organize DLLs into directories that match what they actually are. This works not just for 32/64bit, but other architectures too. Even new architectures would have an obvious location…
This would have been so consistent, intuitive and logical without having to resort to virtual path trickery. This would even work when emulating software across architectures. Microsoft’s solution added unnecessary complexity, confuses users, and created an unfortunate mess that needs to be maintained indefinitely for backwards compatibility.
Granted, normal users don’t see the mess for the most part. Still though, the more you uncover, the uglier microsoft’s solution becomes.
MS had NTVDM on the RISC versions of NT4 which could emulate x86 and run dos programs, it probably wouldn’t have been much effort to port that to x64 (and ARM) and even with the overhead of full processor emulation a modern CPU should still be able to comfortably outpace the processors that natively ran these 16bit apps years ago.
bert64,
They wanted to maintain both source and binary compatibility with older versions. In other words a 32-bit Win32 program run as is, and if it was to recompile win Win64 as the target, it would still work with no or minimal modifications.
That basically forces them to do this exact solution. Especially if both worlds would live seamlessly together.
Other operating systems, like Linux do not actually provide that level of backwards compatibility, hence, they are immune to those compromises. But then, you cannot run you non-statically linked business software on a modern Linux (or even statically linked ones if they depend on certain X11 or similar behavior)
To summarize:
Many Windows program “hard code” C:\Windows\System32 instead of using the proper API to look that up.
A Win32 program binary that knows nothing about Win64 would still want to write there.
A 64-bit compiled version would still want to write to a folder with the same name,
Hence the only solution is virtualization, unless you want entirely separate worlds.
sukru,
Not for nothing, but Microsoft didn’t need to do this to maintain compatibility. Keep 32bit resources where they already were have naturally achieved binary compatibility with existing software – no hacks necessary.
Even source code compatibility would have been good on 64bit too The need to hardcode system directories in one’s software is extremely rare – I’m not sure if I’ve ever needed to do it. Ironically microsoft’s use of virtual paths probably created more issues than it solved.
The thing is you don’t actually need virtual remapping to have 64bit and 32bit software work seamlessly together. Think about this carefully, it genuinely isn’t needed to achieve an OS that can run different architectures simultaneously. An OS that supports several architectures can have them happily coexist on the same computer with an emulator without needing to deploy virtual file systems for every architecture.
That’s not true though. The library loader needs to know where the correct resources are (64bit software needs to link in 64bit DLLs), but beyond that the vast majority of normal software will never benefit from file system mangling underneath it. Can you even think of a single scenario where it makes more sense to create a fake file system than to use a basic environment variable or define?
I don’t even think microsoft engineers did this on purpose, it was a consequence of having to add 32bit programs back into the 64bit prototype, which inadvertently hijacked the 32bit locations. And rather than go back and rather than fix the new 64bit software, they created a new segregated environment for 32bit software. However it wouldn’t have been technically necessary if they had planned out 64bit windows better.
Not only wasn’t it necessary, but win3.1 supported 16bit and 32bit software simultaneously without relying on virtual file systems. The loader knew which DLLs to link in.
Alfman,
I think you under estimate how many people just hardcode C:\Windows\System32
https://github.com/search?q=C%3A%5C%5CWindows%5C%5CSystem32+language%3AC%2B%2B&type=code
Even today thousands in github do that, even though the well defined paths have been known for ages. I don’t even want to think about all the legacy codebases that had this or one of many other hard coded disk or registry paths
Yes, exactly what I mentioned.
For example:
In a program that will print the number of files in the system32 directory (simplest made up example)
Compile for Win32 -> will look up under SWSWOW64
Compile for Win64 -> will look up under SYSTEM32 (yes, strange name)
So, the other options are:
A. Make a System64 directory (or similar)
This would require rewriting thousands (millions?) of software to update to new paths to compile for x64
B. Make System32 only contain 64-bit code (or a mix of x32 + x64)
Will break binary compatibility with 32-bit software
C. Have “two” System32 folders independent of each other
Will break cross-communication between 32 and 64 bit code.
What else is out there?
sukru,
A few points about that…
1) your query is implicitly cherry picking programs that hard code the path, but that does not imply a statistically significant representation.
2) All 32 bit programs would still have been binary compatible on 64bit windows if they kept system32 for 32bit DLLs, so no compatibility issue would exist there.
3) Zero 64bit x86 programs existed for windows prior to microsoft’s 64bit build. So the fact that these future 64bit programs would need to remove erroneous hardcoded of system32 is a good thing!!! Microsoft invented a new problem for 64bit software that didn’t exist previously. These 64bit programs referencing 32bit directories would never have come to exist if microsoft had used the more sane approach of giving 64bit assets their own proper directory from the get-go. In other words, the fake directory scheme was an underlying cause of this problem that you are now pointing out to me.
?
This does not demonstrate a problem. A program that calls FindFirstFile on the System32 directory SHOULD produce the same identical listing regardless of if the program is x86, x86_64, or even arm_64 or riscv_64… Consistency is NOT a bug! Microsoft’s ends up violating both the user and developer expectation of getting exactly what we ask for,. There wouldn’t be a problem if microsoft did not rely on directory mangling hacks in the first place. They are the cause of the problem. Properly written software would have continued working fine and it would have been an excellent opportunity to get improperly written software fixed on day 1 of going 64bit!
1) Properly written software would require no changes.
2) You are greatly exaggerating the work needed to fix the source code. Hard coding the wrong paths should be treated like any other bug.
3) Improperly written software SHOULD be encouraged to be fixed and no software should ever be encouraged to place files in mislabeled directories. Using the wrong directories doesn’t just create a bad user experience, it creates new incompatibilities. Sure microsoft masks some of this ugliness with file system virtualization to lie to software about where files actually are, but it’s a problem Microsoft themselves created. Endorsing this solution is akin to saying two wrongs make a right :-/
Nobody would think that’s a good idea.
There’s no need to have two system32 directories, honestly that sounds like a solution in search of a problem. Don’t over complicate things: new 64bit DLLs should get a new 64bit directory, everyone’s happy. We can’t get there now that things are so broken, but it wouldn’t be a problem if they did the sensible thing on day one.
Alfman,
I think this is where we differ.
Yes, they should, but they won’t
Let me tell a story why Windows Kernel does not have proper hardening.
During x86_64 transition Microsoft decided to do the right thing, and write protected the kernel pages after system startup. No task could “hot patch” the kernel and it would be secure by design.
Did customers celebrate this?
No
Did security companies appreciate this?
Quite the opposite
Symantec / Norton ran full page ads that claimed how “big bad Microsoft” was blocking their malware…. sorry their “anti virus”. Because they depended on hot patching the kernel like every low effort, low quality software company.
They even took European Union behind them.
What happened?
Microsoft had to relent.
And, the result was a worldwide outage of Windows servers a decade later.
Crowdstrike in 2024 was entirely European Union + Symantec’c doing
Yes, they forced this terrible design on Windows by using government regulation.
Did they take responsibility and apologized for their laziness and greed?
Of course not, they blamed Microsoft for not having proper security!
:giant-facepalm-emoji:
sukru,
Again though the underlying reason they won’t is microsoft’s fault. It was wrong for them to muddy the file system in order to support objectively incorrect paths in future 64bit software that didn’t even exist yet. Suppose that bad paths resulted in broken software the very first time it was built for 64bit. It’s an objective fact that these broken software builds would have gotten fixed or ceased to exist!
Therefore when you say “they should but they won’t”, you need to see things to their logical conclusion. A developer or publisher that doesn’t produce working software would effectively take themselves out of the gene pool so to speak.
We cannot fix this today because a bunch of pre-existing 64bit software would break. But back when 64bit didn’t yet exist, microsoft could have designated a system64 directory without breaking any preexisting software. 100% of new 64bit software would have been compliant with a sensible and logical directory scheme without creating any new incompatibility for users. Microsoft had a perfect opportunity to do the right thing instead of this APIs mess that exposes developers and users to fake file system paths. It’s an ugly hack that’s become a permanent requirement for getting windows software to work. These hacks have to be replicated with wine & proton to run games on linux too.
TLDR; I concede there’s little point in arguing over it now, what’s done is done. But they did miss the opportunity to have resources reside in clear locations without requiring APIs to mangle paths.
I don’t mind talking about this issue separately, but it’s a tangent that doesn’t belong in the current topic.
Alfman,
But… it would never look like it was the developer who produced broken code.
I do remember those times when Windows XP x86_64 was first out for testing. People were already complaining “their software did not run” and blame Microsoft.
Nobody would blame the lazy, entitled… sorry the poor, oppressed devs who had to follow draconian MS rules.
Worse?
Many had hard coded installers and utilities that would write into System32, “%SystemRoot%\System32”, registry keys and what not with now 64 bit copies of things. This would break Windows. But they would not say “I installed this game and their crappy devs broke Steam”, they would say “Windows x86_64 is not compatible with SimCity, and now everything is broken”
I don’t think you realize how bad of a timeline we live in
(These are the people who would click “accept all” on malware)
This is exactly relevant, because it shows crappy devs pushing full page ads and getting powerful support of regulators against Microsoft doing exactly the right thing.
There is a lot of precedent for this.
sukru,
Ironically path mangling was contributing to these problems as I originally pointed out. Fewer problems would have arisen keeping 32bit resources in system32 and using system64 for 32bit resources. All preexisting 32bit software would work fine because no path changes were needed. As there was no pre-existing x86 64bit software to be compatible with, 100% of 64bit software would have been designed to work with microsoft’s new layout for 64bit windows. Everything just works with minimal changes to software. I feel you are being difficult only for the sake of argument, not because there would have actually been a problem.
You are failing to acknowledge that APIs faking paths breaks installer software at the source level too. For example 32bit software is often used to install 64bit software. These installers required developers update them to install 64bit software at the right place. This work needed to be done by developers regardless and Microsoft’s path mangling did not save developers from such work. If anything path mangling only made things more confusing and complex. And microsoft made the situation even worse with “program files” and “program files (x86)” directories that were solutions in search of a problem that nobody had.
To this way 64bit software can be installed at “program files (x86)” and 32bit software can be installed at “program files”. There was little technical justification for segregating them.
Alfman,
There was someone who asked this exact question
https://medium.com/@manojkulkarnimanoj2/why-does-system32-hold-64-bit-files-and-syswow64-hold-32-bit-files-eab96dd9b740
It was not thousands, it was millions of applications that would break.
Alfman,
Anyway, I think we have presented all the arguments for all sides.
sukru,
Firstly, there were literally ZERO x86 64bit applications that would have broke because none existed to break. Every 64bit application would have used the appropriate 64bit paths on windows on day one to be viable. There’s no scenario in which users would have to experience the massive breakages you are claiming.
Secondly,, developers needed to update installers to use the correct paths regardless. Microsoft’s path mangling does not and did not fix the wrong paths used by 32bit installers installing fresh new 64bit software.
Thirdly, you’re making mountains out of molehills. Fixing incorrect paths is low effort and trivial. It makes very little sense to criticize the few minutes it would take to update a path once instead of criticizing the long term complexity, confusion, and mitigations that are now permanently associated with windows.
In an alternative universe where microsoft elected to use sensible directories and no path mangling, absolutely nobody would be calling for system32 to house 64bit resources and syswow64 to house 32bit resources. This silly outcome was a byproduct of a lack of foresight by microsoft early in the development process.
Sorry this is off topic, but slightly related. Under MacOSX If I changed the OS9 finder’s type code to APPL, I could launch the OS9 finder like an App under OSX (using classic). It mostly worked. spring-loaded folders and all at a time when OSX finder was not as fully featured. I would also quit the OSX finder so that the os9 desktop icons would not be covered by the OSX icons.
On Windows the shell is just a registry entry, so replacing it should be a matter of updating that to point to the binary in that SysWOW64 directory. I wouldn’t be surprised if it would just work.
On Windows 11 the default shell actually has quite a lot of issues, especially with the system tray. There is often `winget` available to install another shell to make things significantly more bearable.
As for the answer to the question “Can 32-bit Explorer be the Shell of Windows 11”
The answer is unfortunately no.
It will only support 32-bit shell extensions, and will not know modern desktop APIs (like the new tray). It might “work” as in the sense, you might specify “/separate” option. But not very useful.
(Otherwise it will launch the 64-bit version to delegate, but it will cause a crash loop
https://learn.microsoft.com/en-us/windows/configuration/shell-launcher/)
Did I try this?
Nope, I’m not going to risk my gaming machine becoming a brick.
It works fine… But it will only run explorer.exe (32-bit) as a File Manager, there’s no ‘Desktop Experience’ — and no it won’t brick your system. In fact you can change the Windows Shell to literally anything, even Notepad and bricking your install is virtually impossible as it’s very easy to undo…
On and off since Windows 8 I’ve been running cmd.exe as the Windows shell and now that Windows 11 has become such an onerous “Experience”, with Power Shell as the shell (just like Windows Server). This lets you disable and uninstall a lot of nefarious crap that goes way above and beyond (or below) an insult to privacy and security: Desktop “Experiences”, SystemApps, and eliminating a lot of resource hogging, and telemetry laden Processes and Services.
How to post here :https://forums.mydigitallife.net/threads/slimdown11-%E2%80%93-turn-windows-11-or-ltsc-2024-into-classic-legacy-windows.90039/page-83#post-1909764