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.

26
  • 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, 2015 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, 2015 at 1:29
  • 1
    What benefits do you think you could get by preventing non 64-bit aware program from running?
    – Lie Ryan
    Feb 22, 2015 at 1: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, 2015 at 2:38
  • 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, 2017 at 2:53

2 Answers 2

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.

1
  • Normal users can still run portable apps, even if they can't install anything, unless you lock the machine down well. Mar 20, 2017 at 2:50
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.

3
  • Wonderful solution (maybe a little bit really brute). Can I guarantee for a such dll to load always?
    – peterh
    Feb 19, 2015 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, 2015 at 22:27
  • Maybe a crash weren't needed, only an exit(0) - equivalent of the windows api?
    – peterh
    Feb 19, 2015 at 23:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .