Re: Is MOVDQA possible in real mode (16 bit)?
J de Boyne Pollard
JH> Also ideally the boot manager would fit in the MBR. Then
JH> there's no issues of how much of the first cylinder is
JH> available or in use. The second sector could perhaps be
JH> used to store the date and time of last boot.
It's been a bad idea for some considerable time now to make boot
managers operate in the same way as MBR viruses operate. This is not
least because it makes them fall foul of the measures that people take
to combat MBR viruses. It's also the case that code has no business
assuming that it can just use, willy-nilly, the second and subsequent
sectors of the disc. This is the 21st century. Partitioning doesn't
necessarily *have* unallocated space holes that one can drop the code
for a boot manager, or for a computer virus, into. Indeed, it's a
real possibility nowadays that the second sector is *where the
partition table is*. The correct way to go about things has been, for
some time now, to properly allocate space for a boot manager and
properly record that allocation in the partition table, so that there
are no more of the "Editing my partition table overwrote my boot
manager and now my system is unbootable!" problems that so many people
have experienced over decades past. GRUB is now finally capable of
doing this, as of quite recently. IBM's BootManager did it from the
get-go.
JH> Partition ids may be confusing to the user. How would you
JH> name them in the menu?
A convention for giving display names to partitions in the MBR
partitioning scheme has been around since the early 1990s. IBM's
BootManager was where it originated. Essentially, each MBR gains an
additional table, extending the traditional partition table with an
additional flag byte and an 8-character name field. (Of course, the
partition table in the EFI partitioning scheme contained a name field
in each partition table entry right from the start, without requiring
that names be bolted on as an afterthought.) These are the partition
names displayed by DFSEE's PART command, for example (and by my
PARTLIST and DASDPART utilities, and of course by IBM's FDISK, and by
IBM's BootManager and its derivatives).
J de Boyne Pollard
BS> Its con is that it occupies the first partition, eating 7 MB of
the
BS> drive's capacity, while IBOOT doesn't need its own partition.
As explained, that's actually a point in favour of the former, since
it prevents the damage that you'll find your approach subject to, as
many before you have done. It's the 21st century. We don't write
boot managers like MBR viruses any more. (-:
BS> I do it like LILO or GRUB, [...]
As mentioned, GRUB is now, finally, capable of using a proper
partition to reserve space for its second-stage portions, as IBM's
BootManager does.
BS> [...] it creates IDEOS partition tables on all drives. These
BS> occupy 8 sectors for 32 entries. [...]
Don't reinvent the wheel. If you want an improved partition table
mechanism, use the EFI one. Not only has it already been invented,
but you'll find that there already exist other people's tools that can
interoperate with it, which of course won't be the case with a roll-
one's-own partition table mechanism. If you want to auto-convert from
the MBR scheme to some other scheme, convert to the EFI scheme. Note
that you don't need to write to the disc at all in order to use an
enhanced partition table layout *in memory*, in a boot manager.
Maxim S. Shatskih
> Don't reinvent the wheel. If you want an improved partition table
> mechanism, use the EFI one.
aka GUID partition table (GPT). IIRC it is publicly documented.
--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com
Bernhard Schornak
J de Boyne Pollard wrote:
> BS> I do it like LILO or GRUB, [...]
>
> As mentioned, GRUB is now, finally, capable of using a proper
> partition to reserve space for its second-stage portions, as IBM's
> BootManager does.
My GRUB from the latest DEBIAN distribution does use the
scheme I mentioned in my posting. Actually, I have -not-
seen -any- bootmanager (except IBM's) working in another
way. Okay, I work with OS/2 since 1993 and had no reason
to use another bootmanager. I tested some LILOs and GRUB
on the fly, just to have a look at how they work. Forget
about GRUB - it's malware...
> BS> [...] it creates IDEOS partition tables on all drives. These
> BS> occupy 8 sectors for 32 entries. [...]
>
> Don't reinvent the wheel. If you want an improved partition table
> mechanism, use the EFI one. Not only has it already been invented,
> but you'll find that there already exist other people's tools that can
> interoperate with it, which of course won't be the case with a roll-
> one's-own partition table mechanism. If you want to auto-convert from
> the MBR scheme to some other scheme, convert to the EFI scheme. Note
> that you don't need to write to the disc at all in order to use an
> enhanced partition table layout *in memory*, in a boot manager.
I do not support proprietary systems. As I have to get a
license before I am allowed to view any EFI documents, I
don't think it is an alternative. Are there any free do-
cuments regarding definitions you mention in your post?
Does it support 128 bit LBAs? Something fit for the 21st
century should be prepared for rapid growth of mass sto-
rage. My concept keeps pace... ;)
AMD is not mentioned on the EFI homepage. My code is op-
timised for AMD64 and runs best on AMD machines - no AMD
board supports EFI.
Greetings from Augsburg
Bernhard Schornak
J de Boyne Pollard
JdeBP> As mentioned, GRUB is now, finally, capable of using a
JdeBP> proper partition to reserve space for its second-stage
JdeBP> portions, as IBM's BootManager does.
BS> My GRUB from the latest DEBIAN distribution does use
BS> the scheme I mentioned in my posting. Actually, I have
BS> -not- seen -any- bootmanager (except IBM's) working in
BS> another way. [...] Forget about GRUB - it's malware...
Then either you haven't looked too closely at the GRUB documentation,
or your GRUB is an older version. Read the GRUB documentation for
what it calls the "BIOS Boot partition".
JdeBP> Don't reinvent the wheel. If you want an improved
JdeBP> partition table mechanism, use the EFI one. [...]
BS> I do not support proprietary systems.
Yes, you do, else you wouldn't be supporting the MBR partitioning
scheme either. I suspect that that is not your real reason but post-
hoc justification, given the error that you then proceeded to state:
BS> As I have to get a license before I am allowed to view
BS> any EFI documents, I don't think it is an alternative.
One doesn't have to get licences for anything. There's freely
available documentation of the EFI partitioning scheme available from
many places, from the official specification to articles on Apple
Developer Connection and Microsoft TechNet. As M. Shatskih said, it's
publicly documented. One could probably even work out how it works
just from the source code for the GPT fdisk (<URL:http://
rodsbooks.com./gdisk/>), without looking at any of that public
documentation. (I've not tried, myself, though. I just read the
specification.)
BS> AMD is not mentioned on the EFI homepage.
BS> My code is optimised for AMD64 and runs
BS> best on AMD machines
BS> no AMD board supports EFI.
Those are irrelevant. We are talking about a disc partitioning
scheme, not processor instruction sets. Mainboard support is
irrelevant, too. After all, if it *were* relevant, you'd have the
same issue, that no mainboard supports it, with your roll-your-own
partitioning scheme, since no mainboards support that, either. Yet
you aren't complaining that no mainboard supports your roll-your-own
partitioning scheme. The irony is that disk partitioning schemes are
largely irrelevant to mainboards, which don't have to know anything
about disc partitions for x86-style load-and-run-the-MBR
bootstrapping. Those mainboard firmwares that *do* understand and
deal in disc partitioning schemes *use EFI firmwares* and understand
the EFI partitioning scheme just fine. So where it actually is
relevant in the first place, one finds that the mainboards have the
support. (-:
As above, it appears that you are looking for post-hoc rationales to
prop up a decision made for other reasons. But those rationales
simply don't hold water. One doesn't have to get licences. The
association with Microsoft, IBM, et al. of the partitioning scheme
that you *already* deal in doesn't seem to be an obstacle to you.
There's ample documentation for the EFI partitioning scheme publicly
available. Mainboards have very little to do with disc partitioning
schemes. Processor instruction sets have nothing to do with disc
partitioning schemes. And (if the mentions of GPT fdisk, Microsoft,
and Apple didn't give this away) there are publicly available tools
(GPT fdisk, GNU parted, Intel's/Microsoft's "diskpart", and my
DASDPART, for starters) and operating systems (Windows NT and MacOS X)
that put the EFI partitioning scheme into practical use on a daily
basis.
As I said, don't reinvent the wheel. A wheel already exists, here,
that will interoperate with other people's tools and softwares.
And as I also said, one doesn't need to auto-convert partitioning
schemes, or indeed write to disc, if all that one is doing is
constructing temporary data structures on the fly in memory.
Bernhard Schornak
J de Boyne Pollard schrieb:
>
> JdeBP> As mentioned, GRUB is now, finally, capable of using a
> JdeBP> proper partition to reserve space for its second-stage
> JdeBP> portions, as IBM's BootManager does.
>
> BS> My GRUB from the latest DEBIAN distribution does use
> BS> the scheme I mentioned in my posting. Actually, I have
> BS> -not- seen -any- bootmanager (except IBM's) working in
> BS> another way. [...] Forget about GRUB - it's malware...
>
> Then either you haven't looked too closely at the GRUB documentation,
> or your GRUB is an older version. Read the GRUB documentation for
> what it calls the "BIOS Boot partition".
Whenever I find some spare time to search for it.
> JdeBP> Don't reinvent the wheel. If you want an improved
> JdeBP> partition table mechanism, use the EFI one. [...]
>
> BS> I do not support proprietary systems.
>
> Yes, you do, else you wouldn't be supporting the MBR partitioning
> scheme either. I suspect that that is not your real reason but post-
> hoc justification, given the error that you then proceeded to state:
>
> BS> As I have to get a license before I am allowed to view
> BS> any EFI documents, I don't think it is an alternative.
>
> One doesn't have to get licences for anything. There's freely
> available documentation of the EFI partitioning scheme available from
> many places, from the official specification to articles on Apple
> Developer Connection and Microsoft TechNet. As M. Shatskih said, it's
> publicly documented. One could probably even work out how it works
> just from the source code for the GPT fdisk (<URL:http://
> rodsbooks.com./gdisk/>), without looking at any of that public
> documentation. (I've not tried, myself, though. I just read the
> specification.)
Looking at the GUID thingy, the entire concept is
designed to simplify DRM and user tracking. While
32 byte per entry are reserved for GUID's, only 2
quadwords are reserved for the most important in-
formation: Start and size of a partition. It took
less than twenty years until the original MBR en-
coding reached its end and another 10 years until
we reached the limit of 32 bit LBA addressing. It
is foreseeable that we reach the 64 bit limit set
by GPT within the next 15 or 20 years. How can it
be a 'concept for the 21st century' if it defines
its own death within the next 20 years?
Think open, not narrow minded!
> BS> AMD is not mentioned on the EFI homepage.
> BS> My code is optimised for AMD64 and runs
> BS> best on AMD machines
> BS> no AMD board supports EFI.
>
> Those are irrelevant.
Not for more than 90% of all PC users.
> We are talking about a disc partitioning
> scheme, not processor instruction sets. Mainboard support is
> irrelevant, too. After all, if it *were* relevant, you'd have the
> same issue, that no mainboard supports it, with your roll-your-own
> partitioning scheme, since no mainboards support that, either. Yet
> you aren't complaining that no mainboard supports your roll-your-own
> partitioning scheme. The irony is that disk partitioning schemes are
> largely irrelevant to mainboards, which don't have to know anything
> about disc partitions for x86-style load-and-run-the-MBR
> bootstrapping. Those mainboard firmwares that *do* understand and
> deal in disc partitioning schemes *use EFI firmwares* and understand
> the EFI partitioning scheme just fine. So where it actually is
> relevant in the first place, one finds that the mainboards have the
> support. (-:
EFI and GPT still are no international standards.
In general, it is nothing more or less than
<http://www.openfirmware.org/>
OpenFirmware PCs are on the market, as well.
> As above, it appears that you are looking for post-hoc rationales to
> prop up a decision made for other reasons. But those rationales
> simply don't hold water. One doesn't have to get licences. The
> association with Microsoft, IBM, et al. of the partitioning scheme
> that you *already* deal in doesn't seem to be an obstacle to you.
> There's ample documentation for the EFI partitioning scheme publicly
> available. Mainboards have very little to do with disc partitioning
> schemes. Processor instruction sets have nothing to do with disc
> partitioning schemes. And (if the mentions of GPT fdisk, Microsoft,
> and Apple didn't give this away) there are publicly available tools
> (GPT fdisk, GNU parted, Intel's/Microsoft's "diskpart", and my
> DASDPART, for starters) and operating systems (Windows NT and MacOS X)
> that put the EFI partitioning scheme into practical use on a daily
> basis.
>
> As I said, don't reinvent the wheel. A wheel already exists, here,
> that will interoperate with other people's tools and softwares.
A bootmanager is not a partitioning tool. It just
has to start one of the available bootable parti-
tions, nothing else. IDEOS' partition table isn't
reinvention of something, it's a useful extension
for existing PCs, regardless of the installed OS.
Unlike GPT, it is cooperative. It doesn't require
expensive hardware and works with non-'EFI aware'
operating systems. With 128 bit LBA support, it's
fit for the next four or five decades.
> And as I also said, one doesn't need to auto-convert partitioning
> schemes, or indeed write to disc, if all that one is doing is
> constructing temporary data structures on the fly in memory.
That's something I consider. I just hate to waste
valuable resources with outdated mechanisms.
For the remaining parts: Your arguments could not
covince me of GPT or the (U)EFI stuff. As long as
Intel is the main actor and beneficiary, it never
will be my thing. I am not the AMD fanatic, but I
support whatever undercuts the dominant positions
of Intel and Microsoft. I surely will have a look
at the OpenFirmware documents, but GPT already is
history. Its specs define sudden death within the
next two decades - a typical example for 'genuine
Intel'. Let's meet at the burial in 2030... ;)
Greetings from Augsburg + happy new year!
Bernhard Schornak