Windows Vista comes closer to it's first year in public, and Service Pack 1 is taking shape.

However, there a still public and open rants about it, and still, probably your software, too, has not been tested on Windows Vista yet!

I'm wondering why that is.

Longhorn Beta 1 made it's first public appearance at the Windows Hardware Engineering Conference (WinHEC) in April, 2005.

If I remember correctly, it was build 4072 and could be installed in virtual machines with only a bit of a hassle.

So all the hardware and also the software vendors had at least one year before RTM to make their stuff Vista-ready.

They didn't. Most still haven't.

Every major software and hardware company has at least some issues with, or outright no support for, Windows Vista, for most or at least some of their products. Even Microsoft. (I'll add links when I'm not too lazy.)

I read a lot of Microsoft blogs but I haven't got word that they rolled out Windows Vista enterprise-wide. May be I missed it but I shouldn't have been able to.

Now, what I know is that at the time Longhorn Beta 1 came out, my business desktop was running Windows 2000 SP4/Office XP and I had to request an exception to get Windows XP/Office 2003 on my business laptop.

And I guess, there are still some companies that haven't even switched to Windows Server 2003/Windows XP/Office 2003.

What this means is, if only a few software developers make the same experience as I do today and haven't got much of a test environment or just "exposure" to Windows Vista, it hasn't arrived in the software industry workplace.

Companies don't switch because they are afraid their old machines and systems don't support Windows Vista. Because there are no drivers. Or the Source Control or bug-tracking software doesn't work. Or they fear issues with older versions of Microsoft Visual Studio or Office or the favorite text editor. Or they have intranet applications that don't run with Internet Explorer 7.

So testing under Windows Vista and fixing bugs in drivers and applications cannot be a day-to-day routine, it's a job to do in an isolated, restricted and limited environment.

Which causes the software we write to have more undiscovered bugs and issues with Windows Vista than with Windows XP or Windows Server 2003.

Which causes the software we sell and, thus, buy, to cause grief trying it under Windows Vista.

A viscous circle.

And even if we buy new machines, those shiny multi-core processors just go to show what other people didn't know about the multi-threading software bugs.

So the hurdles for writing good software today are high. Security, multi-user, multi-core, multi-platform are only a few of the software taxes we commonly pay too little attention to.

Windows Vista also demands for a new look and user interface. Most of us haven't even understood what's that all about this theming thing that was introduced in Windows XP.

And then, on Windows Vista, users are not local administrators anymore. Now you can't write to arbitrary folders on the machine. Even admins are not usually admin.

This almost doubles test cases. And we usually don't have the time to fix the bugs for all the existing ones...

So my thinking is, instead of picking up the pace, Microsoft should slow down and invest much more in developer education and put itself at the forefront of a public software quality push.

And we as software developers and users should learn to not accept bad software. First and foremost, our own.

Internet Explorer has by no means ever been a frugal application, at least not since it's 3rd or 4th incarnation.

But, with IE7, resource usage is on a spree. Even idling with a page loaded from internal resources (e.g. navcancel), almost a hundred K of desktop heap are constantly allocated.

Don't believe me? Check the desktop heap usage yourself.

With standard settings on the default desktop of the interactive window station, this limits the number of open Internet Explorer instances to 60-70.

Now, why on earth would someone try to work with that many Internet Explorers at the same time?

Think Terminal Server.

Think Automation, anybody that comes up with the idea that it's the easiest way to generate and print a report by coughing up some HTML and use IWebBrowser2 and CLSID_InternetExplorer to do the hard work.

Now, look at the sample code from Knowledge Base article 323568.

It should not be used without uncommenting the call to Release. But then, the expectation is that it keeps running until the end of times.

It certainly does with IE6. But not so with IE7.

Not only is IE7 using much more desktop heap upfront. This code also causes it to hang around with a "Navigation Canceled" page and wait for god-knows-who to close the window. So, roughly 128K of desktop heap stay allocated.

And the next call opens a new page, and slowly but steadily adds to that desktop heap usage.

And when we're a service under a certain user account, the out-of-process Internet Explorer get's it's own non-interactive desktop, which is limited by default to 512K, so things go south sooner or later.

Basically, if the iexplore process doesn't terminate after the call to Release, we can print reports for a day or two and then we have to reboot the machine.

Is that a bug in IE7? Probably not. It's probably a bug in the IWebBrowser2 interface specification.

Look at this:

 I just added line 23, a call to the IWebBrowser2::Quit() method. Now, the iexplore.exe process is gone.

Immediately. Before the call to Release. Ouch.

That's not playing by the COM rules, which IMHO state the server should stick around while references are held. An we hold a reference to a proxy to CSLID_InternetExplorer's IWebBrowser2 implementation and this should cause iexplore.exe to not terminate. Then, however, it should cease quickly after the reference count of the proxy hits the floor.

Another example of "wrong by default", the most undervalued anti-pattern in the software industry.

Update: IE7's process does not exit when the page has been printed, and Stop(), Quit() and Release() methods have been called on the IWebBrowser2 interface. Now, that is a bug in IE7. But at least, the desktop heap usage always returns to an acceptable level.

Update 2: It's the Phishing Filter, dude! Disable it manually or, better, for non-interactive service accounts using IEAK7 and Group Policy.

Disclaimer: The code sample has been modified from it's original version. All information and source code is provided "AS IS", for demonstrational purposes only, without warranty of any kind, neither express nor implied, including but not limited to the warranties of merchantability, fitness for a particular purpose or non-infringement. In no event shall the blog author be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement of substitute goods or services; loss of use, data, or profits; or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of this code sample, even if advised of the possibility of such damage.

My employer recently switched from Symantec Brightmail to Sophos PureMessage. Now I am missing out on the Brightmail Plug-in for Outlook that helped removing and reporting false negatives.

So I hacked something for Outlook 2003 in an almost dead-language. Now I can hit a button in the main toolbar and shoot spam on sight.

Be warned: There are three dangerous functions in this code:

• Permanently deletes selected messages
• Sends message to is-spam@puremessage.net on behalf of the user without confirmation
• Permanently deletes the sent message

For your safety, add a confirmation dialog and error handling.

Apparently you have to enable macros or sign the macro project with a trusted code-signing certificate, or this code does nothing but display warnings.

Please note: Provided "AS IS" without warranties of any kind, neither express nor implied, including but not limited to correctness or fitness for a particular purpose. Under no circumstances shall I be held liable for any damage this code snippet may do, including but not limited to loss of email message or revenue or public respect.

When accessing http://forums.microsoft.com  from Internet Explorer or Visual Studio 2005 Help/Search/Community, you might get a runtime error or the page seems to be loading constantly.

This is due to status codes 500 Server Error or 307 Redirect.

Unfortunately, the 307 redirects to the same location, which is, in fact, an HTTP protocol violation, so from other browsers you might get an "invalid redirect" or "protocol violation" as well.

Delete the microsoft.com cookie. For IE6: Control Panel, Internet Properties, Temporary Internet files, Settings.

Now, try again.

You have to "Sign-in" again, though. [Update: Do not use the “Save email address and password” option!]

This post was brought to you with the indispensable help of Fiddler2, a Web Debugging Proxy and extensible HTTP analyzer by Eric Lawrence of Microsoft.

Oh yeah, it's "Messin' With the Framework" week (or year?). It's my life™.

I did nothing, really. Just adding a little piece of code into an existing Windows.Forms application.

However, my code ended up running into an InvalidOperationException "Cross-thread operation not valid: Control 'NamesAreNotImportant' accessed from a thread other than the thread it was created on."

And it goes to show, the culprit was RunWorkerCompleted calling from the same thread it did DoWork.

That is not supposed to happen! If you claim something else, a cohort of MVP's will call you names ...

Well, ask them about AsyncOperationManager and when it's SynchronizationContext property is set to an instance of WindowsFormsSynchronizationContext in a Windows.Forms application.

Gotcha!

Only while a Windows.Forms message loop is running, which makes perfect sense, given that the whole Invoke shebang uses Windows messages all the way to marshal the calls back and forth across threads.

So, when you call BackgroundWorker.RunWorkerAsync from outside the message loop, e.g. before Application.Run(myMainForm), then you are in trouble.

Because the BackgroundWorker takes a hold on the SynchronizationContext current at the time of invocation of RunWorkerAsync, and relies on it's Post method to marshal the event back to the caller, it may easily end up calling from the wrong thread.

Do not start a BackgroundWorker.RunWorkerAsync before or after Application.Run.

Thank you, Lutz Roeder, I would know diddly-squat without you.