I think the major "reasoning" behind this is that sticking something as space-consuming as a boot animation inside grub2 is like sticking an elephant's foot up your left nostril.

It can be done, with sufficient pharmaceutical help, but the results are rarely worth the effort.

seriously, how does windows ensure that you always get boot animation, regardless of the driver. Isn't it basically kernel-mode setting

Nope, it's a well-designed boot loader (AFAIK).

Neither flavour of grub qualifies.  Grub2 is arguably the more stupid, since it invents hurdles for itself in order to "exploit" various bits of low-level memory.  Grub1 wasn't very smart, but at least it stuck to what was universally available.  Frankly, at this point, if I was the producer of a Linux distro, I'd stick to LiLO.

Back in my freetarded days, when I was annoyed at the tendency of the Windows boot-loader to shift things two bytes sideways (as I recal) and thereby get in the way of booting Solaris for x86, BeOS, FreeBSD and yes, even a Linux, I looked into the possibility of Contributing to the Community on this.

It's quite a daunting task, and the information available back in the early '00s was a bit sparse.  But it's possible.  I think it would take a dedicated team of four or five people about six months' worth of weekends to get it sorted out.  I mean, these days, there are very few targets out there, and the repeatable QA should be fairly straight-forward.

On the other hand, there's grub2.

And no, nothing to do with kernel-mode setting.  Basic common sense, limited space available, and so on.

And I'm not quite sure how to put this, without sounding like a school-marm, but your grasp of either left-wing or right-wing pedagoguery is slim to nothing, and your grasp of OS theory is, if possible, even less convincing.

Isn't it basically kernel-mode setting?

Well, no, it isn't.  From the point of view of booting an OS up, there's no such thing as rings 0,1,2 and 3.  There's just a limited amount of memory (addressable via BIOS) and no kernel whatsoever.

Nice try, though.

KMS is what allows boot animations early on in the boot process, in Linux at least.im not sure how the bootleader would provide high-res animations like in windows 7.

http://blogs.msdn.com/b/e7/archive/2009/02/18/engineering-the-windows-7-boot-animation.aspx

http://www.freedesktop.org/wiki/Software/Plymouth

im not sure how the bootleader would provide high-res animations like in windows 7.

It would imply some form of mode setting as well. Now, putting aside whether KMS is involved or not (since it's not entirely important to the matter), I must point out though that senility has perhaps got an upper hand in Dr. L's life and now all that he remembers is how Windows 95/98/ME covers the Autoexec.bat/Config.sys loading process by showing you an animated, low-res bitmap image. That's ancient history and not at all representative of how the NT startup process actually works.

Notice ntoskrnl.exe is loaded pretty much right before ntdetect.com (or winload.exe in Vista or later). This implies that the system is entering protected mode as soon as the boot animation begins. This also obviously contradicts whatever Dr L. says about the animation running in real mode.

That poor ol' bugger...

KMS is what allows boot animations early on in the boot process, in Linux at least.

Now, as far as I am aware, the use of DRM does not necessarily translate to the actual use of any hardware features or even KMS. LHB has, in fact, covered that subject to some extent. (Link removed due to potty-mouth filter)

That aside, my point is that you don't need KMS in order to switch display modes. Of course, it would be absolutely fantastic to have it, but the fact remains that Linux has been switching modes without KMS since Day 1.

as explained in the msblog the bootsplash is handled by the bootloader. that limits it to a narrow part of the screen and can't do advanced animations like in plymouth.

@Monco:

Salinity? Who are you to accuse me of salinity?

All I'm saying is that grub is manifestly incapable of doing this sort of thing sensibly, and that kernel-mode has nothing to do with that incapacity.

Not being the sort of dweeb who studies how or when ntoskrnl.exe or winload.exe handles real mode or otherwise, I am simply content to point out this simple fact:

The way that Linux chains through the bootload process is utterly inimicable to this sort of thing.

And what have you done for the cause recently, young toaster? I've got Pogson to admit that he deeply admires Schestowitz and regards him as an unimpeachable authority.  You? You've even stopped posting on the Pog Blog.  Pah.

Oh, that was "senility."

Sorry, a touch of the hams there.

FT is Monco?

Well, the Pope is a Bear...

Aha, I see. :)

as explained in the msblog the bootsplash is handled by the bootloader.

The same source also points out that the primary reason for the bootloader to not employ a larger screen area is "to avoid introducing any delay during the early stage of boot". They aren't saying that it's impossible the way they get it done - they are simply pointing out a larger screen area will result in more unnecessary I/O overheads just to slow down the entire startup process.

that limits it to a narrow part of the screen and can't do advanced animations like in plymouth.

Have you actually tried a copy of Windows 7? Even if you haven't done so already, you can always just go to your cited reference and have a look at what's actually there in the startup animation. Also, notice the page mentions that size of the animation is 1024*768 in 32-bit color depth. This mean even for a static image, you will have at least 3MB (or three times the size of real-mode memory addressing limit) of data to squeeze into your memory-mapped framebuffer.  As far as I am aware, however, you'll be hard-pressed to find a part in the entire sequence that involves nothing more than moving around simple lines or geometric shapes, and I do think I am owed a precise definition of "advanced animation".

@Monco:

"Even if you haven't done so already, you can always just go to your cited reference..."

Wait, wait, I'm getting hot flushes here.  "Haven't," "go to," "cited?"

Never mind.  It's that old Loon salinity coming back to haunt me.

The cognitive bar to entry on the Internet is rather low, isn't it?

The way that Linux chains through the bootload process is utterly inimicable to this sort of thing.

Now, to be fair, GRUB/2 has essentially zilch to do whatever splash screen you see in a distro. In most cases, it is done by USplash/XSplash/Plymouth/whatever built directly into the initial ramdisk. In order words, when you see the bootup animation, you system is running in protected mode.

True, but AFAIK it still depends upon the silly chaining process.

But, OK, yeah, at that point your system is running in protected mode.

I'm not about to split hairs as to the difference between protected mode and kernel mode at this point.  If I was that interested, I would even now be trying to emulate either one on an Intel 4004.

I must admit that I'm almost totally ignorant in all that X.org (plus tons of different extensions), KMS, GEM, DRI/ DRI2 and so on. Given enough incentive OR documentation one could probably become expert on those things, but I won't step into THAT cesspool unless someone pays me for doing that (and I'm fairly OK with navigating other Linux/LOSS undocumented code - that should be telling)

As for Windows's animated boot - I do have some expertise: I've actually replaced boot animation with ZX Spectrum's tape loading effect in XP/Vista time (I don't think Win7/8 is much different in this regard - but I could forget some details).

ntldr/winload does not show any animation. What it does is loading SYSTEM hive, parsing Services branch to find all SERVICE_BOOT_START entries, loads them (with all KM dll dependencies including ntoskrnl.exe and hal.dll) with integrity checking but without actually executing any DriverEntries. It puts all that information (as well as partially initialized memory manager, config manager and so on - so kernel just picks that up without redoing that) into LOADER_PARAMETER_BLOCK and lets the kernel to do the rest.

Kernel initilizes (calls DriverEntry) already loaded boot drivers and among other things it spawns *separate thread* for "advanced animation". As shocking as it is, but this "advanced animation" is just a series of timed VidBitBlt-s (from bootvid.dll).

Obviously this process has a lot of details and tweaks, but it's what it looks like from several miles above. Remember those few seconds early in the boot process when there is disk activity but there is no "advanced animation" yet? That's where boot loader prepares all that stuff for kernel.

Garegin,

Linux doesn't support fancy graphics until X is initalized without KMS, which isn't supported with all graphics hardware. Some tricks including initializing X really early, I think Ubuntu did for awhile.

In a perfect world, we'd all have expoding 3D spinning cubes as potential boot animations, but we aren't there yet.

ahh, so the problem is that KMS doesn't work all the time. got it

In a perfect world, we'd all have expoding 3D spinning cubes as potential boot animations, but we aren't there yet.

And thus why Linux will always lose the aesthetics battle with Apple and Microsoft.