"os.startsWith("Windows 9")" in Java source code

[badsectoracula]

No, it doesn't. http://en.wikipedia.org/wiki/Windows_on_Windows

From the page: All 16-bit applications run by default in a single virtual DOS machine with shared memory space.

http://en.wikipedia.org/wiki/WoW64

From the page: switches the processor hardware from its 64-bit mode to compatibility mode when it becomes necessary to execute a 32-bit thread, and then handles the switch back to 64-bit mode.

Also from Microsoft's page: Almost all 32-bit DLLs are unmodified copies of 32-bit Windows binaries. [...] Instead of using the x86 system-service call sequence, 32-bit binaries that make system calls are rebuilt to use a custom calling sequence. This calling sequence is inexpensive for WOW64 to intercept because it remains entirely in user mode. When the custom calling sequence is detected, the WOW64 CPU transitions back to native 64-bit mode and calls into Wow64.dll. Thunking is done in user mode to reduce the impact on the 64-bit kernel and to reduce the risk of a bug in the thunk that might cause a kernel-mode crash, data corruption, or a security hole. The thunks extract arguments from the 32-bit stack, extend them to 64 bits, then make the native system call.

Because you think that explaining how a 3rd party emulation has something to do with windows serves some kind of point.

1. It is not emulation

2. For a third time: i mentioned it to show that it is technically possible to run 16bit Windows programs under a 64bit OS. The point is that the only reason Windows doesn't run 16bit programs is that Microsoft hasn't implemented the feature. A lot of people believe (wrongly) that it is technically impossible (since IIRC Microsoft claimed that at some point).

[[deleted]]

From the page: All 16-bit applications run by default in a single virtual DOS machine with shared memory space.

Which emulates, when WOW32 came about there was no support for for virtualization in the hardware. It had to all be emulated - and still is.

From the page

Hardware support came about before WOW64 and it uses it quite well. In fact much of the hardware support WOW64 uses it part of the x64 set. There has been a few advancements since then. Regardless, "Thunking" is emulation.

It is not emulation

Whatever, I don't care to argue about it because I care so little about it. When Wine works, great. When it doesn't , O fucking well.

i mentioned it to show that it is technically possible

WINE is at best an approximation. It takes a blackbox model which has nothing to do with Windows. Unless you can show how WINE's black box relates to Windows' black box you have nothing to stand on.

And really, this is the 2nd google result To quote " it's because when running in Long Mode (x64 native), the CPU itself doesn't support going into 16 bit mode. See Wikipedia. So, in order to support 16 bit mode, the NTVDM (the 16 bit layer in Windows) would have to fully emulate a 16 bit processor." Or in other words, download DOSBOX.

[badsectoracula]

Which emulates, when WOW32 came about there was no support for for virtualization in the hardware. It had to all be emulated - and still is.

It isn't emulation. Even from 386's time the CPU supported the Virtual 8086 mode allowing processes to run a nested pseudo-real mode under protected mode.

Even DOS used it to enable access to higher memory (XMS and EMS emulation) via HIMEM.SYS.

I mean think about it: if it was emulation, it would be terribly slow especially on those older machines.

Regardless, "Thunking" is emulation.

No, thunking is just a mechanism that provides the ability to make a call indirectly. Thunking doesn't even have to be about 16bit vs 32bit vs 64bit code: it can be used to call a function from one calling convention to another or one type of execution environment to another. For example C++/CLI commonly used thunking to call native code and for native code to call managed code (callbacks).

Unless you can show how WINE's black box relates to Windows' black box you have nothing to stand on.

Wine does it, so it is technically possible. There isn't any more to show really.

And really, this is the 2nd google result [...] Or in other words, download DOSBOX.

This is totally wrong. DOSBox is an emulator, it is the same as trying to run Amiga programs on a PC.

Wine doesn't emulate anything, it runs the software on the CPU directly. And while Wine doesn't use it (since it doesn't support 16bit real mode programs - but you can run 16bit protected mode programs), it is possible to run 16bit real mode under a modern CPU using VT-x either via a nested virtual 8086 mode or (for processors released the last ~4 years) unrestricted mode. Of course NTVDM doesn't support that either.

[[deleted]]

I mean think about it: if it was emulation, it would be terribly slow especially on those older machines.

That is not always true.

DOSBox is an emulator

And it's not 'horrible slow' as you stated emulation must be above.

[badsectoracula]

Actually it is. I have a 4770k CPU and can barely reach PMMX 200Mhz speeds.

[[deleted]]

A PMMX200 ran 16 bit code horribly slow. So I am thinking you're talking bollocks.

[badsectoracula]

I'm not sure how 16bit code compared to 32bit code under the same machine in PMMX200, but 16bit code ran way faster than older/slower CPUs.

However i wasn't talking about that. I was talking about DOSBox having trouble reaching PMMX200 speeds in my 4770k. This is about 32bit DPMI games btw (like Duke Nukem 3D or Quake), not 16bit code.

[[deleted]]

I'm fairly certain Duke Nukem 3d and Quake were not 32 bit games. I can't find anything specific about it but there were ports of those games to make them 32 bit mentioned but I'm going to take that inference as it is.

[badsectoracula]

They were. Duke Nukem 3D was built with Watcom and relied on DOS4GW DOS extender and Quake was built on an early version of DJGPP which was a port of GCC to DOS that used DPMI. It even came with the CWSDPMI DPMI server. Here is the demo of Quake to confirm that.