News for hackers. Stuff that matters.
Re:How to ensure that your program does not run under Window... by Arainach on Wednesday June 03, 2020 @02:54AM (#23400685)
Has, not had. The vast majority of things still work flawlessly, and Microsoft continues to invest serious efforts in this area. I don't have any 32-bit programs on my computer which don't run on Windows 10, and I have plenty of older Win9x-era EXEs of various tools from developers which don't exist any more.
Re:How to ensure that your program does not run under Window... by sterlind on Wednesday June 03, 2020 @03:12AM (#23400782)
Fun fact: You can still run 16-bit programs on 32-bit Windows 10!
Re:How to ensure that your program does not run under Window... by badsectoracula on Wednesday June 03, 2020 @06:09AM (#23401784)
While it isn't Microsoft's work (and Wine has proven that it is technically run most of 16bit programs natively on 64bit), there is Otya128's WineVDM port to Windows[0] that can run 16bit applications in an emulated 386 by stubbing 16bit calls to 32bit ones (so it also relies on the existing Windows backwards compatibility).

Some examples are

https://i.imgur.com/r5aQNyJ.png - Smalltalk Express

https://i.imgur.com/W9ES2fg.png - Delphi 1

https://i.imgur.com/VLSglAK.png - Windows 1.0 port of WineMine

https://i.imgur.com/OLq2gLm.jpg - The Exile series of RPGs

https://i.imgur.com/e26mqWP.png - MicroLathe (though that one does a segfault every time it renders... but it catches it and allows continuing use of the program)

While these programs are fun to play around with (especially Smalltalk Express), another use for this is to run the setup of older (32bit) applications that used a 16bit stub (Microsoft does have a few replacement stubs for some very popular installers but there are many other - and other versions - that are not there... and funny enough, AFAIK this project relies on the code Microsoft added to check for 16bit installers to run any 16bit program :-P).

[0] https://github.com/otya128/winevdm/

Re:How to ensure that your program does not run under Window... by swiley on Wednesday June 03, 2020 @04:50AM (#23401381)
How hard is it to install 32-bit windows 10 on a modern computer? I wouldn’t want to run that on an actual 32-bit only machine.
Re:How to ensure that your program does not run under Window... by kirb on Wednesday June 03, 2020 @05:00AM (#23401440)
It’ll work, may have to disable secure boot/enable legacy BIOS mode though. Of course you’ll be limited to 4GB RAM and there may be software you use that’s gone 64 bit-exclusive in the past few years.
Re:How to ensure that your program does not run under Window... by exikyut on Wednesday June 03, 2020 @05:52AM (#23401694)
> you’ll be limited to 4GB RAM

This made me curious, so I did a bit of digging, and found https://docs.microsoft.com/en-us/windows/win32/memory/physic... (quoted out of order for simplicity):

> Windows automatically enables PAE if DEP is enabled on a computer that supports hardware-enabled DEP, or if the computer is configured for hot-add memory devices in memory ranges beyond 4 GB. If the computer does not support hardware-enabled DEP or is not configured for hot-add memory devices in memory ranges beyond 4 GB, PAE must be explicitly enabled.

> PAE does not change the amount of virtual address space available to a process. Each process running in 32-bit Windows is still limited to a 4 GB virtual address space.

So, TL;DR, what you said :). But I'm glad I checked!

Re:How to ensure that your program does not run under Window... by bcaa7f3a8bbc on Wednesday June 03, 2020 @08:44AM (#23402688)
Under PAE, each process is still limited to a 4 GiB address space, but the total usable physical memory is extended beyond 4 GiB.

Unfortunately, PAE on Windows is a sad story. Unlike what the knowledge base said, in practice, you cannot use PAE for this purpose on Windows. Officially, PAE is only supported on Windows Server, and unusable on desktops.

Technically it's supported and almost always activated by Windows (since PAE is needed for the NX bit / DEP). But on desktop systems, Microsoft intentionally crippled PAE by locking the maximum memory to 4 GiB by a software license restriction [0]. Microsoft didn't do it because it wanted to force you to buy licenses, but due to compatibility problems, especially, all types of device drivers are problematic. Using more memory requires patching the kernel to bypass this license restriction, with unpredictable consequences due to incompatibilities.

TL;DR: PAE on Windows is practically useless.

[0] https://en.wikipedia.org/wiki/Physical_Address_Extension#Mic...

Re:How to ensure that your program does not run under Window... by Dylan16807 on Wednesday June 03, 2020 @09:08AM (#23402906)
So some important notes here:

* PAE is technically enabled on most machines, but only for side effects like DEP, and there's a software lock on using more than 4GB memory.

* Via either spending lots of money or patching some files, you can get a 32-bit version of windows to use 64GB of memory. As long as your drivers don't explode.

* "4GB virtual address space" is a bit misleading. A normal 32-bit process can only use 2GB on 32-bit windows. (or 3GB if you change some settings) The upper part of the address space has to be reserved for the kernel. If you want the entire 4GB for your process, you have to run it on 64-bit windows.

As long as you can make it work, getting windows to recognize more memory despite per-process caps is a massive improvement and "limited to 4GB RAM" really undersells it.

Re:How to ensure that your program does not run under Window... by im3w1l-alt on Wednesday June 03, 2020 @07:24AM (#23402176)
Modern processors still know how to run 16 bit code.
Re:How to ensure that your program does not run under Window... by Dylan16807 on Wednesday June 03, 2020 @08:41AM (#23402662)
The issue is drivers, not the CPU.