> Windows XP/7's video modesetting logic is a bit mysterious. It may try to set a incompatible mode using int10h, which will cause flickering or even black screen after transferring control to the legacy OS.
Microsoft owns GitHub, and GitHub is crawling with Windows source code leaks… and I’m wondering it anyone at Microsoft really cares? Is it possible they’ve even made an intentional decision just to ignore it?
If it were an Oracle source code leak, I expect they’d have a crack team of lawyers suing people 24x7 until it was all gone… maybe that’s why there haven’t (to my knowledge) been any Oracle source code leaks (I vaguely remember one of Solaris, but that wasn’t such a clearcut case since IIRC it was mostly previously open sourced code)
Well, it wouldn’t surprise me if some unfriendly intelligence agency somewhere had succeeded in stealing some of it, but if they have, they are unlikely to release it publicly
When I started college in 1989, my Pascal programming class used a cluster of AT&T 3B2 systems running SVR3. I poked around those systems like crazy over the course of two quarters. I don't remember if there was any significant source code exposed to unprivileged users.
During the mid-90s, the Unix Wars were raging and Unix System Labs was suing U.C. Berkeley over the intellectual property of Unix source code. Unix had been written at AT&T Bell Labs, but Berkeley had licensed and forked their own, based on improved networking code, and by this time it was ready to run on i386 systems. In fact, USL had borrowed back some BSD code, allegedly without crediting them. Berkeley had been busy removing AT&T code and replacing it, so they could relicense BSD Unix.
USL, part of AT&T (but later purchased by Novell), contended that Berkeley could not easily make a "clean room implementation" of any kernel code or device drivers, if those programmers had read or worked with original AT&T source code. They told the courts (and journalists) that the programmers might be tempted to reproduce proprietary Unix code, consciously or subconsciously, and therefore, these programmers were permanently "Mentally Contaminated" and Berkeley should not be allowed to continue distributing BSD [BSDi] Unix.
So when I attended Usenix LISA in 1994, this 3-year lawsuit was at a fever pitch, and someone on the convention floor had manufactured large buttons for attendees to wear, proudly proclaiming "MENTALLY CONTAMINATED", and all the admins and systems programmers had a good laugh about the absurdity of trying to keep a lid on proprietary source code by policing everyone who's ever seen one of its files.
This type of restriction is still applied to contributors to the ReactOS project, in that contributions are not accepted from those who have seen any leaked Windows source code or have worked for Microsoft.
> Microsoft owns GitHub, and GitHub is crawling with Windows source code leaks… and I’m wondering it anyone at Microsoft really cares?
Even weirder is that GitHub hosts all of the tools for activating (i.e. cracking) modern versions of Windows and Office as well. Microsoft really doesn't care.
Why should they? They have bulk licensing deals with PC OEMs and large organizations. They've already got the big money. J. Random Hacker building a PC isn't even a rounding error to them.
Quite right in fact limited weak copyright protection helps retain marketshare that might be lost otherwise especially when that weak protection in fact costs little real revenue.
It looks even smarter from the MS side when you think of all the threat intel that they gather from pirated Windows installs that can be used as a baseline to compare legit installs against.
MS offers (or offered back in the day of Win2000 and XP) access to source code for governments, system integrators and academic institutions as part of its Shared Source Initiative:
And it is pretty clear that’s where most or all of these leaks actually came from, not from within Microsoft. e.g. the NT4 and 2000 leaks apparently came from Mainsoft
I don’t know the current status of those source code access programs but I believe at least some of them are still in effect. IIRC, to stop the Chinese government from dumping Windows, they had to give them source code access, but I believe they are planning to dump it anyway, they see relying on US proprietary software for their government operations as too big a risk
The little bit I perused is very readable code.. like enjoyable to read. There are a lot of stylistic decisions that always felt "right" to me (general spacing, commenting style, horizontal alignment of equals signs, etc) -- but FWIW the first codebase I ever read (and probably imprinted on me indelibly) was DikuMUD, which is kind of in the same ballpark.
I... wouldn't confess to having perused illegally leaked Windows source, as it could taint you and make you ineligible to contribute to certain projects, like Wine.
What percentage of people reading HN do you think are actively contributing to WINE source? I'm going to go out on a limb and claim less than a tenth of a percent. And that, to me, is probably 10-100x too high of a threshold.
This is like the reverse of the bootloaders first pioneered by the Hackintosh community to boot UEFI macOS on traditional BIOS systems.
and VESA VBIOS from SeaBIOS project
Unfortunately I believe modern GPUs without a standard VBIOS may not act enough like an IBM VGA for a generic VGA VBIOS to work, so I see another project for someone in the future: a retrofit VBIOS, especially for those GPUs e.g. Intel's for which lots of open-source driver code and documentation is available but later models no longer come with a VBIOS.
Perhaps also injecting a true CSM from an old closed-source UEFI BIOS, before they started removing it, is worth doing as in my limited experience SeaBIOS isn't as quite compatible as the closed-source ones for some edge-cases.
But, as okanat says, if the goal is to run legacy operating systems, then modern hardware is going to be challenging in other ways too. IME the biggest thing I want PC BIOS back for is the ability to use non-GPT disk layouts, which this doesn't accomplish as, as to use it you put it on the EFI partition on your GPT disk.
MBR and GPT can coexist on the same disk - MBR goes in sector 0, GPT starts in sector 1. Normally the MBR in sector 0 is “protective” (it just marks the whole disk as in use), but in theory you can create a “hybrid” disk in which the MBR and GPT both describe the same partitions. I suppose you could even reserve most of the disk as one big GPT partition and then split that up into multiple MBR partitions. You’d have to be very careful editing the partition table on such a disk because standard tools might break it.
In practice, whether or not this actually works can be very hit-or-miss. We've found several UEFI implementations will not consider a disk bootable if the pMBR doesn't exactly match the spec, which specifies that the 'protective' partition shouldn't be marked as bootable in the MBR partition table.
Meanwhile, other implementations will not consider the disk bootable in BIOS mode if the partition in the pMBR is not marked bootable.
Indeed! Which is why the only portable solution is to not do this.
For stuff that needs to be bootable by both BIOS and UEFI the only portable solution is to use MBR, not GPT. That means all legacy BIOS systems will boot it, and so will all UEFI systems since UEFI must support MBR.
For ISOs that need to additionally be booted off of optical media (aka ISOHYBRIDs) the story gets more complicated, but ultimately what you need to take away from that is the same: avoid GPT at all cost.
That is a very niche use case, and also won't really work on most real BIOS machines as they actually check for a proper MBR and/or BPB (and no GPT), which is also why GPT on BIOS support is very spotty, since a lot of BIOSes will detect the GPT and refuse to boot, or refuse to boot in legacy (CSM) mode.
In any case that is far beyond the original scope of booting old PC OSes, which MBR support alone serves really well (99.9% of the way there, really), which is why I assumed by default you were thinking of MBR, not some other weird scheme.
GPT is not UEFI. It's just the format of the storage device. I have many computers with GPT formatted disks with actual master boot records at the start of the disk that boot MBR on both original BIOS machines and CSM BIOS machines.
MBR is two things with the same name. It is both the format of the storage device and describes a booting mode using a master boot record and up to 4 partitions.
GPT is one thing. It is a format for a storage device. It is the alternative to the MBR format for storage devices. It has nothing to do with (U)EFI.
BIOS or BIOS/csm are not types of formats for storage devices. They are types of boot processes. (U)EFI is another type of boot process.
You can easily mix and match boot types (BIOS/csm vs UEFI) and storage device format types (GPT vs MBR). As others have said, there may be some slight incompatibilities on some rare hardware/software configs, but mostly it just works.
I know every word of what I said in the message you're replying to. While what you said is mostly accurate, as in MBR != BIOS and GPT != UEFI, never in my original message have I stated that that is the case. And the rest of what you said is incorrect, as per my original message.
Oof. On re-read I see now this sub-thread's topic was "non-GPT, non-MBR". So my "response" was ... off topic and useless. Sorry.
I am not sure what I said that was incorrect though. As I'm always looking to learn, which bit? I am currently assuming the 'rest' about GPT on true BIOS machines. I suppose I have never booted off GPT formatted disks in true BIOS machines. I always boot off MBR formatted disks and just used the GPT as storage/etc.
But I'm unclear on how this would break things since you can still have the MBR in the first sector on a GPT formatted disk. And how could the true BIOS motherboards detect GPT format on the disks when they don't know about it?
Because they do know about them. At least some of them do, of course.
Ideally, BIOS/CSM systems should not care about what type of partition table format a disk uses, and just boot by loading the boot sector (the 1st sector), and passing control to it.
In the real world, some machines will check for whether an MBR exists (by MBR meaning the partition table contained in the first sector, also called "msdos" partition table, naming varies depending on who you ask), some of them will check whether there is any partition set as active in said MBR, some of them will, indeed, check if there is a GPT (past any protective MBR), and ignore such disks - possibly because firmware writers thought that no GPT disk should be bootable on BIOS systems (Windows doesn't support it, so...), to avoid passing control to an empty protective MBR and possibly crash or hang as a result.
How much benefit would there be in whole-disk btrfs? The space taken up by GPT and the FAT32 EFI partition is a rounding error compared to the sizes of modern disks.
I have used only whole-disk XFS SSDs and HDDs for more than a decade.
While the space wasted by GPT and partitions and by the arbitrary alignment rules used by various formatting tools is not great, I do not see any reason why it should exist. The space wasted now with GPT and UEFI is several orders of magnitude greater than it was with traditional partition tables, so eliminating it has become more attractive.
Such SSDs and HDDs are not bootable, but for me this is a desirable feature, not a bug. I boot my computers either from Ethernet (e.g. most of my servers) or from a removable USB memory.
The SSDs and HDDs with a whole-disk file system are also wholly encrypted. As in a proper encryption implementation, there is complete separation between the encrypted data and the encryption key. The encrypted disks or their hosting computers do not contain any information about decryption, unlike in many systems of disk encryption. The encrypted decryption keys can be found only on external or remote boot media, which are not normally associated with the hosting computers.
> I have used only whole-disk XFS SSDs and HDDs for more than a decade.
I wouldn't recommend that. It makes the disk appear to be empty to many tools (and possibly some operating systems), which could lead to data loss. That's the reason GPT has the protective MBR: it makes the disk appear to be full to legacy tools which don't understand the GPT format.
You are right, and such disks will appear as empty to any tool or OS, but I will never insert any of my SSDs or HDDs that are used in this way in a computer that I do not control.
Windows frequently overwrites any bootable Linux drive, so it might have even less restraints with an apparently empty drive that does not have GPT structure.
Because of the risk of Windows messing with them, I also do not insert any of my bootable USB memories in a live Windows computer, even when they have GPT structure. For data interchange with Windows, I use only clean and non-bootable exFAT formatted USB memories.
Amazing! I thought all hope of ever running FreeDOS on the bare metal again on new hardware was lost, but maybe using this code (or something similar) a future FreeDOS installer can fix this at least on some systems.
This is the project that I think has been needed for a while now.
So much that a Replacement CSM for user implementation has been top of mind to suggest here, awaiting the next time I see a request from programmers looking for a worthwhile project.
Now there's nothing more performant than a request being granted before it's even been made :)
From the project page: "Boot FreeDOS, Windows XP, and Windows 7"
Additionally, it was just 3 years ago that memtest86plus finally got a UEFI version. That was painful for a few years there. (Though the 4GB RAM limit would have made this not an ideal solution.)
I'm sure there are other such self-hosting utilities that haven't been and may not be ported/rewritten to work under UEFI.
It's a mishmash. Vista and 7 can't boot from the GPT partitions and overall widespread UEFI support on the hardware is ~2013, way beyond Vista and very late in 7 lifecycle.
The two reasons I can think of: to run legacy or educational operating systems. There are going to be limitations to what can be supported, but simply getting the OS to boot is part of the battle. It would also be useful for those who want to experiment with operating systems by creating their own. Yes you can do that without BIOS support, but there are many old tutorials floating around that depend upon BIOS support. The BIOS was also created as a primitive hardware compatibility layer, so it will provide basic support for things like I/O.
DOSBox doesn't give access to real hardware. DOSemu doesn't run well on 64-bit machines. If you need unfettered hardware access, FreeDOS on the bare machine is the best option.
Actually it does give some. I'm using old ham radio software like CT9 under Windows 64-bits using DOSBox-X, with the parallel port configured in pass-through mode. DOSBox-X supplies a specific driver for this kind of direct hardware access. Of course not everything will work that way.
> Windows XP/7's video modesetting logic is a bit mysterious. It may try to set a incompatible mode using int10h, which will cause flickering or even black screen after transferring control to the legacy OS.
I would really love to know more about this.
I assume it's this VGA driver:
https://github.com/tongzx/nt5src/tree/master/Source/XPSP1/NT...
> https://github.com/tongzx/nt5src/blob/master/Source/XPSP1/NT...
> It is based on the SpiderSTREAMS source, stremul\msgsrvr.c.
There's some special history.
I’d love to know if any apps ever actually used the STREAMS support in Windows NT 3/4; I’ve never seen any
It is kind of amazing that Microsoft hosts leaked Windows source code on their own website.
Could this be seen a distribution by Microsoft? I mean, if you can sue Pirate Bay for the content they host...
Wow, Microsoft open-sourced Windows XP?
... uhh, not really. :)
Microsoft owns GitHub, and GitHub is crawling with Windows source code leaks… and I’m wondering it anyone at Microsoft really cares? Is it possible they’ve even made an intentional decision just to ignore it?
If it were an Oracle source code leak, I expect they’d have a crack team of lawyers suing people 24x7 until it was all gone… maybe that’s why there haven’t (to my knowledge) been any Oracle source code leaks (I vaguely remember one of Solaris, but that wasn’t such a clearcut case since IIRC it was mostly previously open sourced code)
Well, it wouldn’t surprise me if some unfriendly intelligence agency somewhere had succeeded in stealing some of it, but if they have, they are unlikely to release it publicly
When I started college in 1989, my Pascal programming class used a cluster of AT&T 3B2 systems running SVR3. I poked around those systems like crazy over the course of two quarters. I don't remember if there was any significant source code exposed to unprivileged users.
During the mid-90s, the Unix Wars were raging and Unix System Labs was suing U.C. Berkeley over the intellectual property of Unix source code. Unix had been written at AT&T Bell Labs, but Berkeley had licensed and forked their own, based on improved networking code, and by this time it was ready to run on i386 systems. In fact, USL had borrowed back some BSD code, allegedly without crediting them. Berkeley had been busy removing AT&T code and replacing it, so they could relicense BSD Unix.
USL, part of AT&T (but later purchased by Novell), contended that Berkeley could not easily make a "clean room implementation" of any kernel code or device drivers, if those programmers had read or worked with original AT&T source code. They told the courts (and journalists) that the programmers might be tempted to reproduce proprietary Unix code, consciously or subconsciously, and therefore, these programmers were permanently "Mentally Contaminated" and Berkeley should not be allowed to continue distributing BSD [BSDi] Unix.
https://en.wikipedia.org/wiki/UNIX_System_Laboratories,_Inc.....
So when I attended Usenix LISA in 1994, this 3-year lawsuit was at a fever pitch, and someone on the convention floor had manufactured large buttons for attendees to wear, proudly proclaiming "MENTALLY CONTAMINATED", and all the admins and systems programmers had a good laugh about the absurdity of trying to keep a lid on proprietary source code by policing everyone who's ever seen one of its files.
This type of restriction is still applied to contributors to the ReactOS project, in that contributions are not accepted from those who have seen any leaked Windows source code or have worked for Microsoft.
From those who claim to, to be precise.
> Microsoft owns GitHub, and GitHub is crawling with Windows source code leaks… and I’m wondering it anyone at Microsoft really cares?
Even weirder is that GitHub hosts all of the tools for activating (i.e. cracking) modern versions of Windows and Office as well. Microsoft really doesn't care.
Why should they? They have bulk licensing deals with PC OEMs and large organizations. They've already got the big money. J. Random Hacker building a PC isn't even a rounding error to them.
Quite right in fact limited weak copyright protection helps retain marketshare that might be lost otherwise especially when that weak protection in fact costs little real revenue.
It looks even smarter from the MS side when you think of all the threat intel that they gather from pirated Windows installs that can be used as a baseline to compare legit installs against.
Also, they still get the ad revenue and telemetry if you pirate Windows and otherwise leave it stock.
...of which the tools to disable that invasiveness are also on GitHub, so maybe they just care more about maintaining marketshare.
Microsoft's current business is its cloud services, not Windows. Windows is just an onramp to their SaaS subscriptions.
MS offers (or offered back in the day of Win2000 and XP) access to source code for governments, system integrators and academic institutions as part of its Shared Source Initiative:
- https://en.wikipedia.org/wiki/Shared_Source_Initiative#Overv...
- https://news.microsoft.com/source/2002/02/21/microsoft-annou...
And it is pretty clear that’s where most or all of these leaks actually came from, not from within Microsoft. e.g. the NT4 and 2000 leaks apparently came from Mainsoft
I don’t know the current status of those source code access programs but I believe at least some of them are still in effect. IIRC, to stop the Chinese government from dumping Windows, they had to give them source code access, but I believe they are planning to dump it anyway, they see relying on US proprietary software for their government operations as too big a risk
The little bit I perused is very readable code.. like enjoyable to read. There are a lot of stylistic decisions that always felt "right" to me (general spacing, commenting style, horizontal alignment of equals signs, etc) -- but FWIW the first codebase I ever read (and probably imprinted on me indelibly) was DikuMUD, which is kind of in the same ballpark.
Anyways, very cool to see.
I... wouldn't confess to having perused illegally leaked Windows source, as it could taint you and make you ineligible to contribute to certain projects, like Wine.
That's Wine's problem, not mine.
if you read it but didn't confess, you'd still be ineligible, you'd be harming rather than helping wine if you did sneak in contributions.
What percentage of people reading HN do you think are actively contributing to WINE source? I'm going to go out on a limb and claim less than a tenth of a percent. And that, to me, is probably 10-100x too high of a threshold.
Wanting to and reading Windows source is fine. What isn't fine is the suggestion to not admit to it.
This is like the reverse of the bootloaders first pioneered by the Hackintosh community to boot UEFI macOS on traditional BIOS systems.
and VESA VBIOS from SeaBIOS project
Unfortunately I believe modern GPUs without a standard VBIOS may not act enough like an IBM VGA for a generic VGA VBIOS to work, so I see another project for someone in the future: a retrofit VBIOS, especially for those GPUs e.g. Intel's for which lots of open-source driver code and documentation is available but later models no longer come with a VBIOS.
Perhaps also injecting a true CSM from an old closed-source UEFI BIOS, before they started removing it, is worth doing as in my limited experience SeaBIOS isn't as quite compatible as the closed-source ones for some edge-cases.
It's actually pretty much the same as the project to get Windows running on Intel Macs before Apple released Boot Camp
Very cool hack.
But, as okanat says, if the goal is to run legacy operating systems, then modern hardware is going to be challenging in other ways too. IME the biggest thing I want PC BIOS back for is the ability to use non-GPT disk layouts, which this doesn't accomplish as, as to use it you put it on the EFI partition on your GPT disk.
By spec, UEFI is required to support both MBR and GPT, so there is literally nothing stopping you from using MBR.
MBR and GPT can coexist on the same disk - MBR goes in sector 0, GPT starts in sector 1. Normally the MBR in sector 0 is “protective” (it just marks the whole disk as in use), but in theory you can create a “hybrid” disk in which the MBR and GPT both describe the same partitions. I suppose you could even reserve most of the disk as one big GPT partition and then split that up into multiple MBR partitions. You’d have to be very careful editing the partition table on such a disk because standard tools might break it.
In practice, whether or not this actually works can be very hit-or-miss. We've found several UEFI implementations will not consider a disk bootable if the pMBR doesn't exactly match the spec, which specifies that the 'protective' partition shouldn't be marked as bootable in the MBR partition table.
Meanwhile, other implementations will not consider the disk bootable in BIOS mode if the partition in the pMBR is not marked bootable.
Indeed! Which is why the only portable solution is to not do this.
For stuff that needs to be bootable by both BIOS and UEFI the only portable solution is to use MBR, not GPT. That means all legacy BIOS systems will boot it, and so will all UEFI systems since UEFI must support MBR.
For ISOs that need to additionally be booted off of optical media (aka ISOHYBRIDs) the story gets more complicated, but ultimately what you need to take away from that is the same: avoid GPT at all cost.
I wonder… does the UEFI spec mandate any particular behaviour in these cases? Does the UEFI SCT test for it?
Seems like an inconsistency which could be addressed by adding it to the spec and/or test suite.
I guess the other thing I don’t know, is whether there is any actual real world pressure on firmware vendors to pass the test suite.
Too late to edit: non-GPT, non-MBR
For instance, whole-disk btrfs. Or old BSD partition schemes.
That is a very niche use case, and also won't really work on most real BIOS machines as they actually check for a proper MBR and/or BPB (and no GPT), which is also why GPT on BIOS support is very spotty, since a lot of BIOSes will detect the GPT and refuse to boot, or refuse to boot in legacy (CSM) mode.
In any case that is far beyond the original scope of booting old PC OSes, which MBR support alone serves really well (99.9% of the way there, really), which is why I assumed by default you were thinking of MBR, not some other weird scheme.
GPT is not UEFI. It's just the format of the storage device. I have many computers with GPT formatted disks with actual master boot records at the start of the disk that boot MBR on both original BIOS machines and CSM BIOS machines.
MBR is two things with the same name. It is both the format of the storage device and describes a booting mode using a master boot record and up to 4 partitions.
GPT is one thing. It is a format for a storage device. It is the alternative to the MBR format for storage devices. It has nothing to do with (U)EFI.
BIOS or BIOS/csm are not types of formats for storage devices. They are types of boot processes. (U)EFI is another type of boot process.
You can easily mix and match boot types (BIOS/csm vs UEFI) and storage device format types (GPT vs MBR). As others have said, there may be some slight incompatibilities on some rare hardware/software configs, but mostly it just works.
I know every word of what I said in the message you're replying to. While what you said is mostly accurate, as in MBR != BIOS and GPT != UEFI, never in my original message have I stated that that is the case. And the rest of what you said is incorrect, as per my original message.
I invite you to read what I said again.
Oof. On re-read I see now this sub-thread's topic was "non-GPT, non-MBR". So my "response" was ... off topic and useless. Sorry.
I am not sure what I said that was incorrect though. As I'm always looking to learn, which bit? I am currently assuming the 'rest' about GPT on true BIOS machines. I suppose I have never booted off GPT formatted disks in true BIOS machines. I always boot off MBR formatted disks and just used the GPT as storage/etc.
But I'm unclear on how this would break things since you can still have the MBR in the first sector on a GPT formatted disk. And how could the true BIOS motherboards detect GPT format on the disks when they don't know about it?
Because they do know about them. At least some of them do, of course.
Ideally, BIOS/CSM systems should not care about what type of partition table format a disk uses, and just boot by loading the boot sector (the 1st sector), and passing control to it.
In the real world, some machines will check for whether an MBR exists (by MBR meaning the partition table contained in the first sector, also called "msdos" partition table, naming varies depending on who you ask), some of them will check whether there is any partition set as active in said MBR, some of them will, indeed, check if there is a GPT (past any protective MBR), and ignore such disks - possibly because firmware writers thought that no GPT disk should be bootable on BIOS systems (Windows doesn't support it, so...), to avoid passing control to an empty protective MBR and possibly crash or hang as a result.
How much benefit would there be in whole-disk btrfs? The space taken up by GPT and the FAT32 EFI partition is a rounding error compared to the sizes of modern disks.
I have used only whole-disk XFS SSDs and HDDs for more than a decade.
While the space wasted by GPT and partitions and by the arbitrary alignment rules used by various formatting tools is not great, I do not see any reason why it should exist. The space wasted now with GPT and UEFI is several orders of magnitude greater than it was with traditional partition tables, so eliminating it has become more attractive.
Such SSDs and HDDs are not bootable, but for me this is a desirable feature, not a bug. I boot my computers either from Ethernet (e.g. most of my servers) or from a removable USB memory.
The SSDs and HDDs with a whole-disk file system are also wholly encrypted. As in a proper encryption implementation, there is complete separation between the encrypted data and the encryption key. The encrypted disks or their hosting computers do not contain any information about decryption, unlike in many systems of disk encryption. The encrypted decryption keys can be found only on external or remote boot media, which are not normally associated with the hosting computers.
> I have used only whole-disk XFS SSDs and HDDs for more than a decade.
I wouldn't recommend that. It makes the disk appear to be empty to many tools (and possibly some operating systems), which could lead to data loss. That's the reason GPT has the protective MBR: it makes the disk appear to be full to legacy tools which don't understand the GPT format.
You are right, and such disks will appear as empty to any tool or OS, but I will never insert any of my SSDs or HDDs that are used in this way in a computer that I do not control.
Windows frequently overwrites any bootable Linux drive, so it might have even less restraints with an apparently empty drive that does not have GPT structure.
Because of the risk of Windows messing with them, I also do not insert any of my bootable USB memories in a live Windows computer, even when they have GPT structure. For data interchange with Windows, I use only clean and non-bootable exFAT formatted USB memories.
> The space taken up by GPT and the FAT32 EFI partition is a rounding error
I am not the OP and I do not do this. However...
Yes, the disk space used is a rounding error and one far right of the decimal point.
But there is extra space used in the human brain that sets this up.
Instead of `/dev/sda1` it's `/dev/sda`. Instead of `/dev/nvme0l0p1` or whatever (I own almost no NVMe kit) it's `/dev/nvme0l0`. And so on.
This could be helpful; I can certainly imagine it simplifying things somewhat.
you probably can with uefi modules
Amazing! I thought all hope of ever running FreeDOS on the bare metal again on new hardware was lost, but maybe using this code (or something similar) a future FreeDOS installer can fix this at least on some systems.
Beautiful.
This is the project that I think has been needed for a while now.
So much that a Replacement CSM for user implementation has been top of mind to suggest here, awaiting the next time I see a request from programmers looking for a worthwhile project.
Now there's nothing more performant than a request being granted before it's even been made :)
I have been looking for something like this for a long time, I am glad to see it now exists.
Me too. Tell me more...?
Huh, Github fails quite badly at dealing with submodules from other forges.
Why?
From the project page: "Boot FreeDOS, Windows XP, and Windows 7"
Additionally, it was just 3 years ago that memtest86plus finally got a UEFI version. That was painful for a few years there. (Though the 4GB RAM limit would have made this not an ideal solution.)
I'm sure there are other such self-hosting utilities that haven't been and may not be ported/rewritten to work under UEFI.
I think I remember Windows 7 (and maybe even Vista) supported UEFI natively.
It's a mishmash. Vista and 7 can't boot from the GPT partitions and overall widespread UEFI support on the hardware is ~2013, way beyond Vista and very late in 7 lifecycle.
The two reasons I can think of: to run legacy or educational operating systems. There are going to be limitations to what can be supported, but simply getting the OS to boot is part of the battle. It would also be useful for those who want to experiment with operating systems by creating their own. Yes you can do that without BIOS support, but there are many old tutorials floating around that depend upon BIOS support. The BIOS was also created as a primitive hardware compatibility layer, so it will provide basic support for things like I/O.
You get a better experience on the educational front from booting them in a VM, but it's certainly more fun to boot on real hardware.
DOS. Can’t think of any other reason.
You get better DOS emulation with DOSBox, rather than trying to make the modern peripherals work on a CSM / BIOS system.
DOSBox doesn't give access to real hardware. DOSemu doesn't run well on 64-bit machines. If you need unfettered hardware access, FreeDOS on the bare machine is the best option.
Actually it does give some. I'm using old ham radio software like CT9 under Windows 64-bits using DOSBox-X, with the parallel port configured in pass-through mode. DOSBox-X supplies a specific driver for this kind of direct hardware access. Of course not everything will work that way.
What about using PCem? It does well emulating real hardware.
That does one no good if you need something connected to a parallel port.
I'd love to see someone tackle eMMC support on older machines as the next step.
Easily done in hardware. Look online for SD/SDHC/MMC to IDE/SATA adapters.