Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Early Easter Eggs

Early Easter Eggs

  • Comments 65

Jensen Harris's blog post today talked about an early Easter Egg he found in the Radio Shack TRS-80 Color Computer BASIC interpreter.

 

What's not widely known is that there were Easter Eggs in MS-DOS.  Not many, but some did slip in.  The earliest one I know of was one in the MS-DOS "Recover" command.

The "Recover" command was an "interesting" command.

As it was explained to me, when Microsoft added support for hard disks (and added a hierarchical filesystem to the operating system), the powers that be were worried that people would "lose" their files (by forgetting where they put them).

The "recover" command was an attempt to solve this.  Of course it "solved" the problem by using the "Take a chainsaw to carve the Sunday roast" technique.

You see, the "Recover" command flattened your hard disk - it moved all the files from all the subdirectories on your hard disk into the root directory.  And it renamed them to be FILE0001.REC to FILE<n>.REC.

If someone ever used it, their immediate reaction was "Why on earth did those idiots put such a useless tool in the OS, now I've got got to figure out which of these files is my file, and I need to put all my files back where they came from".  Fortunately Microsoft finally removed it from the OS in the MS-DOS 5.0 timeframe.

 

Before it flattened your hard disk, it helpfully asked you if you wanted to continue (Y/N)?.

Here's the Easter Egg: On MS-DOS 2.0 (only), if you hit "CTRL-R" at the Y/N prompt, it would print out the string "<developer email alias> helped with the new DOS, Microsoft Rules!"

To my knowledge, nobody ever figured out how to get access to this particular easter egg, although I do remember Peter Norton writing a column about it in PC-WEEK (he found the text of the easter egg by running "strings" on the recover.com binary).

Nowadays, adding an easter egg to a Microsoft OS is immediate grounds for termination, so it's highly unlikely you'll ever see another.

 

Somewhat later:  I dug up the documentation for the "recover" command - the version of the documentation I found indicates that the tool was intended to recover files with bad sectors within it - apparently if you specified a filename, it would create a new file in the current directory that contained all the clusters from the bad file that were readable.  If you specified just a drive, it did the same thing to all the files on the drive - which had the effect of wiping your entire disk.  So the tool isn't TOTALLY stupid, but it still was pretty surprising to me when I stumbled onto it on my test machine one day.

 

  • A strong argument in FAVOR of having easter eggs in your products:

    http://headrush.typepad.com/creating_passionate_users/2005/05/the_case_for_ea.html

    The bottom line, is that all the easter eggs I can think of in past products were pretty simple/silly/innocuous.

    I always liked the "screensaver" eggs: putting "Volcano" in for 3DText, and the "Teapot" easter egg in the 3DPipes screensaver (change the joint type to mixed). Both of these are gone in Windows XP. It a shame. They were fun and cool, and did no harm.

    And now I don't have any more excuse to stare at the 3DPipes screensaver for hours :)
  • Wow. After reading jwz's take on easter eggs, all I can say is that if creating easter eggs means I have to stretch my workday from eight hours to sixteen, twenty, or even ten or twelve, then screw the easter eggs. I'm fixing my bugs and then going home to my family.
  • <p><i>What would you rather have him or her do: (a) add an easter egg, which increases the code size with zero benefit to any end-user, or (b) work toward fixing a bug or finishing a new feature?</i></p>
    <p>Anybody that could say this has obviously never been a programmer. Or if she/he has, she/he must hate his/her life. Hacking up some clever trick under your own direction is actually <i>fun</i> for a few strange people. Working on finishing some new crap feature invented by the marketing team that needed one more bullet point for the upgrade brochure is very rarely fun. Fixing a bug is usually as much fun as performing a root canal on yourself using only an ice cream scoop and soldering iron.</p>
  • If you want to have fun, go home and see your wife and kids. Play a little bit of touch football in the hall. Go play in the street.

    Just don't add garbage to the software.

    If easter eggs are your idea of fun, then I am glad you don't work for Microsoft, Joel.
  • "The Open Source movement's got it all wrong: it's not software that needs to be made free, but the people who use it. And the people who write it."

    Actually the Free Software Foundation's list of freedoms /are/ all about the users, and by definition programmers are also users. It would be absurd to give "freedom" to an abstract computer program.

    e,g, Freedom zero is the freedom to use the software. Seems obvious enough, but most EULAs try to restrict even this basic right which should have been granted to you by the Doctrine of First Sale. e.g. they'll pretend that you ought to have paid extra for each computer where you use the software, or for each CPU you'll run it on, or that you need a different version if you use it to run a business or ...

    You typically won't find many Easter Eggs in Free Software, because unlike MS employees, a Free Software hacker working on a spreadsheet who has an urge to work on a flight simulator can just download the flight simulator code, hack on it in his free time, and contribute back his changes.

    I guess Microsoft has no reason to tell corporate customers that if they can't find the barely concealed Easter Eggs they'll certainly never find the intentional backdoors... of course these backdoors are professional, perhaps huge corporations take blackmail by Microsoft (or by ex-employees) in their stride while a hidden space invaders game in the OS code is too much for them.
  • Mostly I have no opinion on the presence or absence of Easter Eggs. If someone or some management system is dedicated to perpetuating bugs instead of removing them, that's a problem. But if people are doing their jobs right, there's not really a problem, usually. If someone wants to use their free time to create an Easter Egg instead of joining a traffic jam to a baseball game or whatever, why complain?

    There are two exceptions though. One is that a security flaw in an Easter Egg is still a security flaw, a bug that invokes an Easter Egg when it wasn't supposed to do so is still a bug, etc. The other is something that I'm inferring from some of the postings here.

    The English language version of Excel 95 included an adventure game? Is that why the English language version of Office 95 needed twice as many CDs as the Japanese version needed?

    On the whole one might expect Japanese versions of software to be around 5% to 20% bigger than English language versions. There are some odd cases where Japanese versions are smaller than English language versions, but still usually they're within 10%. The MSDN library is a big one, the Japanese version is half the size of the English language version because half of it hasn't been updated in 10 years and maybe because no one noticed how much stuff Microsoft forgot to put in it in the first place. But Office 95? How could the Japanese version of an Office suite be half the size of the English language version? And now I'm discovering that it's because of an adventure game? That's surely over the top.
  • "Phaeron, say a member of the Word team has two hours spare - paid, unpaid, or whatever. What would you rather have him or her do: (a) add an easter egg, which increases the code size with zero benefit to any end-user, or (b) work toward fixing a bug or finishing a new feature? "

    My guess is that most really good software developers will probably want to do more than just churn through defect reports. As much as management would like to believe that their staff should dedicate every 'productive' hour to their cause, it just doesn't (and shouldn't) happen that way.

    Specced out 'easter eggs' sound like a plausisible comporomise between security and fun/panache, and maybe a decent way to create incentives for developers. When they were desigining the second generation Ford Taurus, Ford program management used the the (Yamaha V8 powered, 240HP, High equipment level) SHO Taurus development program as a sort of carrot for developers. Sort of along the lines "stay on budget or we'll cancel this thing we know you want to work on".

    -Mike

    PS: For some reason, this sub-thread reminded me of this:

    http://www.digibarn.com/collections/songs/ibm-songs/

    Ever onward! ever onward!
    we're bound for the top to never fall,
    right here and now we thankfully
    pledge sincerest loyalty
    to the corporation that's the best of all
    our leaders we revere
    and while we're here,
    let's show the world just what we think of them!
    so let us sing men - sing men
    once or twice, then sing again
    for the ever onward IBM!


  • At a large shrinkwrap company, I think banning unspecced easter eggs makes sense. The problem is that untested software always has bugs. I don't care how good of a programmer you are. These bugs might be somewhat innocuous (the text in the easter egg doesn't display properly in non-English language operating systems) or serious (after a certain date, the app just crashes).

    I heard a story about a large vendor who had a date triggered easter egg (I think it changed the info panel) which wound up crashing the app on Japanese operating systems. Since QA didn't know about the easter egg, they didn't test it, and since developers rarely test (or are even able to adequately test) in other languages, the developer didn't test his easter egg in Japanese. The result of this easter egg was that a couple of months after shipping, all copies of the software were crashing in Japan, and the vendor had to do (an expensive) recall of their software.

    Regardless of how accurate this story is (I'm third hand now, so maybe it's just programmer urban legend), the scenario is plausible enough that I bet at least a version of this has happened. Even so, I personally don't think that easter eggs should be banned. As many have pointed out, giving programmers an outlet for some freeform creativity is a good thing. Arguments about wasting time and impacting schedules don't cut it. I just think that once implemented, easter eggs should be specced and tested. While the suits might not get the idea that any amount of their schedule was dedicated to something as trifling as this, I think the benefits outweigh the costs. Also, if they don't give an official outlet for it, they might fall victim to the kind of problem I described.
  • Wow - back in the old days I wondered what the use case for 'recover' was (and that was before I had ever used or heard the term 'use case').

    Recover always seemed like a trojan horse; a utility that sounds like it'll undelete a file (or something nice like that), but instead essentially trashes your drive.
  • I would like to point something out:
    Recover.com Easter Egg (DOS 2.x) is activated
    by CTRL-W, not by CTRL-R ...
    Syntax is Recover.com \filename.ext | x:filename.ext | x:
    extra parameters are ignored (brutally)
    *DON'T* run that version on DOS 3+
    Recover.com of DOS 2.x uses undocumented DOS calls (Int 21h/1Fh, Int 21h/32h) and internal DOS data structures (DPB), changed in 3+, so it is potentially dangerous.
    Besides, Int 21h/1Fh fails on FAT32 HDs ...
    "...Microsoft rules ok" ... the style of the code is quite recognizable ...
  • Tuesday, October 25, 2005 3:10 PM by eak

    > These bugs might be somewhat innocuous (the
    > text in the easter egg doesn't display
    > properly in non-English language operating
    > systems)

    Funny, many ordinary programs (without Easter eggs) display exactly the same behaviour.

    > or serious (after a certain date, the app
    > just crashes).

    Funny, many ordinary programs (without Easter eggs) display exactly the same behaviour, even when running in the same language environment that they were supposedly tested in.

    > I heard a story about a large vendor who had
    > a date triggered easter egg (I think it
    > changed the info panel) which wound up
    > crashing the app on Japanese operating
    > systems.

    I didn't hear about it, but it sounds like a likely possibility. The same happens with ordinary programs without Easter eggs. Sure if an Easter egg adds bugs then it's bad, but the important thing (well, important to some people) is to fix the bugs. Who cares what part of the program the bug is in.

    > and since developers rarely test (or are
    > even able to adequately test) in other
    > languages,

    For a program intended for domestic consumption that's frequently true. But if a program is going to be exported then good companies do hire a few programmers who can speak English or whatever. (Even if theoretically there's nothing special about English, for some reason it's usually the first language that anything gets translated into when exports are planned.)

    Some companies don't understand issues involving fonts and such things though. For example even when all the strings have been translated into English, a help file or something else might still demand that the user install Japanese fonts because some default settings are still in place. I had to persuade one or two companies to set up an English-language Windows system without Japanese fonts in order to test their export versions.

    A famous vendor of Windows OSes still too often forgets to test the opposite kind of case. A famous employee of that famous vendor even admitted privately that non-English-language versions don't even get as much testing as English-language versions. But they don't recall their products when recalls are warranted.
  • Used to be, when you'd buy something from a merchant in and around New Orleans, they'd throw just a little more than you'd asked for into the bag. They'd call this "lagniappe," a Cajun word that means, loosely translated, "a little something extra."

    After discovering the science of perspective, Renaissance artists would paint intentional errors into their masterpieces to convey their understanding that true perfection was the realm of the divine.

    I wouldn't argue for the intentional coding of bugs, but an industry that can no longer tolerate the pride and humor expressed in the famous Excel 95 Easter egg has lost a bit of its human soul, and therefore its capacity to grow.

    Perhaps the next generation of creative developers will redefine the Easter Egg in a way that lets them off the hook. Or perhaps they'll work somewhere where they have the freedom they require.
  • The development tool software house I worked for in the 1990's was famous for their funny easter eggs . . . until one day, the word came down from on high that they would no longer be allowed or tolerated. The reason given was that it allowed headhunters to cherry-pick our developers by publishing their full names with the product.
  • Easter eggs don't have "zero benefit to the end-user". If they did we wouldn't be discussing them. If they they did, the countless sites about easter eggs wouldn't exist. People enjoy discovering and sharing them, and they build some sort of loyalty to the product.

    Insignificant, perhaps, but not zero.
  • The word you're missing when discussing Easter Eggs is "PRIDE". Easter eggs wind up in software because someone is proud of their work. The original easter egg in a game was put in there because the programmer wasn't getting any credit anywhere in the code, on the box, or in the manual... and he was proud of what he'd done.

    You want software written by people who take pride in their work, the same way you want a car built by someone who isn't disgruntled at his employer or food served to you by someone who hates their customers.
Page 3 of 5 (65 items) 12345