5

I want to completely disable the whole syswow64. My goal is to make it impossible to run any 32-bit application, or load any 32-bit DLL on a 64-bit windows system. Similarly to the old 16-bit Windows applications, which can be emulated on some old 32-bit system, but not any more on 64-bit.

On Linux, I can simply disable the 32-bit emulation either in the kernel compilation config or by some sysctl settings. But what can be done on Windows?

Is it somehow possible?

I know, that any 32-bit program—and maybe some 64-bit—won’t work any more, but it is not a problem to me. Actually, it is my goal.

The goal is to experiment in a 64-bit only Windows environment. Initiating a debate about its usability, or it is needed or not, is highly offtopic here. I want a solution, not a debate.

Giacomo1968
  • 53,069
  • 19
  • 162
  • 212
peterh
  • 2,553
  • 10
  • 31
  • 49
  • What's the reason for doing this? Why do you want to disable 32-bit? I'm sensing that you're actually having an X problem, but since you think that Y will solve the problem, you're instead asking for Y. What's the X? – Lie Ryan Feb 21 '15 at 17:42
  • That's not the root reason, why do you need to experiment with 64-bit only environment? All x86_64 CPUs includes native support executing 32-bit code, it's not something you can turn off. There is no emulation, no mode switch, they are run natively because the 64-bit instruction set is a superset of the 32-bit instruction set. This is of different nature than 16-bit windows applications, which is a DOS mode that had to be run on a different CPU mode (Legacy Mode) that has no memory virtualization. Essentially, 16-bit application was running on a different operating system. – Lie Ryan Feb 22 '15 at 01:29
  • 1
    What benefits do you think you could get by preventing non 64-bit aware program from running? – Lie Ryan Feb 22 '15 at 01:31
  • 1
    @LieRyan Unfortunately, this question wasn't about it is needed or not. This question was about, how can I reach that. I didn't said my goal, because I wanted to avoid exactly what you did: that somebody comes here and says exactly, what you said - instead of he gave my a better option as to switch to win2k8 server. If I want a pointless debate about the usability of the 64bit-only systems, I will ask a such question. Unfortunately, I didn't have any better option as to sign your comments as "not constructive" and as "offtopic". Now please, go away. – peterh Feb 22 '15 at 02:38
  • Does comment #2 (after the 1st sentence), not answer the question? (You can't eliminate 32 bit support because it is the core of the 64 bit support.) You could simply not put any 32 bit application or DLL on the computer. – fixer1234 Feb 22 '15 at 03:04
  • @fixer1234 It is factually false - running a 32-bit app requires from the OS to create a 32-bit memory map, and load 32-bit dlls into that. Next to that, the 32-bit mode of the intel cpus has and uses extensive segmenting, while in 64-bit mode the segmenting functionality of the cpu is very limited. If the (64-bit) OS doesn't enable this, if the (64-bit) OS doesn't have the support to bridge over this differences, the 32-bit apps won't work. – peterh Feb 22 '15 at 03:08
  • @fixer1234 It doesn't matter, what is coming from the marketing division of the micro$oft, how do they reason that they are _INCAPABLE_ to port their 32-bit software to their own 64-bit OS, the truth is that running 32-bit apps on a 64-bit os IS emulation, at least in the sense that they are running in a non-standard, simulated environment. – peterh Feb 22 '15 at 03:12
  • @fixer1234 Unfortunately, SYSWOW64 is there, it comes with windows. And, except win2k8 server, it can't be even uninstalled. Of course, I can avoid to install any 32-bit, (or check their existence from task manager and exterminate them if I find one), but I had been more happy with a cleaner solution, for example with a not-so-advertised registry setting or such. – peterh Feb 22 '15 at 03:19
  • I voted your question +0 because you refused to answer Lie Ryan's comment, above. – unforgettableidSupportsMonica Mar 20 '17 at 02:05
  • @unforgettableid I answered it. And this is what I can say even today: in 2017, I can't see any reason why should be ancient, 32-bit softwares *enforced* to me. Fortunately, I don't have to use m$ technologies since then, and my Linuxes are all full 64-bit only. For example, as an MSVS developer explains, [there won't be ever 64-bit MSVS because they are lazy to develop it](https://blogs.msdn.microsoft.com/ricom/2009/06/10/visual-studio-why-is-there-no-64-bit-version-yet/), I can't decide I should whine or laugh. – peterh Mar 20 '17 at 02:11
  • @peterh: A) You replied to Lie Ryan, but AFAICT, you didn't really answer. B) The Visual Studio GUI can be 32-bit; GUIs aren't CPU-intensive. Really all you need is a 64-bit compiler, since compilation is CPU-intensive. – unforgettableidSupportsMonica Mar 20 '17 at 02:27
  • @unforgettableid No. I only want a world free from volunteer m$ salesmen, that is all. Our debate is over. – peterh Mar 20 '17 at 02:36
  • @peterh: Your second-last comment was deleted. You may want to therefore also delete your last comment. – unforgettableidSupportsMonica Mar 20 '17 at 02:48
  • @peterh: I never said that 32-bit is better! In fact, for CPU-intensive tasks, I'm sure that 64-bit is definitely better. But what do you gain by preventing old 32-bit-only apps from running? P.S. I happen to like Linux. – unforgettableidSupportsMonica Mar 20 '17 at 02:48
  • 1
    @unforgettableid 1: mixed 32/64 code segments can't live in the same address space, they have to use some IPC mechanism to cooperate, this causes various intra-app **compatibility** problems 2: 32-bit processes have to use a lot of 32-bit dlls, essentially a 32-bit copy of w$, running with the 64-bit host system together 3: it is a **very clear signature** of the total incompetence of the m$ development 4: and yes, there is also the 4G per-process address space limit. – peterh Mar 20 '17 at 02:53
  • @unforgettableid Everybody knows this very well in the industry. The only reason why m$ *is allowed to be lazy* and avoid to port everything to 64-bit since the first 64-bit windows (note: linuxes are 100% 64-bit since the first ones), is that programmers are using windows mostly not because they like it, they use it because it is *enforced* to them. I am one of these programmers, this is why I am now a little bit... hmm... nervous. – peterh Mar 20 '17 at 02:56
  • @unforgettableid My second reason, why I was annoyed, and why I tried to close out the debate in the last sentences of my question, was that I know from experience: if I ask anything into the *"how to remove 32bit things from windows"*, a hird of m$ advocates appears on the spot and they start to explain, in the similarly incompetent style of the m$ phone support, that *"32 bit is just so well as 64 bit, you don't need it"*. The 2 downs I've got for my question, were from these people, too, I knew this that they will appear and they will downvote, and I lived with it. – peterh Mar 20 '17 at 03:02
  • @unforgettableid Note, it is not their first similar thing. Remember the time of the win98 era, as winNT couldn't read fat32 partitions, and win98 couldn't open NTFS? *Two OSes came together from the same company and they couldn't read eachother's disks!!!!* Of course the m$ advocates and the very polite but totally incompetent m$ phone support said at the time: *"You don't need it, you can copy files from NT to Win98 with the w$ file sharing!"* This is second thing, what I, as a *customer* really hate: if I want X thing, then I want X thing, and not nice explanations from incompetent – peterh Mar 20 '17 at 03:08
  • @unforgettableid salesmen why I don't need it. No company could survive with such a product "quality" like m$ without continuous monopolistic power misuse and dirty behind-the-wall tricks. My question targeted to *fix* one of their most dirty, present problems. It is also the reason, why the m$ phone became such a catastrophe (for them, I am happy that I have androids everywhere) for the company. Not because "Ballmer reacted too late for the upcoming mobile world", what leaded to his firing, Ballmer did this part imho well. The m$ lose the mobile segment because – peterh Mar 20 '17 at 03:13
  • @unforgettableid nobody wanted to develop for a phone where you need m$ audited encryption keys and registration to run *your own programs on your own phone*. Well, yes, apple does the same, but from a small company (compared to m$ at the time) it was so or so tolerable. – peterh Mar 20 '17 at 03:15
  • @unforgettableid To be offtopic again: You can't buy a new CPU without 64-bit support since around 2003. You can safely turn off the 32-bit support in any 64-bit linuxes since around 2004. Now we are in 2017, and you still can't have a productively used w$ without 32-bit apps, simply because *they weren't developed*. And not anybody, *but a developer of the m$ visual studio, on an official microsoft blog site, has page-long explanations that there won't be ever 64-bit msvs because "you don't need it"*. – peterh Mar 20 '17 at 03:25
  • @unforgettableid Of course you can't simply turn off the 32-bit support from a 64-bit windows. In linux, it is 1 command. In Windows, it is impossible. You should make the SYSWOW64 somehow unusable (note: 32-bit w$ lives in C:\Windows\SYSWOW**64**, while the 64-bit windows lives in C:\Windows\system**32**, very logical, congrat m$ again!), and then somehow disable the internal windows feature what would automatically restore it. It would be impractical and dangerous even for a hardcore w$ hacker. – peterh Mar 20 '17 at 03:35
  • @peterh it should worth noting the 64 bit version WinPE used to install Windows from bootable ɪꜱᴏ or with the Windows recovery environment doesn’t support running 32 bits application at the ᴏꜱ level (and not only because lack of UserLand) when the command prompt is launched. I mean it’s stripped of the feature in the way you’re looking for. – user2284570 Jul 20 '19 at 20:44
  • @user2284570 Thanks, nice to know! Some parallel, non-MS windows repackaging would be imho quite useful. However, today I think, not the extermination of the 32-bit subsystem is the best for a windows, at least on client system. Instead, a 32-bit windows version with an enforced PAE feature could be better (until the need for 3G per-process adress space, or 64 GB physical RAM won't be common). Although fortunately today I don't need to use windows so much, to start to experiment with it. My home linuxes are now all 32-bit PAE systems. – peterh Jul 20 '19 at 22:40
  • @peterh hey, I found what you’re looking for, this is a feature of Windows Server core : the feature name which can be enabled or disabled is called `ServerCore-WOW64`. But I think it should be possible on other Windows as by definition it’s a Subsystem which is not native (so too is Win64) and that all subsystems are optional. I think your question would fit better on ServerFault. – user2284570 Jul 21 '19 at 08:36
  • @peterh 32‑bits Windows xp Service pack 1 supported ᴘᴀᴇ for addressing and so give the possibility of addressing more than 4Gb of Ram on a 32 bits system. It was removed in later versions of Windows and service packs because many third party drivers weren’t supportting this and were crashing the system. But ᴘᴀᴇ remains used for many Windows security features : it’s just no longer possible to use it for larger ʀᴀᴍ. Though they are hex editor hacks ro remove this limitation up to Windows 8. – user2284570 Jul 21 '19 at 08:44

2 Answers2

4

The bruteforce method would be to use an AppInit DLL whose 32 bits version crashes on load. Since every 32 bit process would load it, they all crash before startup. No direct harm to 64 bits programs as they'd refuse to load the 32 bit DLL anyway, but of course all those 32 bit installers will refuse to run etc.

MSalters
  • 8,185
  • 1
  • 23
  • 29
  • Wonderful solution (maybe a little bit really brute). Can I guarantee for a such dll to load _always_? – peterh Feb 19 '15 at 16:34
  • I'd be confident that if it works once, you'll get at least 99% success. Possible exceptions: Microsoft processes, things running under `SYSTEM` account, etc. – MSalters Feb 19 '15 at 22:27
  • Maybe a crash weren't needed, only an `exit(0)` - equivalent of the windows api? – peterh Feb 19 '15 at 23:40
3

The simplest method of achieving this is not allowing applications to be installed by normal users. If you only install 64-bit applications, then only 64-bit applications will be running, except those 32-bit processes still used by Windows, of course.

It isn't possible to disable the WoW64 subsystem, which isn't "emulation", on a consumer version of Windows. It is possible with Windows Server. I am going to assume it is a Windows Feature on Windows Server which can simply be disabled. The linked article provides the command, which is version-specific for an older version of Windows Server.

Ramhound
  • 41,734
  • 35
  • 103
  • 130