> I did't mean that the INT calls are slow. I don't know it. The time > needed to come to the LILO prompt is too long with normal BIOS.
Some habits die hard. I am working with lovely headless servers - no graphics - but a dumbass BIOS which still religiously "counts the memory", "clears the screen", and has opportunities for "pressing a key" - which is a bit ridiculous on a serial line to a minicom. I can quite imagine that this vendor wanted to do things differently - but they have to sell to Windows users, and there are expectations to be met. And, yes, if relations progress, I'll ask about LinuxBIOS support... > I'm really interessted in the reason why it is so slow !? First, expectations. Windows users just expect booting to be slow (and most, if asked, probably think that something terribly complex is going on), so why would BIOS vendors be bothered? In the time I've been doing this sort of thing booting, processors have become 1000 times faster. Boot time (hard reset to OS start) has generally become SLOWER; which makes it seem all the wierder that users of the OS booted more than any other don't complain. Second, vendors now want you to watch animated logo, or be able to use their "Special Setup" with their own "three finger salute" - the system vendor, the graphics card vendor, the SCSI card vendor. These are the customers of the BIOS suppliers, not us poor saps, and the customer is, by definition, always right. > As far as I have understood Rons answer, the problem of support for > other OS like windows is the lack of INT functions that they use. Reproducing INT functions to support the OS is one way to run apps, but not the only one. Linux and the open source projects for firmware and Windows support - (LinuxBIOS, NILO, OpenBIOS, Plex86/Bochs, Wine etc) are heading towards making a platform for Windows apps which is *better* - efficient, reliable, fixable - than Windows. I've been surprised by the progress in the last couple of year of projects acheiving "critical mass" - not maturity, but enough support that they are actively developed. If the objective is running a Windows application - not Windows per se - then there's scope for optimism.
