Look at a Linux Kernel. Why do you have to keep the kernel size down? You need to fit it into that first 64K
My linux kernel is 1.6 megabytes (not including the modules). It would be very difficult to create a linux kernel that would fit into 64k
Since I didn't know exactly how things worked, I did some reading. In an attempt to clarify it for myself, a summary of the boot process follows.
There is indeed a 640k limit in PCs still today. When things first start running the CPU is in
real mode, and data outside the first megabyte of address space can't be read. 640k of that is set aside for main memory. We have to load the kernel before it can run, and we have to deal with that 640k limit. I'll summarize how this is done below.
The first thing that runs is the BIOS, which does some tests and stuff. If one is booting from a floppy, the BIOS then loads the first part of the kernel directly.
Kernels all used to be small enough (half a meg) to fit into that 640k. The first part was loaded in after the first 64k block (where data from the BIOS is stored during bootup). This first bit (bootsect.S) loads the rest into the 640k. The code (now setup.S) moves the kernel down and overwrites the 64k block with the BIOS related data (after which the BIOS can't do anything more), switches to protected mode (where all RAM is available), passes control to the beginning of the block and we're off.
Of course, kernels grew larger than 640k, so they were compressed (made into a zImage). The compressed kernel was loaded into the 640k, it is moved to where the BIOS was, startup code (setup.S) switches to Protected mode and control is passed to the beginning of the block, all as before.Now however instead of the kernel, ready to run, the code there (head.S) is unzipping code that decompresses the rest of the kernel into high mem, and passes control to it, and we're off.
Eventually, kernels got so big that they couldn't fit into 640k even when compressed. Kernels larger than 640k when compressed are bzImages. Data is read in 64k at a time, and a helper routine uses a special BIOS call to move the chunks into protected memory. The startup code (setup.S) transitions to Protected mode and passes control to the unzipper at the start of the bzimage (which is sitting in the first part of high memory), which decompresses the kernel, first into low mem until it fills up then into high mem and things run from there. Control then passes to the start of the kernel at the bottom of low mem Typically things run thus: and we're off.
Obviously, not many people boot from floppies nowadays. When booting from the hard drive, things run slightly differently.
The first thing that runs is of course still the BIOS. It runs some tests, then loads the contents of the first 512 byte sector (MBR), which is the bootsector of some bootloader. The bootsector then either loads another bootsector - typically from the start of the active partition - (chain loading) or a second stage boot loader. Once you choose which OS to boot (or if there is only one), the bootloader loads the corresponding kernel (or chainloads another bootloader that loads the kernel). If the kernel fits into 640k, it's loaded into into low mem, bzImages are loaded into high mem via BIOS calls.
The bootloader then then passes control to the startup part of the kernel (setup.S). From here, things proceed similarly to how they do when booting from a floppy. If the kernel is not compressed, the startup code transitions to protected mode and hands off to the main kernel. If it is a compressed kernel, the startup code transitions to protected mode and control passes to the unzipper (which is at the beginning of low mem for a zImage, or at the beginning of high mem for a bzImage). The zImage unzipper unzips the kernel to high mem and gives it control. The bzImage unzipper unzips the kernel into low mem then high mem, and gives it control. And we're off
Conclusion:
So while the PC does have some strange 640k limits still today (not really 64k), kernels are hardly expected to fit into 640k: several kludges have developed to get them loaded. And needless to say, once the processor has left real mode for protected mode, all pretense of a 640k limit can be dispensed with. I might be missing something, but I see no evidence of a
64k limit anywhere.