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
partition table.
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,
but, someday...
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
bytes).
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
like that.
Marco d'Itri wrote:
>
> On Feb 03, John Goerzen <jgoerzen@complete.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.
>
> --
> ciao,
> Marco
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
--
Robin Burgener / Linux Kernel Group / Corel Corporation
mailto: robinb@corel.com
20Q, the neural-net on the Internet - http://www.20q.net
Reply to: