Does knowing C make you a better programmer?

Joel and Jeff had a conversation about the merits of knowing how to program in C.  Joel’s take was knowing how to program in C makes you a better program.  I’m in that camp, with some other people (Darren and Eric).

After college, I did mostly C programming.  That was back in the days when 640K wasn’t the punch-line to a joke, but a real limit that drove you nuts.  Having a good working knowledge of C gave you a better understanding how memory was allocated and how it was used.  Pointer arithmetic was part of the natural order of programming.  It made you a careful with what you allocated and how you managed it.

There’s a still a place for unmanaged code, whether it’s C, C++, Delphi, or some other language.  You get a lot functionality with managed code (more ways of accessing data, garbage collection, etc), but there’s no free lunch and there’s a substantial footprint for each process that uses the .NET Framework.  I’m typing this with Windows Live Writer, an app that’s written for the .NET Framework.  It’s using 54MB right now as I type.  That’s a lot of memory for a WYSIWG blog tool.  Just because you have a garbage collector doesn’t mean that it’s being used effectively.  It’s still good to clean up after yourself and a good C/C++ programmer does that.

Eric Sink compared knowing C with knowing Morse code.  It’s a flawed argument in that Morse code is not the underpinnings of the technology that came after it, but it’s close enough to the spirit of the argument to have some merit.  My dad learned Morse code 30+ years ago when he got his ham license.  It was a big deal back then and you couldn’t get your ham license with being able to demonstrate your proficiency with Morse.

Once he got his license, he rarely if ever used Morse to send out a message.  But every now and then, he would pick up a faint signal that had bounced around the ionosphere and it would be in Morse.  He would sit at his radio and pick out the words that of the dashes and dots.  

But how can you use that analogy to demonstrate the value of C to a managed code programmer?  For many programmers, I’m sure it doesn’t mean anything to them.  If you are just doing web programming for some giant LOB app, only knowing VB.NET or C# probably isn’t much a of a liability.

On the other hand, If you do any P/Invoke work, you’ll calling DLLs that were mostly written in C or C++.  Having a knowledge of those languages makes it a little easier to understand the data structures and calling conventions used by the DLL.  If you working with binary data that came from unmanaged code, knowing how that data is represented in it’s native environment will make it easier to understand what it is and how to use it.

Darren Stokes made the assertion that programmers who know C seem to solve complicated problems faster than those who don’t know C.  I don’t know of you can make that case.  With the push to teach only managed code at school, the programmers that came up knowing C are a bit older than the programmers who don’t know C.  That programmer who has the C experience is probably someone who has been around longer and has that much more experience to draw from.  I wonder if anyone has down any actual studies that compare the level of productivity from programmers with C experience compared with programmers that only know only managed code.

Ack! The Windows Installer does not permit installation from a Remote Desktop Connection

I’m testing a installer that I had migrated from Wise For Windows to InstallAware. I testing the installer from inside a virtual machine. I used do it with VMware Workstation, but now I’m using virtual machines hosted on our ESX server. That’s usually much faster and doesn’t my bog down my development machine.

I connected to a virtual Server 2003 session using Terminals. If you spend anymore of time using Remote Desktop, then you’ll want Terminals. It lets you have multiple sessions open in a single instance of the client by displaying each session in a tab. In addition to RDP, it supports VNC, Telnet/SSH, and a few other protocols. And it’s an open source project, you can’t beat the price tag.

With a RDP connection, you have the ability to automagically have the remote connection access your local resources (drives, printers, serial ports, etc). I was using the local access to disks to allow the remote connection to access my hard drive. I figured that would be a quick way to compile the installer on my local machine and run it remotely through the RDP connection.

Or so I thought. As a prerequisite for this app, I need to install the ASP.NET 2.0 AJAX Extensions. That comes as a Windows Installer .msi files. When I ran that .msi, I got the following error message:


In other words: FAIL. To add insult to injury, that’s not even a standard Windows error dialog. With most Windows error dialog boxes, you can press Ctrl-C and the contents of the dialog box will be copied to the clipboard. You’ll get all of the information from the dialog, something like this (from a different installer):

---------------------------
Microsoft .NET Framework 2.0 SP1 Setup
---------------------------
The Windows Installer package:


c:\c6b28b8b6e56383fbc455e9977dd00\vs_setup.msi


could not be opened.



Choose Retry to try again. Choose Cancel for exit setup.
---------------------------
Retry Cancel
---------------------------

That’s very handy for reporting errors or for researching with the text from the dialog. I hate it when I see a bug logged in our internal bug tracking system that has embedded a screen shot of an error message. They screen shot the whole page (hello? Alt-Prtscn anyone), save the image, then attach it as a file attachment. Instead, they have press CTRL-C and then CTRL-V and be done with it. Rant over, back to original rant.

For some reason, the AJAX installer team chose not to follow that convention. So I went to Google and manually typed in the text of the error message (Oh, the huge manatee!) and start viewing the results. Sure enough, it’s in the MS Knowledge base as 927063. Windows Installer does not allow installs in Server 2003 from a RDP connection shared drive. When you allow access to your local C: drive to the remote session, it sees it as \\TSClient\c and flat out disallows installs from anything in the \\TSClient namespace. This was determined to be a security risk and the tssclient blocking was added Windows Installer 2.0 at the time of the Windows Server 2003 release.

This KB article lists two resolutions, use the standard UNC notation to reference that drive or map a drive letter to that location. To that list, I’ll a third option. Copy the file from the \\tsclient share to the remote desktop and run it from there. For one off tasks, that’s usually faster than accessing a UNC named object.

Side note: While writing this post, I read on the Terminals home page on CodePlex that Microsoft will be removing the ability to connect to the console session through the RDP protocol in version 6.1. Being able to connect to the console is a little known feature of the RDP client, mstsc.exe. I use it when people leave their RDP sessions hanging on a 2003 Server box that only has the admin remote connections enabled. I can connect over the console session and blow away the left over sessions. I can query and kill the remote sessions via the command line, but sometimes you just need one session open. If you want to see this feature left in the RDP stack, place your vote here.