HP’s QuickWeb and QuickLook were obscure pre‑boot Linux‑based and EFI‑based utilities that let users browse the web or check email before Windows loaded. Born from HP’s acquisition of Phoenix’s Hyperspace, these features illustrate how manufacturers tried to add value in a market where hardware differentiation was limited, often resorting to hacky firmware tricks that are now largely irrelevant.
HP QuickWeb and QuickLook: A Deep Dive into Forgotten Instant‑Boot Features
Thesis
HP’s QuickWeb and QuickLook were niche, pre‑boot utilities that attempted to give executives a faster way to check email and browse the web. They represent a rare instance where a PC vendor tried to extend value beyond the operating system by embedding custom code in the firmware, but the effort was ultimately hamstrung by limited functionality, poor performance, and a market that moved on to faster SSD‑based boot times.
1. The origins of QuickWeb
- Acquisition of Phoenix Hyperspace (2009). HP bought Phoenix’s instant‑boot platform, but did not immediately use it. The company already shipped a similar product called QuickWeb, based on the Splashtop engine.
- Hardware footprint. QuickWeb appeared on a wide range of HP models – from the Mini 210 netbook to EliteBook workstations. The presence of a globe‑shaped button on the chassis signaled the feature, although the button’s function varied between a true instant‑boot environment and a simple Windows‑hosted browser.
- Implementation details. The OS lived on a normal FAT32 partition named HP_TOOLS. Firmware looked for
HP_TOOLS\QuickWeb\QuickWeb.efiand launched it directly via UEFI, bypassing the traditional MBR bootloader. This made the system appear “boring” from a hardware perspective because it relied on standard UEFI capabilities rather than proprietary tricks. - Evolution of the software stack. Early revisions used Splashtop, later ones switched to the Hyperspace code base. The user experience remained minimal – a web browser, Skype, an email client, and a handful of news widgets. No file‑system access, no office suite, and no persistent storage beyond the EFI partition.
2. QuickLook – an EFI‑resident Outlook clone
- What QuickLook is. Unlike QuickWeb, QuickLook is not a Linux distro. It is a standalone EFI application (
QuickLook.efi) that runs directly from the firmware, providing a very thin email and calendar UI. - Technical underpinnings. EFI supplies a tiny set of services (graphics output, absolute pointer, simple file I/O). HP wrote QuickLook in C, compiled it as a PE/COFF executable with an
.efiextension, and placed it inHP_TOOLS\QuickLook. When the user presses the dedicated QuickLook button, the firmware boots straight into this program. - Data synchronization. QuickLook does not touch the Outlook data files directly. Instead, an Outlook plug‑in on Windows periodically exports the mailbox and calendar to XML files on the HP_TOOLS partition. QuickLook reads/writes those XML files, and the plug‑in merges changes back into Outlook on the next Windows boot.
- Limitations. The UI is sluggish (≈10 fps), lacks hardware acceleration, and offers no true multitasking. It is essentially a proof‑of‑concept that EFI can host non‑bootloader applications.
3. DayStarter – abusing System Management Mode (SMM)
- The claim. HP’s DayStarter supposedly displays calendar events while Windows is booting, a feat that appears impossible because Windows takes complete control of the CPU after the bootloader hands over.
- How it could work. The most plausible explanation is that DayStarter runs in System Management Mode, a privileged CPU mode used for low‑level firmware tasks (thermal control, power management). Code executing in SMM can intercept hardware events, such as writes to the VGA framebuffer, and replace them with custom graphics – in this case, JPEG images of calendar entries.
- Implications. Leveraging SMM for UI purposes is a severe misuse of a feature intended for hardware management. It demonstrates how firmware can be stretched far beyond its original design, but also introduces stability and security risks: SMM code runs with higher privilege than the OS kernel and is difficult to patch.
4. Why HP bothered
- Executive pressure. In the early 2010s, HP executives wanted a differentiator for high‑end laptops. Outlook was the only application that mattered to business users, and the only part of the system they could influence was the pre‑boot environment.
- Hardware constraints. Adding a feature that could not be replicated by competitors required firmware changes. HP could not alter the CPU, chipset, or BIOS without writing custom code, so they chose to embed QuickWeb/QuickLook/DayStarter directly into the firmware.
- Cost‑benefit analysis. The effort yielded a marginal time saving (a few seconds) and a clunky UI that performed worse than simply waking a sleeping machine from an SSD. Nevertheless, the project existed because it was one of the few levers available to a PC OEM.
5. Broader implications
- Firmware as an extension point. The QuickWeb/QuickLook story shows that UEFI, while primarily a boot manager, can host arbitrary applications. This opens possibilities for secure‑boot‑validated utilities, but also for vendor‑specific bloat.
- Security considerations. Running code in SMM or EFI bypasses the operating system’s protection mechanisms. Modern security frameworks (Secure Boot, Measured Boot) aim to prevent unsigned firmware from loading, but legacy machines may still be vulnerable.
- Obsolescence. With modern SSDs and fast OS boot times, the original motivation for instant‑boot environments has vanished. The features are now curiosities preserved on a handful of older HP laptops.
6. Counter‑perspectives
- Utility vs. novelty. Some argue that QuickWeb provided genuine value for users without an OS, especially in low‑spec machines. However, the lack of file access and limited app ecosystem meant it was never a true replacement for a full OS.
- Potential for revival. The concept of a lightweight, firmware‑resident web/email client could be revisited for secure, isolated environments (e.g., a “trusted‑path” browser for banking). Modern UEFI implementations are more robust, and security‑oriented vendors could build on this idea without the hacky SMM tricks.
Conclusion
HP’s QuickWeb and QuickLook were born out of a narrow business need: give executives a few seconds of pre‑boot access to email and the web. The implementations leveraged the flexibility of UEFI and, in the case of DayStarter, the extreme privilege of System Management Mode. While technically impressive, the features were ultimately limited, poorly performing, and rendered obsolete by faster hardware and more efficient OS boot processes. Their legacy remains a cautionary tale about the lengths OEMs will go to differentiate products in a market where hardware innovation is increasingly incremental.
Further reading
- HP’s official QuickWeb documentation (archived) – https://web.archive.org/web/20130201000000*/http://h10025.www1.hp.com/ewfrf/wc/documentViewer?docname=c03057888&doclang=en
- Phoenix HyperSpace project page (archived) – https://web.archive.org/web/20090415000000*/http://www.phoenix.com/Products/HyperSpace
- UEFI Specification (latest) – https://uefi.org/specifications
- Overview of System Management Mode – https://www.intel.com/content/www/us/en/architecture-and-technology/system-management-mode.html
Comments
Please log in or register to join the discussion