Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Tuesday October 19 2021, @04:06AM   Printer-friendly
from the 2021's-Pentium-Bug dept.

Windows 11 hardware requirements made a mockery of by an Intel Pentium 4 processor

As the screenshots below show, Microsoft considers the Intel Pentium 4 661 a supported processor. Intel released the Pentium 4 661 in early 2006, with a solitary core to its name. Apparently, Microsoft forgot to add any Intel Family 15 (Netburst) SKUs in its unsupported processors list for Windows 11.

Hence, the PC Health Check tool sees that the Pentium 4 661 has a 3.6 GHz boost clock, which satisfies one of Windows 11's requirements. Curiously, the tool states that the Pentium 4 661 has two or more cores, even though it lists it as having one.

@Carlos_SM1995 has even got Windows 11 (Build 22000.258) running on a Pentium 4 661. Supposedly, Windows Update still works too, highlighting the ridiculousness of Microsoft's overtures regarding Windows 11 compatibility.

Windows 11 final (Build 22000.258) running on Intel Pentium 4 (11m4s video)


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Informative) by DannyB on Tuesday October 19 2021, @04:44PM

    by DannyB (5839) Subscriber Badge on Tuesday October 19 2021, @04:44PM (#1188451) Journal

    Consider the configuration nightmare. How many different duplicate sets of routines do you want Windows to have? Consider just the Kernel for a second. How many different permutations of Kernel should Microsoft compile for? There are different dimensions of features that a processor may or may not have.

    Now that said, let me digress a moment and point out where Java wins hands down on processor compatibility. See this journal article: It's fashionable to hate Java [soylentnews.org], where I explain about the C1 / C2 native compilers.

    Summary:

    Your JVM bytecode starts up being interpreted. As soon as a function is identified as using disproportionate CPU, it gets immediately compiled quickly by the C1 native compiler into much faster but not optimal code. It is also added to a list of functions to be recompiled by the native C2 compiler soon. When the C2 compiler comes around, it will spend significant time and effort compiling your function to native code. C2 can take advantage of things known only at runtime, which cannot be known ahead of time, such as a C compiler. For example, maybe this one method call does not actually need to be a virtual call going through a vtable. There is only one instance of a subclass ever, at all in the entire program. And many other optimizations an ahead of time compiler cannot know. In particular, and of specific relevance here is that the C2 compiler can compile your function to the exact instruction set of the hardware it is currently running on. Does your processor have this or that other set of vector extensions? Or this or that other coprocessor, or some other feature? The code is compiled to the exact processor you are running on. Whether it is Intel, AMD, or even a different architecture, ARM (many flavors), Power PC, even IBM mainframes, etc.

    Thus, Java programs start up slow, then seem to "warm up" and run fast. This is great for a program that will run for a long time and wants excellent performance. It is horrible for quick command line programs such as 'ls'.

    --
    The anti vax hysteria didn't stop, it just died down.
    Starting Score:    1  point
    Moderation   +3  
       Informative=3, Total=3
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5