OSDev.org

Sure, a passive frame buffer is good enough for debugging output but it is not enough to run a desktop OS. Even without a GPU driver (that would enable hardware acceleration) you don't have access to stuff like display hotplugging (e.g. TV screens or projectors, or even detaching/reattaching some "active" connector like HDMI or DisplayPort), power management (e.g. disabling a laptop screen) and page flipping. Most user-space graphics stacks at least assume that graphics RAM allocation and page flipping is possible so you're going to have a hard time porting existing applications.

Every major desktop OS (including Windows, Linux and macOS) is capable of running "framebuffer only" (GOP or VBE). That pretty concisely disproves the idea that it's impossible to run "existing applications" in that state. Sure, you might not be able to play UHD video or modern 3D games without a proper graphics driver, but the basic GUI works fine and is at least usable enough to run a web browser to find, download and install the necissary driver.

We have a saying "You don't see the forest 'cos you are standing to close to a tree". First of all, almost all of you mix up BASIC with FULL support. You also should think about what's the difference between "standard firmware interface" and "standard OS interface". First would be beneficial for all OSes (hobby and mainstream as well), while the latter only for one specific OS' drivers.

@zaval: UEFI is over-complicated for only booting an OS. The truth is, 90% of it's library and complexity is not needed for that. If they were planning only for booting an OS, they should have designed a much more simpler and more sophisticated interface. And it's a common criticism, not just my opinion (Linus would agree too). My argument here is that while you can use BIOS VESA and disk interrupt in runtime, you can't use GOP. (And for god's sake, let's forget about real-mode, that's not the point here! It's just an ABI detail in this case. There is a way to change resolution (regardless to video card) and read/write disk (regardless of it's controller) from your OS with BIOS, while under EFI there's no way at all, you MUST implement native drivers and have all of them loaded at boot time, no fallback possible).

A modern OS could benefit a lot from BlockIO and GOP and the others. I agree with mallard. Also, using firmware's interface for the device under "boot" mount is not only reasonable but desirable as it removes a couple OS layers and driver code. Nobody cares if reading/writing the /boot partition is slow, reliability is more important. Also BlockIO would be great to save a freshly downloaded SCSI driver to a SCSI disk for example. The same applies for network cards and all other devices. In lack of native driver that FULLY supports the device it would be better to have a fallback option with BASIC features than having nothing!

@Korona: I don't agree with you. Passive framebuffer is ENOUGH for a desktop OS used at a typical workplace. It's enough for all office, server administrator and programmer tasks: terminals, picture viewer, document writing, spreadsheets, presentations, displaying graphs, reporting, documentation reading, print previews, emailing, browsing, using IDE, simple games (chess, go, solitaire, space invaders etc.), form management (for configuring the system or filling database records) and even simple animation effects. With good design, you can also play SD video, and probably 720p too. Mplayer used to have an fb driver for console tty under Linux, and it worked pretty well. I also remember 3d games before GPU was invented. Sure, they did not looked like a movie as today's games, but worked. Again, please don't mix up BASIC with FULL support.

I did not even mention the problem of bad performance due to lacking graphics acceleration. My point is that there is more to graphics cards than just 3D acceleration and mode switching. Features like turning off laptop/tablet screens and being able to plug in projectors are expected from modern desktop OS. If a desktop OS requires a reboot if I unplug my DisplayPort monitor and reattach the connector I consider that broken.

Hi,



For this, I'd separate "design" from "implementation".

If an OS design makes it impossible to do things like change displays (without rebooting), control power management, use 2D and 3D acceleration, support GPGPU, etc; then the OS design is broken.

However, if an OS design support all this but the implementation lacks a suitable video card driver, then that's inevitable (no OS has drivers for every device all the time), and because this is inevitable an OS is broken if it can't fall back to "minimal support" (e.g. setting up framebuffer during boot and using software rendering, and not supporting display changes or power management or ...).


Cheers,

Brendan

No, not overcomplicated at all. Booting from everywhere one could imagine is not just quick and dirty MBR code jumping. Basically, the broader the range of boot possibilities an implementer wants, the more he needs to implement. The required bare minimum, is not that "complicated". But to see that, one needs to dig into it deeper than just referencing Linus, who dislikes everything outside linux, and thus - whose criticism only invokes a desire to say: What a big deal.

I don't know what OS layers you are talking about here, and this is way too OS specific, for the FW to care about. remember, it's not some messy "uboot", which only cares about linux and nothing else, it's about a standard for booting any OS. And their intention was clear - it's FW boot services, made for using at boot time. on the boot time, your efi application, OS loader, uses all these possibilities (on the other end, your OS loader is a builder of your OS image/infrastructure and, basically is a part of it ), if it needs to, and only when everything has been read and ready, this link is getting thorn by it, not by FW, now OS has its drivers to manage everything, doesn't it? The same way you may use efi apps for even updating and upgrading your OS, if you want to, downloading your SCSI (sexy) drivers. You may have a whole bunch of efi apps for every need your OS might have, you even have an ability to put it in your own freakin Vendor directory, in the ESP, isn't this cool? you may use everything there, it's just your choice when to do ExitBootServices(). Requiring these services to be present all the way even at run time, sounds just as a caprice, just to find something to pick on. Practically, it will not be a good idea, because the owner of the system at any time should be just one (we already have such parasite "technology" literally, as HV). The same way, blaming the FW for "over-complicated" design and requiring from it some "librarian" kind of support for things like graphics is unfair. What support? For every imagined OS? Probably that support would suck (dead bunnies through bent straws), so maybe you are better off to provide your OS with what support you want.

All I wanted to say, they didn't include all those things intentionally, because genuinely believed it's not needed at OS run time. I see that logical and I am not inclined to jump in a bandagon of "criticism" just becuase Linus told. (I'd rather do opposite )
Efi applications are the key for interfacing with variety of UEFI services. Those are the bridge between the FW and OS. Use this approach to take advantages UEFI represents. Make your OSLoader deeply integrated in both UEFI and the kernel to achieve what you said is desirable.

I didn't say they didn't develop them, I said they didn't develop on them. OK, technically they developed on one of their OSes, but that OS was Xenix (later SCO Unix). This only changed after SCO was spun off, which was around the same time development on Windows NT 4.0 was started.

The switch from hosting their development on Xenix to self-hosting Windows development led to a lot of grumbling by the MS staff, and was the period when the term 'dogfooding' entered the jargon via the Microsoft OS team (it is short for "eating your own dog food" - the term had been around over a decade before then, according to Wicked-Pedo, but it didn't come into general currency until the mid-1990s. It refers to using the tool you are developing. Apparently there was a lot of opposition to this in both the Systems and Apps teams.

^ hahaha, that little "on"
My feeling:


PS. Still, I remember, someone from the NT-team recalled that first months of their work they were typing (documentation) in Word. Aand looking Wikipedia, Word actually appeared first for Xenix.

OK, the Wikipedia article discusses the term in greater depth, and it looks like I was confusing a few different events and claims from that period. I apologize if any of that was misleading.

@zaval: you're missing the point, and you haven't answered to my argument at all. I say it would be great if firmware had an interface that any OS could use to utilize the devices at a basic level, and use a common code on all hardware. And you say no worry, you can develop different applications for every firmware for every OS to do the same. You really do not see the difference?

And your argument that Linus is not right because you don't like Linus is ridiculous. It was just an example, but here are others (after 3 minutes of googling):
https://archive.fosdem.org/2007/interview/ronald%2bg%2bminnich.html
https://github.com/jwise/28c3-doctorow/blob/master/transcript.md
http://techrights.org/wiki/index.php/UEFI (this is a long list)
https://phoenixts.com/blog/booting-uefi-mode/
http://zannyland.blogspot.hu/2012/11/uefi-good-bad-and-stupid.html

And being over-complicated is also not just my opinion (by the way I don't say it because Linus says so, I say that 'cos I've implemented a fair amount of EFI applications already, with the edk, with gnu-efi and in pure asm as well. One of that applications can be found in my git repository too). The clear indicator for being over-complicated is that Lenovo, Toshiba and Samsung were unable implement it properly, and I don't think they haven't hired programmers good enough for the job. Yet their implementations somehow could only load M$ OS, nothing else. Even worse, when I tried to boot a Hello World EFI app on one of my Samsung testbed, it was bricked (seriously, can you imagine that? Using Print() bricks a hardware??? How f*cked up is that?). And what do you think, why do legacy bios boot option still exists on EFI machines? EFI was first introduced more than a decade ago, yet they were afraid to remove BIOS.

And about of OS layers you don't understand: the device drivers of course. If an OS could call firmware's interface as a fallback that would mean it wouldn't use it's own driver stack which would be great for debugging and to update a faulty or missing driver.

There's plenty of evidence that later (4.0+) MS-DOS development was done on OS/2 and basically no evidence at all that NT development was ever hosted on Xenix. The fact that NT (pre XP) had full binary compatibility with OS/2 1.x, but no compatibility with Xenix (and the NT POSIX subsystem was extremely limited, clearly a "box ticker" more than a serious feature) is highly likely due to Microsoft's developers using development tools that ran on OS/2 and wanting to keep using them on NT. The fact that it provided a marketable "upgrade path" for OS/2 1.x customers is more than likely just a "bonus".

Even for MS-DOS, while Microsoft almost certainly used Xenix for editing source code (which would be why MS-DOS didn't ship with a proper editor until 5.0; nobody at MS/IBM thought to create one!) and "source control" (in whatever form that took in the early 1980s), there's also evidence that MS-DOS itself was used to host development tools. Why else would a pre-release disk "leaked" from IBM include an assembler and a tool to exchange code with Microsoft? Surely they're exactly the kinds of activities that IBM would prefer to use their "big iron" for?

There's even evidence that suggests OS/2 was used during development of Windows 1.0 even before OS/2 was publicly released.

The well-known Microsoft "LINK4.EXE" linker shows the heritage. It's the only (known) Microsoft/IBM linker that supports the Microsoft "NE" executable format. It was originally developed for the 1986 multitasking MS-DOS 4 (not to be confused with the 1988 non-multitasking MS/PC-DOS 4.0) which is where the "4" in the name comes from. It was then shipped with all subsiquent Windows (non-NT) and OS/2 SDKs/DDKs as the NE format was used by both. There is no evidence that LINK4 ever ran on Xenix or that any other linker supported the NE format. All NE format executables ever found show clear "signatures" of having been linked with LINK4 on MS-DOS (or an MS-DOS "emulator" like those included in Windows NT or OS/2). While Microsoft no longer ship a compatible linker, the NE format persists; even Windows 10 includes a few such files as it was the format used for the old ".FON" bitmap font files (the font itself it just a "resource" in an otherwise "empty" executable file).

Since Microsoft had no involvement with the 80386 port of Xenix (that was all SCO's work; Microsoft did lead the 8086 and 286 ports), it's highly unlikely that Microsoft used Xenix very much at all beyond around 1987, long before NT 4.0 was started.

Word of god from Larry Osterman (who has been with Microsoft since I think 83 or 84):

Back in 1984, MS-DOS builds were done on Sun workstations running Xenix, and Microsoft’s languages were done on a Decsystem-20 running TOPS-20, but since 1987 or so, all Microsoft development’s been done on a PC based platform (OS/2 originally, then Windows NT).

Thank you for the corrections. I retract my earlier statements, and apologize for my failure to research the topic properly. I am impressed with your work here, in fact.