Peter Ritchie's MVP Blog

Has ANSI C/C++ Been Perpetuating Unsecure Computing?

Whatever Happened to sprintf(..., "%n", ...)?

Strsafe.h: Safer String Handling in C

Security Enhancements in the CRT

Many 3rd party libraries model their API around the ANSI C/C++ libraries, introducing the capability of buffer overruns.  Is using a ANSI C++ library/compiler a good thing anymore?

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:

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:

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.