Happy (Belated) Easter

So a while back there was big news about some secret code in IE that used “Netscape engineers are weenies”.  I only know what I read in the newspapers about this, and the fact that internally MS outlawed any and all 'Easter Eggs'.  We were given a brief moratorium in which we could remove the code without any questions asked, after that any such code would be grounds for termination.

Yes this probably makes for higher quality software.  Yes this makes MS engineers seem more professional.  But part of me just wants to scream, “If artists can sign their art, why can't I sign my art?”  Of course that begs the argument of whether programming really is software engineering or some sort of black art.  My personal opinion is that it's a little bit of both.  Mostly engineering, but the difference between good engineering and great engineering is definitely creativity, which I call art.  Alas I digress, so back to the topic...

Since there are no more Easter Eggs, the closest thing I can do for an Easter/Passover/Name-Your-Favorite-Non-Denominational-Spring-Time-Holiday present is a extremely under-documented feature hiding inside alink.dll.  If you've been reading my other ALink posts you'll realize that because it's in alink.dll, it affects C#, VB.NET, and C++!

So everybody hopefully knows you can put a star “*” for either of the last 2 version numbers of the AssemblyVersion attribute.  ALink will then translate that into the days and minutes since January 1st, 2000.  Well, here comes the feature: What if you don't like January 1st 2000?  Well, you can change it.

[Fill-in here with the usual disclaimer about being careful not to hose your system by messing with the registry]

Create a key named [HKEY_CURRENT_USER\Software\Microsoft\ALink].  Then add a DWORD value named “VersionStartDate”.  Now here's the hacky part.  The high-order 16 bits is the start year (minus 1900), the next 4 bits are ignored, the next 4 bits is the month (January == 0), the next 3 bits are ignored and the low-order 5 bits is the day of the month (0-based).  All numbers are unsigned, so you can't have any year before 1900.  The relevant bit masks would be:

year  = 0xFFFF0000
month = 0x00000F00
day   = 0x0000001F

So January 1st 2000 looks like: 0x00640000.  But if you're a purist and believe the new century didn't start until 2001, it would be 0x00650000.  Or maybe you prefer to use the Chinese New Year (February 5th 2000 if my sources are correct): 0x00640105.


Comments (7)
  1. Sean Terry says:

    Nice. I always wondered how those were generated.

  2. John says:

    Interesting post – thanks Grant. In follow up, what are some of the reasons people have used to actually change the start date? I would imagine egomania would be one: version numbers shall reflect the time passed since the time of my birth, marriage, parenthood, etc.

  3. GrantRi says:

    I haven’t heard of anybody actually doing this, so I can only speculate on reasons. Generally if I was only working on a single product, I woul reset it so that it started at 0 days whenever I incremented the major or minor build numbers. But that’s just speculation.

  4. joviol says:

    Is it possible to change the behavior to decide, for exemple, to put as third param the current day (ex:60424) and last one the build number which increment itself at every build?

  5. Nope, the algorithm is has already shipped, and there’s no changing it now.

    Also due to Win32 backwards compatbilty, each component is limited to 16-bits, thus 0x60424 would not fit.

    Lastly, alink.dll doesn’t realy have any place to persist storage, so it has no clean way to ‘increment at every build’.  You get something very similar to that because the last build number is the number of seconds since midnight, thus each successive build throughout the day will have ever increasing build numbers, and will automatically start at 0 the next day.

Comments are closed.

Skip to main content