Hitching the UEFI Shell: Platform Moving Beyond DOS (Disk Operating System)The UEFI Shell obligated very humble beginnings. Its origin lies with the birth of the PC and the advent of CPM/DOS. For those who can recall the predominant operating system of the 1980s, it was part & parcel of the original IBM PC and was very much omnipresent for users of computers in that era. In those days, DOS was the boot target. The expectations of the user were a bit more humble than they are today.

DOS exposed limited standardized APIs to access the underlying platform, so the complexity associated with what one could do through the command-line interface was also fairly restricted. However, with the advent of UEFI and the myriad boundaries that it exposed, the possibilities became fairly broad. For instance, within UEFI we have provided abstractions to access networking devices, graphical components, storage devices and a multitude of other things. The possibilities of what a third-party application or script can do are much broader than it was ever possible in the earliest of operating systems..

It should be noted that in many UEFI-compliant platforms, the UEFI shell and its underlying abstractions are all contained on the platform’s embedded non-volatile storage (e.g., FLASH device) and can execute even without a boot media target. This is something that the platforms of old did not provide. On a UEFI-compliant system, you could potentially have a rather robust environment of a complete network stack, UEFI shell and a modern programming environment with memory managers and a driver model.

The first version of what is now the UEFI Shell was created to facilitate the debugging of early parts of EFI. It was never intended to see a customer. It was a simple convenient tool to speed up an EFI developer's job. Its escape to the rest of the world was in retrospect, inevitable because it was more valuable than we realized. It became popular enough that in the eyes of many it was EFI but It was not and it is not. EFI (now UEFI) is a commonly agreed-upon set of interfaces between operating systems, BIOS and option ROMs. The shell is in many ways simply another operating system that sits on top of EFI.

The shell became more and more valuable. Badly suffering from too many hands and not enough guidance, it became complex enough to warrant the serious effort, a seriously out of control adolescent if there ever was one. In the end, it has become valuable enough to warrant the creation of an industry specification and adoption throughout the industry. It is becoming a basis of computer component validation, computer validation and manufacturing, system testing, and applications. Pretty good for something originally intended as a throwaway piece of code to test some EFI drivers.

The Shell started its life in 1999 or 2000 (we don’t exactly remember) so it is comparatively a newcomer. Yet it is in many ways a throwback to (at least what now) seems a much simpler time say 1970 or so. It doesn’t run protected code, has a swap file or a registry or even a GUI. As far as we know it doesn’t even have a virus scanner.

We’ve discovered there is still a place for a small, simple, developer’s environment that provides enough resources and support for complex programs without getting in the way of applications that need to (or at least think they need to) “own the system”.