Windows kept BOZOSLIVEHERE working after the warning became its name
Calling an exported callback directly created an upgrade burden that a deliberately insulting label could never remove.
Microsoft named a function BOZOSLIVEHERE to scold applications for calling it. Then Windows had to keep answering those calls. The warning became part of the interface it was supposed to discourage, which is a very expensive way to discover that a joke also needs backward compatibility.
Raymond Chen’s account starts with real-mode Windows, where callback functions had to be exported. That made internal routines visible outside the components that owned them. Other developers reverse-engineered the routines, and applications began depending on the behavior they found.
Visibility turned out to be persuasive. If a function can be linked, some program will eventually try it, even when the supported route already exists. That does not make the internal function a documented promise, but it does create a program somebody can buy, install and later blame Windows for breaking (naturally).
Chen identifies BOZOSLIVEHERE’s earlier name as EditWndProc, the edit control’s window procedure. Applications called it directly instead of obtaining the procedure through the documented mechanism. When Windows could stop exporting those procedures, removing them broke existing software. The old entry points came back with names intended to express Microsoft’s enthusiasm for the arrangement.
The compatibility bill grew when Windows 95 moved the procedures to 32 bits. Old callers still arrived with 16-bit expectations. Keeping a name exported would not reconcile the two calling worlds on its own, so the operating system needed a conversion function in between. The detour outlived the shortcut that made it necessary.
Chen describes the result as converting an “illegal 16-bit function call” into the corresponding 32-bit one. That word choice is about an unsupported programming path in his account. It should not be read as a claim that an application author had committed a crime, although somebody maintaining the conversion code might have felt personally wronged.
The useful tension is between an internal design boundary and a product that has already reached somebody’s desk. Redesigning the boundary can be reasonable. Preserving the customer’s working application can also be reasonable. Once those collide, the team maintaining the operating system gets an extra job no interface diagram had volunteered to show.
Renaming the function could communicate displeasure, but it could not remove the installed programs that already used it. That makes this a particularly memorable case of an implementation detail becoming part of real-world behavior. The label had a message for developers; the compatibility code had to deal with what their programs actually did.
For a system with plugins or external clients, the relevant question is which supposedly private surfaces are reachable and already used. A name beginning with an insult will not answer it. Chen’s old example leaves the next maintenance burden easy to imagine: another platform change arrives, and a routine nobody wanted anybody to call still needs somebody to care for it.
The bozos got a conversion function.