How to sneak the Windows 95 credits screen into the build without anybody noticing
The hidden Windows 95 credits screen was snuck into the build under cover of darkness.
Okay, maybe not, but it was snuck in.
The code for the Windows 95 credits was snuck into shell32.dll, in part by writing it in an obscure language nobody understood.
It was written in C++.
At the time, C was the well-tested, well-supported language, having been de facto standardized since 1978 (K&R) and formally standardized since 1989. The C++ language wouldn’t become standardized until 1998. C++ was the language to use if you wanted to live dangerously on the bleeding edge.
The code for the credits is the only code in the Windows 95 shell that was written in C++. Aside from a small amount of assembly language, everything else is in C.¹
Related reading: An insight into the Windows 95 startup sound, and the origin of the Windows 95 credits music.
Bonus video: Composer Brian Orr answers questions about the Windows 95 credits music.
Bonus chatter: Even though Brian in the video says that management mustn’t find out, at least one manager did know about it, because I remember sitting in their office to go over the list of names to include.
¹ The Windows 95 shell was COM-based, but it used COM in C. So don’t say it can’t be done.
Light
Dark
8 comments
Were other parts of Win95 using C++? C/C++ 7 shipped 1992, and around that time the Apps org was shipping MFC and the NT team had been using C++ (I believe in the graphics stack, but it’s been a while since I last read Showstopper). Were any similar investigations happening in Windows at the time?
…writing it in an obscure language nobody understood. It was written in C++. — Raymond Chen, 2021
I don’t know about you, but I still don’t understand C++.
I guess this piece of history kind of reveals why Microsoft C++ GUI stacks always had worse tooling than what the competition was offering since MS-DOS and Windows 3.0 days with Turbo Vision, OWL and MFC.
The Stockholm syndrome of using COM with C, is probably the reason why we then get WRL and C++/WinRT without any Visual Studio tooling support, while C++/CX gets the death row ticket.
Meanwhile VCL has been replaced by FireMonkey and C++ Builder has gone cross platform.
Microsoft some times seems too siloed on its own ways regarding productivity tooling.
So yeah COM can be done with C, and anyone doing something similarity primitive nowadays should be heavily compensated to do so.
“Meanwhile VCL has been replaced by FireMonkey”.
I wouldn’t say that. I spend my days developing commercial Win32 VCL apps at work and non-commercial Win32 VCL apps at home.
I’d rather say that FMX is an alternative to the VCL, which you can use if you need cross platform support (or if you want a “modern” flashy GUI but is unable to design it yourself and you don’t mind the GUI being buggy and inaccessible).
If you only require Win32 support (and in my world, there is no other OS), it is better to use the VCL.
Using Win32 + VCL, you can create amazingly stable GUI apps without any UI quirks. With FMX, you need to be very lucky if the end user doesn’t find a bug the first minute he or she tries the app.
Correct, I should have expressed myself better.
In any case, much better than the current C++ framework offerings from Microsoft.
Sometimes I wonder if they have no idea about the state of competition, and enjoy making C++ tooling a poor companion of .NET VS tools.
Did this happen before the easter egg ban? https://docs.microsoft.com/en-us/archive/blogs/larryosterman/why-no-easter-eggs
I believe the ban was for Windows 2000. 98 and Internet Explorer releases before this had easter eggs. I think Office continued doing them.