I had no idea UEFI booted directly into long mode... I feel like a moron who hasn't kept up with the times, but admittedly I'm not super into kernel dev. Can I just ignore segmentation entirely? It has always been my least favorite part of programming on x86
> I had no idea UEFI booted directly into long mode
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 =(
Another small technical detail. Windows has a mechanism to sign executables. The certificate in this mechanism is defined with the following structure [0]:
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]:
Oh that is not the really annoying part. By spec UEFI only requires support for booting from FAT (the particular flavor of FAT they implement) volumes, so, surprise, I've yet to seen any UEFI BIOS that supports booting from anything but a FAT filesystem.
> 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.
[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.
It depends. Cheap Intel boards come with a 32bit UEFI (for whatever reason, it's not like UEFI is paid by the address bit), leading to all kinds of issues.
>(for whatever reason, it's not like UEFI is paid by the address bit)
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.
I know we're probably ten years or more out from it (because it'd break way too much software ... I have an application I want to use but can't due to a 16-bit installer ... in 2016); but I really hope Microsoft eventually puts out a 64-bit only operating system. It would be lovely to be rid of SYSWOW64, Program Files (x86), the alternate shadow registry, ~3GB of wasted space for all the 32-bit code, etc.
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.
I feel just the opposite. I have a pile of the most powerful general-purpose commodity hardware ever built, and it's a damning indictment of the industry that it can no longer run software that used to work fine on tiny machines.
I disagree. Things that made sense on a tiny machine, like the original 8086's wraparound at 1 MB led to hacks like the A20 gate [1]. Or timing loops that were dependent on a processor running at 4.77 mhz, requiring things like the turbo button. Compatibility is a balancing game, because you end up needing to keep bugs lying around that otherwise would be fixed at some point in a newer architecture. I'm more of the opinion that we're much better off explicitly emulating those areas, so they are run in their own context and it's a lot easier to mitigate damage. While compatibility is a positive thing, improvement is a much more positive thing.
I agree that virtualization is better than support for old instruction sets in new cores, but users should expect that virtualization to be ever-present and reliable rather than mutely accept when tools randomly stop working.
> and it's a damning indictment of the industry that it can no longer run software that used to work fine on tiny machines
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?
There's also no PC manufactured in the past two decades that can run it. Real mode has nothing to do with the challenges necessary to emulate that demo.
(There's also the fact that the 8088 MPH demo is not a particularly compelling use case, even if the hardware were present.)
If they wanted to, they should have done it in 10. They can't now, because they promised to support all the devices it could be installed into for their lifetime. Some of those devices are 32bit.
64-bit Linux kernels can be configured to so that they can be booted by 32-bit UEFI. It's messy but it works. Even runtime services like UEFI variables work.
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.
You still need a GDT, but most of the values are ignored in long mode. There is still limited support in the form of changing the FS/GS segment bases, which is useful for the SYSCALL/SYSRET instructions.
