Re: The problem with mbr...
I haven't been following all the way along, however, I am quite familiar
with the MBR. There are exactly 512 bytes for the MBR. The last 2 are
a signature (0x55AA) and the 64 bytes befor that are the master
The sectors that follow the MBR are *usually* unused but may be
allocated; this would be a rather dangerous place to put code. We could
all agree that *we* will never use those first few sectors as storage,
I thought about RLE encoding my code but code does not compress and the
RLE decompress took more space then it saved. I assume that any other
compression method would have the same problem (my RLE decomp was 32
LILO extends the MBR code by using the MBR bootloader to load the "real"
boot loader by loading absolute sectors off of the disk.
If you think you can do better, go for it, just be warned ;-)
P.S. I'm one of those people that actually enjoys playing with stuff
Marco d'Itri wrote:
> On Feb 03, John Goerzen <firstname.lastname@example.org> wrote:
> >I'm not sure that there is space technically for this. Dunno, this is
> >a guess, but I suspect that with all the features in it, they are
> >REALLY pushing the limit already.
> I don't think so. I have some experience in writing boot sectors and I
> remember having one which displayed quite a lot of text and did more
> than MBR does (like switching the fdds).
> If needed, I can help optimizing mbr.
> To UNSUBSCRIBE, email to email@example.com
> with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org
Robin Burgener / Linux Kernel Group / Corel Corporation
20Q, the neural-net on the Internet - http://www.20q.net