Pot to Kettle: "You’re Black"

I distinctly remember in the first round of antitrust suites against Microsoft there were complaints that the default Windows installation included a link to the MSN Internet Service Provider sign-up URL.  AOL was included in this debacle.

Recently I had to install the Netscape browser to get to the bottom of a problem a client was having only when they used Netscape.  Going through the install process, I made sure only the browser was installed, ensuring there wasn't even a desktop for it.  Lo and behold, I now have a AOL sign-up icon on my desktop and my Start menu.

I love how companies like AOL and Sun cry foul when Microsoft does something they don't like.  Put in the same situation–despite there now being a precedence for an action not being legally acceptable–they do the exact same thing they were whining about.

Give me a break.

Schedule at Least a Three Hours When Installing Visual Studio 2005 Service Pack 1 Beta

Yesterday, I got Rob Caron's, the Visual C++ Team's, and various other emails about the just-released VS 2005 SP1 Beta.

After getting my approval to download it, I did just that.  I then quickly proceeded to install it.  It took well over 10 minutes to inform me that I have Web Application Project add-in (WAP) installed and it must be uninstalled before proceeding.  10 mins?  I knew SP1 has Web Application Projects built-in, so I guess I understand.  But, 10 mins?  So, I pressed OK and waited a couple more minutes before the dialog went away.  I then went to uninstall WAP, then the SP1 Beta install sparked up again!  After about 10 mins the same message appeared.  This occurred three times before it finally stopped.  That was about 45 minutes blown and I haven't installed anything yet.

I proceeded to uninstall WAP, and started the SP1 install process again.  As soon as the installation was started I noticed that despite the CPU not going much above 10% my whole system was not very responsive.  "Preparing to install…" was all I saw for 11 minutes before that changed to "Please wait while Windows configures Microsoft Visual Studio 2005 Premier Partner Edition – ENU".  Odd, I thought–I have Team Suite installed.  5 minutes later I was presented with "Do you want to install Microsoft Visual Studio 2005 Premier Partner Edition – ENU Service Pack 1 (KB918525) on Microsoft Visual Studio 2005 Premier Partner Edition – ENU".  I just assumed it really mean Team Suite.  So, I clicked Yes and was presented with the EULA then "Gathering required information…".   This continued for a minute or so when I was presented with "Time remaining: 3 minutes".  6 minutes later, that changed to "time remaining: 37 minutes".  Here is where I wonder why can't this application tell time, and time remaining for what?  Was it expecting to take 3 minute to calculate that 37 minutes was required to install, or has it just given up and decided it was wrong with 3 minutes (which it seemed to be) and it should really take 37 minutes.  This is what you do when your system is basically unusable and you've got about 37 minutes to do nothing (1hr and 14 minutes, if the program's accuracy with 3 minutes was any indication).  14 Minutes later that changed to "time remaining: 0 seconds" and the progress meter was at 100%.  This his looking more promising then the actual 3 minutes time frame.  Alas, that remained for another 5 minutes until I was presented with "Successfully installed".  I was happy, but it took 45 minutes (not too far off 37+3).  But, It was short lived because the "time remaining: 0 seconds" returned.  This stuck around for about a minute before it was replaced with "Preparing to install…".  That stuck around for 4 minutes before I was presented with "Please wait while Windows configures Microsoft Visual Studio 2005 Team Suite – ENU" and "Do you want to install Microsoft Visual Studio 2005 Team Suite – ENU Service Pack 1 (KB918525) on  Microsoft Visual Studio 2005 Team Suite – ENU".  Well, at this point I was thinking that it had already installed what it should; but I've had really bad luck when not continuing with Microsoft installs so, I just proceeded.  Long story short, this repeated again for Visual Studio 2005 Team Explorer.  I turns out I technically have three versions of Visual Studio 2005 installed and the service pack ran once for each.  Yuck.  That's 2 hours and 45 minutes.  (not including the first 45 mins or so while it complained about WAP).

For those who haven't installed SP1 beta yet, be sure to uninstall WAP first.  Might as well save yourself 15 minutes.

More Windows SDK Functions That Are Not Safe

Raymond Chen recently blogged that IsBadWritePtr, IsBadCodePtr, IsBadHugeReadPtr, IsBadHugeWritePtr, IsBadReadPtr, IsBadStringPtr, and IsBadWritePtr have side effects that basically render then useless.

Unlike methods like TerminateThread–when used to terminate any thread other than itself–that was never safe, the IsBadXXXPtr functions seem to not have evolved with the rest of the system and have had no attempt to deprecate them.

Save CBitmap to File

It has always astounded me why the CBitmap class never implemented saving to a file.  Here's a nice and tidy way:

#include <atlimage.h>

#include <Gdiplusimaging.h>

        //…

        CBitmap bitmap;

        bitmap.CreateBitmap(width, height, 1, 32, rgbData);

        CImage image;

        image.Attach(bitmap);

        image.Save(_T("C:\\test.bmp"), Gdiplus::ImageFormatBMP);

The Difference Between Teams and Groups and the Difference Between Leaders and Dictators

Rob Caron recently referred to a very good article Team Doctors, Report to ER.  This article describes some basic problems I often see when I deal with software development groups and their management.

The article alludes to teams being a group of people with complimentary skills that work together, make decisions, are given responsibilities, and are mutually accountable.  It also alludes to leaders as being a person who is a member of the team, delegates decisions to the most capable member of the team, ensures decisions are made, ensures problems don't pile up, keeps members focus on goals, and manages goals/priorities/processes.

Management of software development groups often sub-group people together and anoint someone to manage that sub-group.  They then refer to that sub-group as a team and the person, or persons, managing it as a "leader" or leaders.  The problem I often see is that the sub-group and its management is either not given the mandate or not given the responsibility for that sub-group to actually be a "team" or the manager of that sub-group to be a "leader".  The "leader" is usually just the most senior person and they're anointed as "leader" for political reasons.

Groups of people forced to follow leadership of a person who is not a leader and are not given the mandate and resources to operate as a team are described as a "nonteam" and is doomed to failure.

The article goes on to name some of the symptoms of "nonteams":

  • "Collective Amnesia" – the nonteam wonders why the team exists.
  • "Group Myopia" – the nonteam wonders what they are trying to do; they don't know what the goals are or how to reach them.
  • "Chronic Cantankerousness" – nonteam members often quarrel about insignificant team issues or details.
  • "Losing Life Support" – the nonteam does not have the resources (money, space, equipment, information) to operate as a team.

Some other things I've read recently that would lead me to believe a software development sub-group is not really a "team":

  • Mushroom Management1 – the software development team is isolated from customers/clients and the real world and are only given incomplete, filtered second-hand information about requirements and goals.
  • Shallow Process – Things like ISO 900x only truly mandate that an organization has a process.  If a group says they "have a process"; but that process doesn't really contain any detail for the process' artifacts or guidance on how to complete a task with known quality, they really don't have a process. 

1 Willian J. Brown et al. Anti-Patterns: Refactoring Software, Architecture and Projects in Crisis. Wiley. 1998.

Changing TextBox Text as an Undo-able Action

The TextBox class supports undoing the last action–inherited from TextBoxBase.  Normally the user does this by pressing the undo key (Ctrl-Z if your keyboard doesn’t have a specific Undo key) or by selecting “Undo” from the context menu.  The last action can also be undone programmatically by calling TextBoxBase.Undo() (after calling CanUndo() to see if Undo() will work).


Changing the text in a TextBox so that the change can be undone is not so obvious though.  Changing the Text property or the SelectedText property is not undo-able.  .NET 2.0 added TextBox.Paste(String) (not inherited from TextBoxBase, it’s inherent to TextBox) that replaces the currently selected text and is undoable.  If you want to replace all the text while allowing the user to undo it, simply call TextBoxBase.SelectAll() before Paste(Sting).  For example:



textBox.SelectAll();


textBox.Paste(text);


This side-effect, unfortunately, is not documented–which is why it “is not so obvious”.

Protecting intellectual properties in .NET, Part 1.

One thing that bothers many people and organizations about .NET is the ease of which IL code can be re-hydrated into source code (C#/VB/etc.).  While this has always been a problem with binaries, IL code is a much smaller set of instructions compared to the instruction sets of today's processors and is designed around accommodating high-level-language usage patterns–making it easier to translate into high-level source code.  Native binaries could always be disassembled and the assembler code be reassembled into another, new, application.  But, it was assembler code, and optimized–nearly impossible to translate into a high-level-language, let alone similar to the original code .  Everyone seems fine with this because it doesn't really look like the original code.  .NET IL an be re-hydrated into source that is almost identical to the original–sans comments.

One thing you can do with .NET is to force a method to be precompiled to native code.  This can be done by attributing the method with a little-known, not well documented attribute: System.Runtime.CompilerServices.MethodImpl and setting the MethodCodeType property to System.Runtime.CompilerServices.MethodCodeType.Native.

Some caveats

  • Seems to only work in a FullTrust environment.
  • Since native methods can't be reflected these methods cannot be uses as event handlers
  • May cause some grief for many debuggers.
  • The Runtime severely restricts where methods tagged as Native can be loaded.