I was really surprised to learn that it requires PE executables and Windows' custom x64 calling convention. I know it's just a small technical detail for booting ... but it's kind of scary that Microsoft had so much sway in the design of how our future PCs will boot =(
typedef struct _WIN_CERTIFICATE {
DWORD dwLength;
WORD wRevision;
WORD wCertificateType;
BYTE bCertificate[ANYSIZE_ARRAY];
} WIN_CERTIFICATE, *PWIN_CERTIFICATE;
UEFI has a shockingly simmilar structure [1, page 1812]: typedef struct _WIN_CERTIFICATE {
UINT32 dwLength;
UINT16 wRevision;
UINT16 wCertificateType;
//UINT8 bCertificate[ANYSIZE_ARRAY];
} WIN_CERTIFICATE;
[0] https://msdn.microsoft.com/en-us/library/windows/desktop/dn5...[1] http://www.uefi.org/sites/default/files/resources/UEFI%20Spe...
> PE is a modified version of the Unix COFF (Common Object File Format). PE/COFF is an alternative term in Windows development.
However, there's little information on its license (it says it's a standard currently developed by Microsoft, but that's about it). And COFF is pretty much the same, but older and developed by AT&T[1].
Still, compared to other Microsoft "products of old"[2], there's a surprising ammount of documentation and analysis into the PE format.
[0] https://en.wikipedia.org/wiki/Portable_Executable
[1] https://en.wikipedia.org/wiki/COFF
[2] I don't compare it to the newer open source stuff because it'd be unfair.
[3] https://msdn.microsoft.com/en-us/library/ms809762.aspx -- I was going to link a few other articles (some from the References section of Wikipedia) but most seem to be broken now. Still, there are some interesting paperes from digital forensics people that analyze in-depth the PE format, mostly for malware scenarios.
But even then, segmentation is not an issue.
32 bit Windows 10 is 4GB smaller than the 64 bit version. This matters on cheap tablets and netbooks that come with <32gb of MMC storage. I've heard that 32 bit OEM licenses are also slightly cheaper, but I can't find confirmation of that.
https://blogs.intel.com/evangelists/2015/07/22/why-cheap-sys...
I intentionally leave off the 32-bit compatibility with my FreeBSD systems, and it's lovely. Of course, it's so much easier there with everything being open source.
https://msdn.microsoft.com/en-us/library/windows/desktop/dd3...
Additionally Nano server does not have it.
Not sure if it is yet possible to remove from the desktop yet, but I'm doubtful.
On the contrary, I think it's an indictment of the industry that we still put effort in hardware into running ancient software and continue to burden the most widespread architecture in the world with 1970s nonsense when virtualization is the obvious solution.
Plenty of people want to run games for the 6502 architecture on their PCs, yet Intel would be out of their mind if they added a 6502 to the die. Why do we not treat the Intel 8086 the same way?
For example, AFAIK there's still no emulator that can correctly run the 8088 mph demo.
(There's also the fact that the 8088 MPH demo is not a particularly compelling use case, even if the hardware were present.)
I think the idea is that long mode can be fused off. IIRC there's some MS requirement that boxes that have 64-bit CPUs must use 64-bit Windows, so keeping 32-bit firmware and adding a fuse works around it for users who care.