Question Basic OS Questions

Page 6 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.

TheFlash1300

Proper
Mar 15, 2022
277
4
185
0
When was the last motherboard, that is compatible with Windows 7, produced? What is its name?

Is any motherboard, that was produced before 2020, compatible with Windows 7?
 

DSzymborski

Titan
Moderator
You have been opening up an obscene number of threads (19 in four days) which is bad enough, but now many of these entirely new threads to ask slight variants of questions and questions you've already asked in previous threads.

This thread-spamming must stop, and it will whether it's voluntary or involuntary. These forums are not a substitute for Google searches. People are happy to provide assistance, but you're pushing this to absurd limits.
 

Colif

Win 11 Master
Moderator
Jun 12, 2015
56,762
4,517
160,690
10,275
what i suggest is if you have questions, put them all in the one thread as then you don't get conflicting answers. Also makes it easier to fix things as I see people ask 1 question then a week later another closely related to previous. Some people its many threads that all seem to relate to same problem, they just haven't worked out what it is yet.
 
Since I saw the whole running 16-bit applications on 64-bit thing...

For one, x86-64 CPUs can execute 16-bit code and can switch between them freely (see https://en.wikipedia.org/wiki/X86-64#Operating_modes). However, running 16-bit code while in 64-bit mode requires the application to be compatible with 16-bit Protected Mode, which wasn't a popular x86 execution mode. Most people went straight to 32-bit Protected Mode.

So if an x86-64 CPU can execute 16-bit code even in 64-bit mode and even then can switch to a 16-bit operating mode, why can't 64-bit Windows execute 16-bit applications? It's this (from https://docs.microsoft.com/en-us/windows/win32/winprog64/running-32-bit-applications):
Note that 64-bit Windows does not support running 16-bit Windows-based applications. The primary reason is that handles have 32 significant bits on 64-bit Windows. Therefore, handles cannot be truncated and passed to 16-bit applications without loss of data.
A handle is basically a reference to a system resource. In previous versions of Windows, the handle limit per process was supposedly 10,000, but Microsoft's official documentation says the limit can be as high as 65,356 for 32-bit applications. Either way, this value fits in a 16-bit value. This limit was apparently raised to 16,777,216 at some point, which requires at least 24-bits, so the handle value was bumped up to at least 32-bits at that point. It's likely 32-bit applications treated the handle number as a 32-bit value by default even if the maximum value would never exceed 16-bits. However, 16-bit applications would've treated this as a 16-bit value, or at least, they expected a 16-bit value. So if it got a value that exceeded 16-bits, then it presents a problem because you can't chop off the upper 16-bits as that could mean another handle.

Note that WINE supports running 16-bit applications on 64-bit kernels without needing to resort to virtual machines or whatnot. Microsoft could've done whatever WINE was doing, but they probably decided that supporting 16-bit applications in Windows wasn't worth their time and used the quoted text as their excuse.
 

ASK THE COMMUNITY