An interesting meme I've encountered a number of times amongst c#/Java programmers:

   Low Level c/_asm programmers are 'smarter' than the rest of us.  Kernel hackers are psuedo-gods.

Ok, I've worked with a wide variety of programmers.  Embedded programmers, Driver developers, EE/ board designers, Windows Programers, Unix 'hackers', Java devs, .NET developers, etc.
One of the things that I've noticed is that each developer usually considers his technology superior, and others just don't get it.

Actually, I think that they are all correct.  Or all incredibly wrong.  Take your pick.

Embedded Developers:  Can hack 'C' like there's no tomorrow.  Typically push memory around like it's ice cream.  These developers excel at handling low- and out- of memory conditions.  You'll rarely see an Embedded programmer fail to handle a memset failure (or new(), though that command would be rare..!).  My experience is that C++ is a major leap for many embedded developers, and Classes are certainly a difficult construct to grasp.

Driver Developers: (See Embedded Developers)

EE / board designers: It always amuses me when EEs think that they can both design the board, and write software for it.  Truthfully, you can be successful at one or the other, but not both.  In my experience, EEs really don't understand the concept that the hardware actually does fail.  Usual shortcomings amongst these developers include a failure to handle error conditions, and a lack of understanding of higher language constructs such as events, classes, and exceptions.
MFC/ATL/Windows developers: These programmers present an intimate knowledge of the arcane structures, return codes, and other esoteric knowledge required to leverage the Win32 API.  Unfortunately, these engineers are too stuck in the middle - too high in the food chain to know everything that's going on underneath them, but too low to be able to excuse that lack of understanding. 

Java Devs:  They really wish that "Write-Once, Run Everwhere" had some actual truth.  Oh, and real runtime supported generics would be nice.  Hacks need not apply.

C# Developers:  Trying to be more respectable than VB.NET, these developers strive to impress everyone else with there knowledge.  Eschewing VB.NET's "My" namespace, most of these developers would rather pretend that they code everything on their own.  However, the .NET GC is there to pick up the errant memory leacks that c# developers enevitably 'cast' aside.

VB.NET developers: I refuse to touch this flamebate language.  I won't even say the obvious.  Draw your own conclusions, please.

Unix 'hackers': Major flaw:  There really is such a think as 'best tool for the job'.  Sometimes that tool is *nix.  Sometimes it really is Windows.  /. Readers need not apply.

Did I miss your pet language?  (LISP, Ruby, Python, PERL, Delphi, VB, PHP,......)
There was a reason for that - no one cares.  Least of all, me.

Have a good language war - see you next Armageddon.


My new favorite line of code:


From Tobin Titus's new


The PDC 'scheduler' is out - visit


My tentative schedule of breakout sessions:

11:45 AM - 12:30 PM - FUNL02 Lap around the WinFX and Win32 SDKs
1:00 PM - 2:15 PM - DAT301 High Performance Computing with the Windows Server Compute Cluster Solution  
2:45 PM - 4:00 PM - DAT303 SQL Server 2005: Building Distributed, Asynchronous Database Applications with the Service Broker
4:15 PM - 5:30 PM -COM304 Networking: Building IPv6, Firewall, and IPsec Aware Applications  

11:00 AM - 12:15 PM - COM200 Applications and Communications Roadmap: Platform Presents and Futures
12:30 PM - 1:15 PM - TLNL06 Tips & Tricks: Scrubing Source Code for Common Coding Mistakes (FxCop and PreFast)
1:45 PM - 3:00 PM - PRS309 Windows Presentation Foundation ("Avalon"): Overview of Windows Vista Graphics
3:15 PM - 4:30 PM - DAT411 SQL Server 2005: Extending and Embedding Integration Services (ETL)
5:00 PM - 6:15 PM - COM416 Windows Communications Foundation ("Indigo"): Under the Hood of the Windows Communications Foundation Channel Layer

10:00 AM - 11:15 PM - FUN412 Five Things Every Win32 Developer Should Know
11:45 AM - 12:45 PM - PRS320 ASP.NET: Future Directions for Developing Rich Web Applications with Atlas (Part 2)  
1:00 PM - 1:45 PM -  PRSL03 Ten Amazing Ways to Speech-Enable Your Application
2:15 PM - 3:30 PM - DAT219 BizTalk Server Future Directions: 2008 and Beyond  
3:45 PM - 5:00 PM - COM325 Workflow + Messaging + Services: Developing Distributed Applications with Workflows  
5:15 PM - 6:30 PM - FUN034 Windows Vista & "Longhorn" Server: Improving Reliability with the New System.Transactions Classes, File System and Registry Transactions  

8:30 AM - 9:45 AM - COM430 Windows Communications Foundation ("Indigo"): A Deep Dive into Extensions for Security and Identity  

Well, apparently my PDC letter worked.

PDC'05 - Developer Powered

I'll be going to the 2005 PDC.  See you there!

Dear <Boss>:

As my overlord and my unqualified mentor, I am terrified about presenting you with a self-serving opportunity to contribute to my overall geek cache. Whenever Microsoft gets excited they hold the PDC Conference where some of the world's most anxious-to-party developers gather to share and party.

Attending this conference will help me become more informed about upcoming Microsoft bad haircuts, so I can start using them in my job as soon as they're available. And it will help me become more informed about the future of the ubernerd industry. So whether you need my input in deciding what overpriced new hardware to purchase, or what features our next payment for your boat should include, I'll be a more unfireable cube jockey.

As you can ascertain this is a tremendous developer free-for-all that any savvy developer would have to be incarcerated to miss. Thank you very much for your unqualified consideration.

Yours compulsorily,

Jerry Dennany
Software Engineer

(Autogenerated from

Posted Monday, July 25, 2005 10:24 PM by jerdenn | with no comments
Filed under:

 Credit goes to Michael Trantow for the following:


Undefined behavior getting you down?  Now you can refine your searches to find that needle in the proverbial development haystack with the new Google tool, DennaNoogle. 

Now in beta, the new search tool was developed and refined by Google in conjunction with longtime Googlist Jerry Dennany. Try the tool today.  Better yet, for a limited time, get a free DennaNoogle demo by visiting Jerry in his Cuble.  Dennany will also be presenting the seminal PodCast “Google Is Your Friend”, available soon for download on Kazaa, or you can pre-order the DVD at Netflix.


DennaNoogle (beta)
Posted Friday, July 8, 2005 1:09 PM by jerdenn | with no comments
Filed under:

After all of these years, the Win32 API still does not provide a mechanism for updating a System or User Environment Variable.

One more complaint about Windows Installer DLL Custom Actions.  If an entry point is not found, then Windows Installer generates a generic error, 1723.  This is pretty much the same error for any problem running the DLL.  As it's pretty simple for the Windows Installer team to know if the dll entry point wasn't found, why couldn't they generate a more explicit error message, or even log more detailed information in the MSI log?

It's quite obvious that Windows Installer was designed for internal product team by Microsoft, and then later released for general use.  Who actually makes their HANDLE a typedef for an unsigned long?  Windows Installer's MSIHANDLE, that's who.


This is more of a Windows Installer complaint, but since WiX and Windows Installer are so closely linked, I feel justified making these comments.

The mechanism that Windows Installer uses to call custom actions is convoluted, at best.  A DLL embedded into an MSI is extracted at runtime to the %TEMP% directory, and dyamically renamed to a named format, "MSI???.tmp", where the string '???' is psuedo-randomly generated (There may be a pattern, but I haven't spent the time to figure it out.)

Why do I care?  Well, I attempted to write an embedded DLL that used Managed Code.  Specifically, I used C++ for the Windows Installer entry points, and then generated a c# module.  This worked perfectly for my nUnit test suite, but my instalation kept failing when I tried this from Windows Installer.  After quite some time debugging, I finally examined the fusion assembly binding logs. I discovered that even though the module is embedded in the same PE file as the original calling assembly, the .NET framework first looks for a '.module' file external to the existing assembly.  If it fails to find that '.module', it then examines itself to find the referenced .net module.  However, a small 'feature' is that it does this by looking for it's own original assembly name. The problem I experienced is that Windows Installer has renamed my assembly to the MSI???.tmp name, so I would get assembly/module load issues.

So, that went down the drain. As I am relatively C++ averse (especially Managed C++, though C++/CLI is supposed to rescue me from the ugliness that is MC++), I really preferred to write my CAs in C#.

My solution was to write an external assembly that I install into the GAC.  Now, my c++ "interop" layer can always find the C# custom actions, as they are globally installed.  That does leave me with a chicken and egg problem, though.  How do I get my c# custom actions into the GAC before I call them?  After all, I must have them available during my UI sequence, and I can't wait until intallation time for my CA's to be present.

I followed the same solution that InstallShield uses for there "InstallSheild Engine", idriver.exe.  I wrote a mini-install to place my c# assembly into the GAC, and perform this installation at the beginning of my 'main' installer.

This is a lot of effort to get around the fact that the Windows Installer team hasn't really considered managed custom actions, although the user groups are teaming with such requests. Even though all future versions of the operating system will guarantee a managed framework, the WI team still insists on C++ as the custom code 'story' for windows installations.  (Please don't tell me that Windows Installer supports vbscript.  We all know this.  We also should know that vbscript is very, very bad in installation situations).

So, a long story short - managed CAs are possible, but not easy.  I'll post more on my Managed CA adventure soon.

Posted Tuesday, June 21, 2005 6:41 PM by jerdenn | with no comments
Filed under:

Despite the lack of blog posts, I've really been immersed in WiX.  I'm learning to love and hate this project.  I really love the XML declarative style of creating MSIs.  I really hate the fact that WiX wraps the abomination known as Windows installer. 

I was very familiar with Windows Installer before this adventure. I've spent years working with both InstallShield and Wise, and have had to edit raw MSI tables many times in the past.  However, these commercial products do a much better job of hiding the complexities of Windows Installer than WiX does.  If you decide to adopt WiX, make certain that you have the time to invest in learning the ins and outs of the MSI SDK.  Even if you think that you know quite a bit in this area, be prepared to spend some time spelunking through MSI.chm.

Writing Custom Actions using WiX isn't a walk in the park, either.  I'll talk a bit about managed CAs a bit in the future.  Hopefully people will learn from my trials and tribulations in this area.

Just to make sure that this blog entry has some substance, I'm going to give my WiX UI tip of the day:

To define the default font, place the following in the <UI/> section:

  <Property Id="DefaultUIFont">Tahoma8</Property>
  <TextStyle Id="Tahoma8" FaceName="Tahoma" Size="8" />  
  <!-- rest of UI (dialogs, etc) go here. -->


More Posts « Previous page - Next page »