masm32 win 10 version

[TouEnMasm]

Works also with:
Microsoft Windows 10 Family Edition: 10.0.10586

[jj2007]

Even more important: It works with Win7-64 and Windows XP :t

[hutch--]

The main fun was tracking down the sequence of error messages. The Win10 emulation of Win32 is good but not without its differences, the old print spooler was incompatible with Win10 and the only solution was to remove it. Apart from some updated binaries, it is nearly identical to the earlier installer and it should work from WinXP upwards. There is nothing to stop it installing on Win2000 but some of the binaries will not display correctly as Win2000 did not support RGB/A image data. I gave up on supporting old graphics by back converting RGB/A to 256 colour as it was a pain to do and looked like crap.

[jj2007]

Btw why do you call it "emulation"??

[sinsi]

https://blogs.msdn.microsoft.com/oldnewthing/20081222-00/?p=19763

[jj2007]

The comments are lovely, as usual. Here's what I get for my system. Still, I find the word "emulation" a bit misleading. The processor is not emulated, it runs in native 32-bit mode afaik...

Code Select Expand

SystemInfo
sinfo.wProcessorArchitecture    0
sinfo.dwProcessorType   586   <-----------
PROCESSOR_INTEL_PENTIUM 586   <-----------
x:sinfo.lpMinimumApplicationAddress     00010000
x:sinfo.lpMaximumApplicationAddress     FFFEFFFF
b:sinfo.dwActiveProcessorMask   00000000000000000000000000001111
sinfo.dwNumberOfProcessors      4

some x64 exe files:
C:\Windows\sysnative\boot\winload.exe
C:\Windows\sysnative\boot\winresume.exe

[Siekmanski]

Code Select Expand

SystemInfo
sinfo.wProcessorArchitecture    0
sinfo.dwProcessorType   586
PROCESSOR_INTEL_PENTIUM 586
x:sinfo.lpMinimumApplicationAddress     00010000
x:sinfo.lpMaximumApplicationAddress     7FFEFFFF
b:sinfo.dwActiveProcessorMask   00000000000000000000111111111111
sinfo.dwNumberOfProcessors      12
some x64 exe files:
C:\WINDOWS\sysnative\boot\winload.exe
C:\WINDOWS\sysnative\boot\winresume.exe

[hutch--]

There are a couple of things involved, the x86 hardware to remain compatible supports everything from 16 bit DOS upwards and it depends on the OS you have installed as to what the native format happens to be. If you are running 64 bit hardware which most do these days AND you install a 64 bit OS, Windows in this case, the base operating system components are all 64 bit which Win32 cannot directly address do due to a range of differences. As 32 bit software will be around for a long time yet, Microsoft had to produce support for 32 bit software and it is done through what is basically a "virtual machine" where the same functions and facilities are exposed so that 32 bit Windows software will run.

Older 32 bit Windows did the same thing with 16 bit Windows applications and could run DOS 16 bit real mode programs with a few limitations and both were done in virtual machines. All an emulation layer is is a virtual machine to run software that is not the native OS type, Win64 PE files are the native type and can directly use the 64 bit OS components and address far more than 4 gig.

[jj2007]

the x86 hardware to remain compatible supports everything from 16 bit DOS upwards

Japheth had a nice exercise showing how to force the cpu into all three modes. Anyway, this looks to me like an attempt of Microsoft to blur the lines between virtualisation and emulation:

When my old word processor runs on Win7-64, the code firmly believes to be run by a Motorola 68000. This is emulation, and it's kind of "slow" because every instruction has to be translated into x86 code (actually it's much faster than the original, which ran at 8 Mega-Hertz).

In contrast, WOW just hooks API calls and exchanges some pointers, but the code is run by the x64 cpu with its x86 subset of instructions - there is no translation at cpu level. That is virtualisation, and in practice it's as fast as "native format" code.

The distinctions are controversally discussed. Search for virtualisation emulation simulation to get an idea.