Does the logo req't of UEFI mean that OEM's can't build 32-bit x86 systems?


  • ....or does it mean that UEFI support is now built into 32-bit x86 versions?

    From my understanding (and a lot of reading from the OEM System Builder website), contract/direct/royalty OEM's, and system builders that sell their systems through distribution need to certify their systems before selling them with Windows preinstalled. 

    If the 32-bit version of Windows 8 doesn't include support for UEFI (Windows 7 and Vista 32-bit didn't), how can they meet the new logo requirement that Microsoft states is to have Native UEFI and Secure Boot enabled in order to sell through distribution?  Does this mean that all logo'd systems have to be 64-bit from now on?  If this is the case, why even bother releasing a 32-bit version of Windows 8?

    What does this mean for all of the corporate machines that still need to be 32-bit for compatibility reasons?  Hyper-V doesn't exactly solve every compatibility issue that is created when you take an OS off bare-metal.

    Saturday, September 24, 2011 5:56 PM

All replies

  • Because UEFI is only supported with a 64Bit Windows (Vista/7) I think that OEM version will be 64Bit only.
    "A programmer is just a tool which converts caffeine into code"

    Saturday, September 24, 2011 6:14 PM
  • UEFI support is from the motherboard. Whether the OEM would sell a Windows on it is another matter (though it does not make sense to get a Windows logo if you are not going to put Windows on it). You may as well install a UEFI capable version of Unix/Linux and still utilize the motherboard's UEFI support.

    The following is signature, not part of post
    Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
    Visual C++ MVP
    Saturday, September 24, 2011 8:52 PM
  • Here's what I know:

    1. "System Builders" buy their "OEM" software and components from distributors, not directly from component vendors.
    2. Higher-level OEM's buy their stuff directly from ODM's and vendors, including Microsoft.
    3. System Builders that build systems and want to sell back through distribution to resellers must certify their systems.  This is made clear on the OEM System Builder website .  If they only want to sell directly to end-users (ie. your neighbourhood PC shop, or the guy down the street) it isn't mandatory - at least, it never was.
    4. High-level OEM's must certify all of their systems because that is part of the contract agreement in buying software licensing through the direct purchase channel.
    5. Secure Boot requires Native UEFI, and UEFI is required for logo certification of systems.
    6. 32-bit versions of Windows Vista and Windows 7 never shipped with UEFI support.  I don't know if this is changing with Windows 8.
    7. If it isn't, no systems sold into channel distribution could ship with 32-bit versions of Windows, unless Microsoft changes the requirements of channel sales and allows uncertified systems to sell into the channel.

    So someone has to officially say whether or not the 32-bit version of Windows will support UEFI.

    This discussion has ABSOLUTELY NOTHING to do with Linux either.

    Saturday, September 24, 2011 9:27 PM
  • I see your point, Joe. 

    It's not too hard to imagine 32 bit Windows being phased out...  Not that much doesn't run on an x64 Windows 7 system now, and how many people with pre-x64 systems will really be wanting to install Windows 8?



    • Edited by Noel Carboni Saturday, September 24, 2011 10:30 PM
    Saturday, September 24, 2011 10:16 PM
  • It's just that Microsoft has already said that "32-bit Windows will be around for a while yet".


    Also, the current ARM processors that Microsoft seems to be targeting for Windows are not going to exceed the Cortex-A15 specification, which means that ARM versions of Windows will probably be limited to 32-bit.  They also said that UEFI would be a requirement for ARM.


    If the ARM version is 32-bit and requires UEFI, and 64-bit x86 supports UEFI (but required for certification), I could see them possibly using similar higher-level codebases for the x86 version - meaning that it would support UEFI for the first time in a 32-bit version.

    • Edited by Joe Raby Monday, September 26, 2011 3:33 PM
    Monday, September 26, 2011 3:25 PM
  • Hello Joe,

    You should review the post below by Steven Sinofsky about Microsoft's view of UEFI. However, he doens't mention anything about 32 bit or 64 bit.
    The Samsung tablet given out at the Build conference the firmware  was designed to allow the customer to disable secure boot.


    Wednesday, September 28, 2011 4:29 PM
  • My understanding is that UEFI and OS have to have the same "bit-edness", and mainstream x86 motherboard vendors are using 64-bit UEFI, so MS decided to support UEFI in their 64-bit OSen only.


    • Edited by DCMonkey Wednesday, September 28, 2011 7:03 PM
    Wednesday, September 28, 2011 7:03 PM
  • It's not too hard to imagine 32 bit Windows being phased out...

    Considering Microsoft's claim that Win8 runs comfortably in 1GB (which i don't doubt), if Win_x86 supported full PAE 36-bit/64GB memory addressing, conceivably MSFT could phase-out the 64-bit client. Assuming well written kernel, drivers and apps, 64GB should be enough for anyone. ;-)

    Seriously, what is the point of 64-bit on the desktop?


    Thursday, September 29, 2011 8:51 AM
  • Seriously, what is the point of 64-bit on the desktop? 

    Well, for one thing I get 10% to 15% better performance in the apps I use with the 64 bit instruction set.


    But beyond that minor gain, I often use single applications (e.g., Photoshop) that need access to gargantuan memory space far in excess of 4 GB.  <Remove personal comment> What's the point of limiting oneself to a 32 bit address space, even if managed adeptly?



    Thursday, September 29, 2011 6:17 PM
  • Noel, i think you misread what i said so you can show off a little.

    Perhaps read this - Licensed Memory in 32-Bit Windows Vista

    Having multiple releases of Windows in both 32 and 64-bit format, plus all the editions, creates a lot of administrative load. For the Win8 release, i request that only 4 editions be available; HomeBasic, HomePremium, Professional, Ultimate. Where HomeBasic is merged with Starter and Ultimate=Enterprise.


    Friday, September 30, 2011 12:18 AM
  • I'm not showing off.  Lord knows I'm not the only one with a 64 bit computer.  Everything is moving to 64 bits.

    I'm thinking it's possible you don't understand how address space works very well, or what the differences are between the 64 bit and 32 bit instruction sets.

    My statement about individual applications needing more than 4 GB of address space is right on target.


    Friday, September 30, 2011 2:49 AM
  • "I'm thinking it's possible you don't understand how address space works very well"

    Your right, i don't understand it very well - just like i could never understand how my 16-bit 8086 CPU could access more than 64KB.


    Friday, September 30, 2011 5:36 AM
  • There are pros and cons of 64/32bit. The only pro of 32-bit is reduced memory footprint and compatability with older CPU's.

    Everything else is stacked in favour of 64-bit. Extra security, speedier processing (depends on the app, but e.g. Fractal Extreme is close to 200% faster for 64-bit versus 32-bit), individual apps able to address more RAM (important for the games we will be playing in 2-3 years, I predict).

    Obviously Photoshop and most every video editing packages will benefit greatly from being able to address >4GB (which they cannot do on a 32-bit system even with PAE and e.g. 16GB installed RAM).

    We could provide some reasoned argument to continue to support 32-bit, but the fact of the matter is that 64-bit is now the standard and 32-bit is increasingly regarded as a legacy platform.

    Friday, September 30, 2011 10:31 AM
  • "MS has been able to manage up to 64 GB in 32-bit systems for something like 15 years already. See these articles."

    Exactly - and the same could be done on the desktop SKUs if MSFT chose to. From the PAE article;

    "The net result is that a 64-bit application might run slightly slower than the same application compiled as 32-bit, but it will often run slightly faster."

    So unless you need more than 64GB, 32-bit Windows would be adequate on the desktop, if the full 36-bit PAE address space were enabled. To restate my point, 64-bit on the desktop could be considered superfluous, if PAE weren't deliberately hobbled, and the security policies and mechanisms of 64-bit Windows were replicated on 32-bit, entirely. For those tiny few who really need more than 64GB, you could buy a Server SKU, which, IMO, should just be considered the next step up from Ultimate Edition anyway.


    Friday, September 30, 2011 11:29 AM
  • "You can't boot that drive without 64-bit UEFI."

    That's true, but again, only because MSFT chose not to implement a UEFI compatible 32-bit Windows for x86/x64 architecture. However, Windows on ARM requires UEFI and ARM is 32-bit. Compatibility with UEFI is not theoretically limited by CPU bitness.



    Friday, September 30, 2011 11:42 AM

  • Some of you folks are talking like a 64 bit application could just be run on a 32 bit Windows system.  Did you neglect to remember that a 64 bit application needs all the 64 bit system calls, DLLs, and support facilities supplied by a 64 bit system to be able to run?

    Microsoft put effort into WOW64 so that 32 bit applications could be run on a 64 bit system.  No such "reverse" facility exists.  I'm not even sure it could be done.  A reasonable person simply wouldn't think of emulating a more powerful system on a less powerful one.

    The basic premise that it's much more work to maintain software for two different instruction sets is simply wrong.  If you had actually written any software you'd realize that well-written source software really is virtually identical and is only recompiled for Win32/x64 (and now ARM).  I have an application with nearly 1000 source files and several hundred thousand lines of code that we initially developed as Win32, and it took us exactly 1 day to get it to compile and run as an x64 app.  Almost no changes were required!  Your entire conversation is based on a flawed fundamental assumption.

    <Removed personal comments>


    Friday, September 30, 2011 1:23 PM
  • Everything else is stacked in favour of 64-bit. Extra security, speedier processing, [...]  individual apps able to address more RAM

    How is that so?

    What extra security is there?  (...beyond MS imposed signed 64-bit drivers).  Speedier processing?  That is actually sometimes exactly the opposite of true.  And with the inconvenience of x86-PAE AWE API, the 32-bit limit is 64 GB.  Are your 64-bit apps using more than 64 GB ?



    (important for the games we will be playing in 2-3 years, I predict)

    You forgot one minor thing.  An economical < 4 GB computer can cost less than a Retail Box Windows.  In 3-4 years, you'll be buying a new computer with Windows 9, with all that money you saved.  Besides, your current computer won't support Windows 9 anyway.

    But if you want to run a decent, practical, economical computer today, with a plain vanilla off-the-shelf 2+ TB hard drive, why must you sacrifice 130 MB or RAM just for the 64-bit bragging rights?   That's what it is boiling down to.  You can't boot that drive without 64-bit UEFI.

    The AWE-API was something I was not previously aware of. It seems somewhat limited, but I'm sure something like Photoshop could be modified to make use of it. It also confirmed my recollection that a process on a 32-bit system can only alloc and access 2GB RAM by itself.

    Why sacrifice 130MB RAM? I agree, I hate to see waste and inefficiency but we are not living in a world where this is the majority view. It's a side-effect of 64-bit binaries that they will inevitibly have a larger footprint than their 32-bit cousins. It's a trade-off I'm actually happy to accept on my little server system with 8GB RAM. My little server runs a few Java tasks, one of which had to have 6GB to itself for a short time. Not something I would have been able to do with a 32-bit OS.

    You can have a 32-bit UEFI, but you then can only boot into a 32-bit OS. Surely it follows then that if there is enough demand in the marketplace, motherboard manufacturers will provide us the option to pick between 32 and 64. There is no real technical reason why this couldn't be a software setting, rather than having to re-flash between BIOS types.

    Friday, September 30, 2011 2:08 PM
  • For what it's worth, I've found most image crunching operations in Adobe Photoshop (doing real things to real images) are about 10% faster on the 64 bit side, even with the same threading.


    Sunday, October 16, 2011 2:32 PM
  • In all seriousness, there are too many factors - system architecture, which Intel processor design is being used, whether operations are compute-intensive vs. data transfer intensive, etc. to make a definitive general statement.  I stand by what I wrote, because it's what I've found.


    But hey, I'm game.  Here's a representative sample run (times measured with a stopwatch accurate to 0.2 seconds) on my Dell Precision T5400:

    • Cold start Photoshop CS5 32 bit from an icon on the desktop:  4.0 seconds
    • Load a large multilayer image (400+ MB on disk) in 14.2 seconds.
    • Smart Sharpen the top layer:  5.2 seconds
    • Upsample to 200% in each dimension:  83.2 seconds.


    Same test, same image, same settings with 64 bit Photoshop CS5:

    • Cold start:  3.0 seconds vs. 4.0 seconds - 25% less time.
    • Load same large image:  13.8 seconds vs. 14.2 seconds - 3% less time.
    • Smart Sharpen same parameters:  4.8 seconds vs. 5.2 - 8% less time.
    • Upsample:  33.0 seconds vs. 83.2 seconds - 60% less time.


    The last bullet item illustrates why 32 bit software is simply no longer viable.  Photoshop, having only between 2 and 3 GB of RAM at the disposal of its 32 bit version had to swap to disk, while the 64 bit version could use more of the system's RAM directly.



    • Edited by Noel Carboni Sunday, October 16, 2011 5:41 PM Vertical spacing to improve readability.
    Sunday, October 16, 2011 5:32 PM
  • Another data point...
    In one of my own commercial graphics applications, which I have instrumented to use high accuracy timing facilities, the timing of some of the color management code as run on a large, deep image:
    32 bit compile:
    13:34:48 : Line 2128: Total Time = 474.505 milliseconds: Performance Message: 'Multithreaded CopyTileWithColorConversion() using 7 threads completed.'

    64 bit compile of the exact same source code:
    13:35:41 : Line 2128: Total Time = 357.365 milliseconds: Performance Message: 'Multithreaded CopyTileWithColorConversion() using 7 threads completed.'


    This is relatively compute-intensive software that does a color-management transform on every pixel of a 16 bits/channel RGB image, and it shows a whopping 25% improvement in speed.


    Sunday, October 16, 2011 5:44 PM
  • MS doesn't permit 32-bit software to access more than 2 GB usermode ram.  Remember.  You could run 32-bit with up to 64 GB, using the x86 PAE AWE API.  Except it violates licensing.

    Having eliminated the MS-imposed advantage of greater memory, does 64-bit mode actually run slower than 32-bit?

    I think you're misunderstanding things, AWE doesn't suddenly allow 32-bit applications to address more than 2GB RAM (or 4GB on a 64-bit OS). All it allows is for you to manually manage some of the paging operations so that you can create a sliding window type effect whereby portions of physical RAM are moved in and out of address space at any one time. It's exceptionally cumbersome to program for and not particularly efficient either, it was really only intended for special-case scenarios like SQL Server running on 32-bit hardware.

    As for whether or not 64-bit code is slower, not really. Code which was optimised primarily for 32-bit systems might suffer slightly because pointers are larger (and thus there is more data to shuffle around). However 64-bit systems have a much larger set of registers and a larger addressable space means you can employ more techniques liike loop unrolling and code expansion without worrying about running into memory allocation issues.

    Sunday, October 16, 2011 8:00 PM
  • I can assure you you weren't, I was writing paging code long before emm386 was a twinkle in anyone's eye.

    As to the apps, Photoshop 64-bit outperforms Photoshop 32-bit in pretty much every case I've ever seen, including sub 4GB machines. Picking arbitrary other applications that don't really doesn't help your case (Fractal eXtreme claims to have hand-tuned assembly, which implies maybe it's not as well tuned as it should be). And whilst only the 32-bit release of IE has an optimised JS engine, the 32-bit build runs faster on 64-bit machines than on 32-bit hardware. As for things like Silverlight, they'll never use AWE extensions anyway since AWE requires significant amounts of manual memory management and that's something you just don't have access to in a completely managed language environment.

    You seem to have already decided that 64-bit must be slower, despite evidence to the contrary (including the fact pretty much every PC on sale in mainstream stores today is 64-bit) and it's not going to go away any time soon.

    Wednesday, October 19, 2011 8:53 PM
  • I need not deconfigure system RAM to make a comparison where Photoshop 32 and 64 bit use less than 2 GB.  Virtually all the measurements I did above except for the one where Photoshop went virtual with the large dataset prove the point just fine.  <Remove personal comments>


    Andy is right; there's no magic way to make a 32 bit app address more than a 2 or 3 GB block of RAM (theoretically 4 GB but that's just not how Windows works) using its 32 bit pointers, outside of doing a bunch of paging/mapping backflips in the application software itself, which is not trivial and is usually inefficient.  This is 35 years of software engineering experience talking.  <Remove personal comments>


    Case in point:  A large RGB image, say, 32768 x 32768 pixels (one gigapixel).  Two bytes per color, 3 colors per pixel and boom, we have one image occupying 6 gigabytes all by itself.  The code to manipulate this image, and find all the data for any given pixel at x, y is very simple if all one has to do is some straight math on 64 bit pointers, but start mapping things and the code to do the work gets wacky in a hurry.

    Simpler code is generally more efficient.



    Thursday, October 20, 2011 4:01 AM
  • <Removed Personal Comments>


    64 bit system designs really do work, and given that 32 bit software works perfectly on the x64 OS, I personally see no need to continue 32 bit versions of Windows too far into the future.  It's just silly, and for what real gain?  At some point virtually every computer that anyone will want to install Windows on will be x64 capable.


    One doesn't have to do system programming, but just application programming to see the advantages of a virtually unlimited flat address space in applications that need access to large sets of data.  Any "scheme" to map more memory via smoke and mirrors is simply outdated.  <Removed personal comments>


    Psst.  Don't look now but powerful yet inexpensive computers with more than 4 GB of RAM are readily available to everyone, and Photoshop has literally millions of users who could somehow afford it.


    <Remove Personal Comments>



    Thursday, October 20, 2011 6:31 PM
  • It doesn't make any difference for performance if Photoshop doesn't need to use the RAM.  The 64 bit software is still faster.  <Removed Personal Comments>


    <Removed personal Comments>


    Thursday, October 20, 2011 9:17 PM
  • Please keep comments on Topic of the issue being discussed in this thread.

    Everyone is entitled to their opinion so please keep your replies professional when responding in this forum.



    Thursday, October 20, 2011 10:21 PM
  • So, does anyone know if Windows 8 32-bit will boot through UEFI firmware ?


    Friday, November 11, 2011 5:14 AM