Until now, taking advantage of the UI improvements in Windows 7 (and even some features in Vista) took a fair bit of work – there was a lot of stuff that wasn’t available through the .NET Framework. You’d have to either switch to C++ or resort to hacks in order to access these goodies.

That’s all changed with the newly-released Windows API Code Pack for Microsoft .NET Framework. Written in C# – with some DirectX stuff written in C++ – this library acts as a wrapper that gives managed code access to features including:

• Windows 7 Taskbar Jump Lists, Icon Overlay, Progress Bar, Tabbed Thumbnails, and Thumbnail Toolbars.
• Windows 7 Libraries, Known Folders, non-file system containers.
• Windows Shell Search API support, a hierarchy of Shell Namespace entities, and Drag and Drop functionality for Shell Objects.
• Explorer Browser Control.
• Shell property system.
• Windows Vista and Windows 7 Common File Dialogs, including custom controls.
• Windows Vista and Windows 7 Task Dialogs.
• Direct3D 11.0, Direct3D 10.1/10.0, DXGI 1.0/1.1, Direct2D 1.0, DirectWrite, Windows Imaging Component (WIC) APIs. (DirectWrite and WIC have partial support)
• Sensor Platform APIs
• Extended Linguistic Services APIs
• Power Management APIs
• Application Restart and Recovery APIs
• Network List Manager APIs
• Command Link control and System defined Shell icons
• Shell search API support
• Drag and drop functionality for Shell objects
• Support for Direct2D/Direct3D interoperability
• Support for typography and font enumeration DirectWrite APIs

The system requirements are:

• .NET Framework 3.5 SP1 or later
• Windows 7 RTM (although many features will work on prior versions)
• DirectX features require Windows SDK for Windows 7 RTM
• Some Direct3D samples require the March 2009 release of the DirectX SDK

We’ll cover the Windows API Code Pack for Microsoft .NET Framework over the next little while in a couple of places – certainly on this blog, as well as at the TechDays 2009 cross-Canada conference in the Optimizing Your Apps for the Windows 7 Experience session.

Download Windows API Code Pack for Microsoft .NET Framework (v1.0)

This article also appears in Canadian Developer Connection.

No tech workshop is complete without a little goofing around on an accordion, and I certainly didn’t want the MeshU day of workshops (which preceded the Mesh Conference) to be incomplete. I did a quick interview with Anita Kuno in which I performed a classic computer programmer song parody and promoted The Empire, which you can see in the video below:

Round Trip

Back when I was working for OpenCola (from January 2000 through January 2002), the start-up cofounded by Cory Doctorow, I was doing a lot of work using beta versions of C# to build prototype peer-to-peer applications that got demoed to some large companies, including Microsoft, who were kind enough to provide us with betas of Visual Studio .NET and Windows XP.

I graduated to the 1.0 version when it came out. Even during the year after I left OpenCola (or more accurately, got the boot), I continued to write applications in C#, from things like a sales app for people who were selling practice certification tests to a trivia game for a company that was pitching it to Maxim. I do manage to land some interesting jobs from time to time.

That changed on Bastille Day 2003, my first day as Tucows’ Technical Evangelist, or as the title originally read, “Technical Community Development Coordinator”. Tucows’ client base were people who wanted to resell things like domain names and email, and as such were largely hosting companies. This in turn meant that they were using languages that you might consider “webbier”: open source dynamically-typed languages like Perl, PHP, Python and Ruby. I did what I could to stay away from Perl, I’d coded in PHP and Python for work before, and I picked up Ruby along the way.

Feeling a bit restless, I left Tucows in late 2007 to do Ruby on Rails development at what turned out to be Toronto’s worst-run startup, possibly ever. After that, it was project management at b5media, where I used Ruby to implement some “housekeeping” scripts. Although I hit up Microsoft Evangelist David Crow for a copy of Visual Studio so I could try out XNA, I really didn’t pay too much attention to C#. I installed it on my machine, wrote a lazy “Hello, World” app – a single WinForm with a button that displayed a MessageBox with the word “poop” when you clicked it – and promptly forgot about it.

The situation changed when I got laid off in September and then got hired as a Developer Evangelist for “The Empire” in October. Suddenly, I’m back in a world with a three-versions-later Visual Studio and a two-and-a-bit-versions-later of C# and .NET. I’ve got the programming know-how and the language basics down cold; it’s the changes in the language and library – generics, LINQ and a bunch of 2- and 3-letter acronyms beginning with “W” – that keep catching me by surprise.

Luckily, management is cool with my first year being a “learning journey”. They’re really interested in how I mix my schmoozing and community-building skills with a love of technology and programming and don’t mind that my first year is a “learning journey”. They especially don’t mind if I share what I learn along the way, which is what this series of articles, Sith Lord in Training, is all about. As I learn more about C# and the .NET framework, both present versions and the upcoming 4.0 versions, I’ll write about them here.

Default Parameters in C# 4.0

Suppose that you’ve got a method that takes a single boolean argument. Here’s how the argument affects what the method does":

• If the argument is anything other than true or if no argument is provided, the method performs its normal task.
• If the argument is true, the method performs its task, plus some additional stuff.

Here’s the Ruby implementation:

# Ruby

def myMethod(doSomethingOptional = false)
    puts "Doing my regular thing."
    if doSomethingOptional
        puts "Doing the optional thing."
    end
end

doSomethingOptional is a parameter with a default value. If myMethod is called without any parameters, doSomethingOptional is given the default value of false.

Unfortunately, the current 3.0 version of C# doesn’t support parameter defaults. The way to emulate this behaviour is to use method overloading:

• One method to handle cases where no parameter is given
• Another method to handle cases where a parameter is given

Here’s the implementation in C# 3.0:

// C# 3.0

public void MyMethod()
{
    MyMethod(false);
}

public void MyMethod(bool doSomethingOptional)
{
   Console.WriteLine("Doing my regular thing.");
   if (doSomethingOptional)
   {
       Console.WriteLine("Doing the optional thing.");
   }
}

That’s a bit long-winded for something that should be pretty simple. Luckily, this has been fixed in C# 4.0:

// C# 4.0

public void MyMethod(bool doSomethingOptional = false)
{
   Console.WriteLine("Doing my regular thing.");
   if (doSomethingOptional)
   {
       Console.WriteLine("Doing the optional thing.");
   }
}

And with that, the long-winded (and unnecessary, at least to my mind) method overloading workaround vanishes. Yay!

Named Parameters in C# 4.0

Named parameters make the meaning of the parameters explicit, as long as the parameter names themselves are pretty meaningful. Contrast the following call:

drawCircle(100, 200, 200, "yellow")

with this, which is supported in Python:

drawCircle(radius = 100, x = 200, y = 200, color = "yellow")

C# 3.0 doesn’t support named parameters, but C# 4.0 does. Here’s how you’d call MyMethod in C# 4.0 using them:

myMethod(doSomethingOptional: true)

As for the Python drawCircle method in the example above. here’s how you’d call it in C# 4.0:

DrawCircle(radius: 100, x: 200, y: 200, color: "yellow")

If this syntax is giving you some deja vu, it might be because it’s reminding you of Objective-C, where the call would look something like this:

[someObject drawCircleWithRadius:100 x:200 y:200 color:"yellow"]

See the Video

If you’d like to see more about default and named parameters in C# 4.0, there’s a video on the Chanel 9 site that covers them quite extensively. Go check it out!

While following the exercises in the book Teach Yourself ASP.NET Ajax in 24 Hours – one of the few books I’ve been able to find on Ajax for ASP.NET 3.5 – I found an error in the “Hour 9” chapter in the example that covers client-side error-handling (it starts on page 137). I’ve reported this error to the publisher and with any luck, they’ll post a corrected version on their support web page for the book.

I’ve done some searching and haven’t found anything covering this error so I thought I’d cover it here. Better still, I’ll also cover the fix, which turns out to be quite simple. If you’ve been trying out the code in the book and wondering why it doesn’t work, relax: at least in this case, it’s not your fault.

In the course of covering the error and how to fix it, I’ll also talk about how ASP.NET handles exceptions raised by asynchronous postbacks and how you can make use of it to make better user interfaces. Even if you don’t have a copy of Teach Yourself ASP.NET Ajax in 24 Hours, you should find this article an interesting introduction to client-side error handling in ASP.NET Ajax.

Unhandled Exceptions and Asynchronous Postbacks

In ASP.NET Ajax, if an exception is raised during an asynchronous postback and isn’t handled on the server side – that is, in the code-behind – it gets passed along to the client side. What happens on the client side depends on which version of ASP.NET you’re using:

• In ASP.NET Ajax 1.0, the server-side exception object is serialized into JSON. The JSON is sent to the client, which displays the exception’s message property in an alert box.
• In ASP.NET Ajax for .NET 3.5, the server-side exception is still serialized into JSON and the JSON is still sent to the client. However, instead of displaying the exception’s message property in an alert box – a presumptuous design decision, if you want my opinion – the client throws the exception, which gives you the opportunity to handle it on the client side as you please.

(In this article, I’ll stick to covering ASP.NET Ajax for .NET 3.5.)

This is quite different from most other web application frameworks, where an exception raised as the result of an XMLHttpRequest call to the server results in some kind of “error” page from the server (or a blank page, if you’re suppressing error reporting).

To illustrate this, let’s put together a simple ASP.NET Ajax application. It’s a single page with a single button, that if clicked, throws an exception.

Here’s the code for the page layout. It’s pretty straightforward:

Listing 1: Default.aspx – Layout for the page of our simple ASP.NET Ajax application.

<%@ Page Language="C#" AutoEventWireup="true"
CodeBehind="Default.aspx.cs" Inherits="WebApplication1._Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Error Handling Demo 1</title>
</head>

<body>
    <form id="form1" runat="server">

        <div>
            <asp:ScriptManager ID="ScriptManager1" runat="server" />
            <asp:UpdatePanel runat="server" ID="UpdatePanel1">
                <ContentTemplate>
                    <asp:Button runat="server" ID="Button1"
                    Text="Click Me" OnClick="Button1_OnClick" />
                </ContentTemplate>
            </asp:UpdatePanel>
        </div>

    </form>
</body>

</html>

Some notes about the code:

• The ScriptManager control at the top of the form enables Ajax by ensuring that the JavaScript needed to support ASP.NET Ajax on the client side is downloaded to the browser.
• The UpdatePanel control determines the controls that trigger asynchronous postbacks and defines the region of the page that can be updated via Ajax.
• Button1 is the button control that we want to throw an exception when clicked. We’ll set it to call the Button1_OnClick method, which will contain the exception-throwing code.

The code-behind is very simple. In it, we define a single method: the event handler Button1_OnClick, which is called in response when the user clicks Button1. All we want it to do is throw an exception that uniquely identifies itself:

Listing 2: Default.aspx.cs – Code-behind for the page of our very simple example app.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace WebApplication1
{
    public partial class _Default : System.Web.UI.Page
    {
        protected void Button1_OnClick(object sender, EventArgs e)
        {
            throw new Exception("Click!");
        }
    }
}

Running with Debugging vs. Running Without Debugging

Listing 1 and 2 give us enough to make our simple app work. It’s time to take it for a spin.

Here’s something that doesn’t get covered in Teach Yourself ASP.NET Ajax in 24 Hours: what happens when you try to run this app with debugging (starting it by hitting F5 in Visual Studio or “Start Debugging” under the “Debug” menu)?

Here’s a screenshot of what happened for me:

With debugging on, the unhandled exception thrown in Button1_OnClick is caught by the debugger. Normally, this sort of error-catching behaviour is welcome, but in this particular case, it gets in the way of what we’re trying to achieve: having an exception on the server side and passing it along to the user’s browser to handle.

If we run the same app without debugging, we get the effect we want: the exception is raised on the server side, but the server-side part of the application doesn’t halt with an error message. Instead, the client shows the error message.

Here’s a screenshot. Note that the error message includes the string “Click!”, which is the argument in the throw statement the Button1_OnClick event handler. Thanks to this, we can be pretty certain that the error message is the result of our deliberately-thrown exception:

Now that we have the exception that we threw on the server side being handled on the client side, let’s do something with it. 

Handling Exceptions Passed from the Server on the Client Side

Let’s do something simple – let’s catch the exception caused by the button click, and instead of having a JavaScript error box pop up, let’s make a couple of changes to the button:

• Change its text to “This button has been disabled for your safety.”
• Disable it.

To handle exceptions on the client side, we need to write some client-side JavaScript. Luckily, this is made simple by the number of handy utility classes defined in the scripts downloaded to the client by the ScriptManager component. In this case, we’re going to make use of the Sys.Webforms.PageRequestManager class to deal with the exception because it provides us with the following:

• The endRequest event, which is raised after an asynchronous postback has completed and control is returned to the browser.
• The add_endRequest method, which specifies a method to call when the endRequest event is raised.

Here’s the JavaScript, which we’ll put in a file called ErrorHandler.js:

Listing 3: ErrorHandler.js — Client-side error handler for our very simple example app.

Sys.WebForms.PageRequestManager.getInstance().add_endRequest(EndRequestHandler);

function EndRequestHandler(sender, args)
{
    if (args.get_error() != undefined) {
        $get('Button1').value = "This button has been disabled for your safety.";
        $get('Button1').disabled = true;
        args.set_errorHandled(true);
    }
}

The script performs the following:

• It registers the method EndRequestHandler as the method to call whenever the endRequest event is raised.
• It defined the method EndRequestHandler, which does the following:
  • If an exception did occur during the asynchronous callback:"
    • The button’s text is changed
    • The button is disabled
    • The error is reported as handled, which allows the application to continue

Now that we have this client-side code, we need to get it to the client. We do this by using the Scripts section of the ScriptManager to send this file to the client. The listing below shows the updated layout code for our simple application. I’ve highlighted the change in the listing below:

Listing 4: Revised Default.aspx – Layout for the page of our simple ASP.NET Ajax application.

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="WebApplication1._Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Error Handling Demo 1</title>
</head>

<body>
    <form id="form1" runat="server">

        <div>
            <asp:ScriptManager ID="ScriptManager1" runat="server">
                <Scripts>
                    <asp:ScriptReference Path="~/ErrorHandler.js" />
                </Scripts>
            </asp:ScriptManager>
            <asp:UpdatePanel runat="server" ID="UpdatePanel1">
                <ContentTemplate>
                    <asp:Button runat="server" ID="Button1"
                    Text="Click Me" OnClick="Button1_OnClick" />
                </ContentTemplate>
            </asp:UpdatePanel>
        </div>

    </form>
</body>

</html>

The Scripts section of the ScriptManager lets us specify scripts to be sent to the client along with the page, with each script specified in a ScriptReference tag.

When we run the app (remember, without debugging on) with these changes and click the button, here’s what we get:

In a later article, I’ll look at other ways of using client-side error handling in ASP.NET Ajax in .NET 3.5.

The Error in Teach Yourself ASP.NET Ajax in 24 Hours

Here’s the page layout code for the error-handling example in Teach Yourself ASP.NET Ajax in 24 Hours. The code-behind for the page and the client-side JavaScript are fine, it’s this code that has the error. See if you can spot what’s amiss:

Listing 5: Default.aspx — Page layout of client-side error-handling example in Hour 9 of Teach Yourself ASP.NET Ajax in 24 Hours.

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="WebApplication1._Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title></title>
</head>

<body>
    <form id="form1" runat="server">

        <div>
            <asp:ScriptManager ID="ScriptManager1" runat="server" />
            <asp:UpdatePanel runat="server" ID="UpdatePanel1">
                <ContentTemplate>
                    <asp:Button runat="server" ID="Button1"
                    Text="Click Me" OnClick="Button1_OnClick" />
                </ContentTemplate>
            </asp:UpdatePanel>
        </div>

        <br /><br />

        <div id="Message" style="visibility: hidden;">
            <asp:HyperLink ID="HyperLink1" runat="server"
                           Font-Bold="true"
                           Text="Error Occurred..."
                           Font-Italic="true"
                           ForeColor="red" >
            </asp:HyperLink>
        </div>

    </form>
</body>

</html>

Just for kicks, here’s what happens when you click on the button in the app using the code straight from Teach Yourself ASP.NET Ajax in 24 Hours:

The mistake is simple: although there is some error-handling client-side JavaScript in the app, it’s not referenced in the ScriptManager tag, which means it’s not sent to the client. Without error-handling code on the client side, the exception is thrown, there’s nothing to catch it and the user is presented with the standard error dialog box.

The fix is equally simple: reference the script in the ScriptManager tag’s Scripts section:

<asp:ScriptManager ID="ScriptManager1" runat="server">
    <Scripts>
        <asp:ScriptReference Path="~/ErrorHandlingScript.js" />
    </Scripts>
</asp:ScriptManager>

Once that’s done, the program works as promised.

As a new Microsoftie and programmer returning to C# after a six-year absence, I have a lot of learning and re-learning ahead of me. In preparation for this, I spent the better part of an afternoon in the “Computers” section of my neighbourhood bookstore going through the C# programming books, sorting the gems from the junk. I took the “beginner’s mind” approach and looked at all the books on the shelves, regardless of the skill level they were written for, even the books that devoted whole chapters to basic concepts like looping and branching. At the very least, it would give me an idea of the current state of programming literature was like in the .NET world.

A couple of weeks later, I stumbled across the C# “Yellow Book”. It’s the standard book for first year computer science students at the University of Hull (I know of it thanks to a Black Adder episode) and written by Rob Miles, a Microsoft MVP and lecturer at that university. Each computer science student there is given a free-as-in-beer printed copy of the book, and now anyone can get a free-as-in-beer PDF copy online.

The C# Yellow Book is quite good, and can easily hold its own against some of the commercial C# books I’ve seen, which typically sell for about $35. It’s written in a clear and breezy style, explains it concepts well, has examples that actually work (I tried some out just for kicks) and often goes beyond typical beginners’ books with many asides called “Programmers’ Points” that explain good programming technique. Its 185 pages cover most of the basic C# language — and most of the example code is run in console mode except for the section near the end that covers basic Windows Forms. After finishing this book, you should have enough background material to tackle an intermediate book on C# or introductory books on .NET topics like GUI programming, ASP.NET or even game development for the PC, Xbox 360 and Zune (yeah, really, the Zune) with XNA.

I’d say that Rob has a strong incentive to make the book as good as possible because it’s the basis of a course at his university and because he can get some rather immediate feedback from its readership. If only that was true for a professor of mine back at Crazy Go Nuts University, whose Pascal programming book (it was the eighties) had terrible examples, an incomprehensible presentation and writing style and annual revisions to foil used-book sales and to force each new class to buy the latest edition. Kudos to Rob and the computer science department at Hull for giving away the course textbook for free!

If you’re a starving student looking to learn Windows programming, I’d recommend getting your hands on a copy of Rob Miles’ free-as-in-beer C# “Yellow Book” and pair it with Microsoft’s free-as-in-beer Visual C# 2008 Express Edition. Alas, I can’t point you to any free-as-in-beer computers.

Links

• Rob Miles’ C# “Yellow Book”
• Visual C# 2008 Express Edition
• WindowsClient.NET: The official site for GUI development in Windows, covering both Windows Forms and the new GUI framework, WPF.
• ASP.NET: The official site for ASP.NET, Microsoft’s framework for web application development.
• XNA Developer Center: The official site for XNA, Microsoft’s game development framework.
• XNA Creators Club: The online community for XNA game developers.

Here’s a fun little claymation video showing called Pointer Fun with Binky that explains C++ pointers “to kids”. Why can’t all programming be taught this way?

My favourite phrase of the moment, thanks to this video, is “Magic Wand of Dereferencing”.

[Found via Being Cellfish.]

Interview with Chris Slemp, MSDN

Here’s another video interview featuring Yours Truly at the PDC: it’s with Chris Slemp, Program Manager for the Server and Tools Online group at Microsoft. In the interview, we talk about MSDN and its new social bookmarking feature.

Click here to watch the video.

“Grim Fandango’s” Puzzle Document

If you’re looking to get into the mind of a game designer and the design of one of the most highly-regarded computer adventures games, be sure to check out the Grim Fandango Puzzle Document. Tim Schafer, in “a temporary fit of Cake-induced Grim nostalgia,” decided to put the game’s puzzle design document online in PDF form (it’s 2.3MB in size).

Here’s a great summary of the Grim Fandango Puzzle Document, written by Andy Geers:

I use that word "crafted" because that’s exactly what this newly released document shows: true craftsmanship. We see the incredible attention to detail, the pacing of the narrative as it builds and as the puzzles get increasingly sophisticated, always coaxing the player along with them. As somebody whose spent the last few years trying to write my own adventure game, what struck me most about this document is the sheer simplicity of it – it’s well established that it takes a great deal of clarity and hard work to boil down something so vast as Grim Fandango into such a simple representation that conveys so much information in such a succinct way.

It’s a considerably more interesting read than most specs.

My Job-Related Reading List

Nothing gives you that frozen-caveman-thawed-in-modern-times feeling like returning to a software platform after not developing in it in seven years. Getting back into the swing of Microsoft’s development tools has been fun so far, but it is, as a lot of people have told me, like drinking from the firehose.

To quickly get acclimated with C#, ASP.NET and XNA, I’m expensing the following books I bought today:

• Pro C# 2008 and the .NET 3.5 Platform by Andrew Troelsen
• Professional ASP.NET 3.5 in C# and VB by Bill Evjen, Scott Hanselman and Devin Rader
• Beginning XNA 2.0 Game Programming by Alexandre Santos Lobao, Bruno Pereira Evangelista, and Jose Antonio Leal de Farias

I’ll let you know what I think of these books as I read them.

“Zero Punctuation” Reviews

And finally, a couple of reviews from my all-time favourite game reviewer, Ben “Yahtzee” Croshaw. The first one’s for Saints Row 2, which includes a great argument for why it might actually be a better game than Grand Theft Auto IV as well as a brilliant concept for a new game:

and here’s the latest review, for Dead Space, which he summarizes as “competent but bland”. Luckily, his review is anything but…

The July 25, 1994 issue of Time magazine.

The computer science student phase of my academic career (the less said about the previous phase, in which I was an electrical engineering student, the better) ran from 1991 to a successful conclusion in 1994.

If you are like me, you strongly connect memories with the music of the time; you could say that my computer science student phase ran from the time of Nirvana’s Nevermind and Soundgarden’s Badmotorfinger to Green Day’s Dookie and The Offspring’s Smash. Let’s just say that I often showed up to my classes and labs in a flannel shirt.

(If that last paragraph makes you think “Whoa, that was a long time ago!”, you’ll be blown away by the fact that the initial work on C ran from the time of the Beatles’ Abbey Road to Led Zeppelin’s Houses of the Holy. A fair number of you probably weren’t even born then.)

My Student Language of Choice

I don’t know what the situation was like at other schools, but at the time, computer science students at Crazy Go Nuts University were allowed to hand in programming assignments using the following languages:

• Pascal
• Turing
• C

(Remember, there was no Java back then. The Green Project, from which the language/platform sprang, was still ongoing at this time, and Java was still going by its “Oak” codename.)

The general recommendation that came from most of my professors was to use Turing. They told us that it was a kinder, gentler language than Pascal and even more so than C, which they implied was designed by dyslexic aliens. When some of us suggested that it might be better to use a language that saw actual use in the real world, many of them countered with the argument that learning principles of computing was more important than learning specific languages. We might’ve responded by pointing out that one of our professors was a co-creator of Turing and probably got a vig for every Turing installation (it was a commercial language), but that might have been an academic career-limiting move.

I ignored their recommendations and went with C. In the lab, I used good ol’ cc. At home, it was Turbo C at first, and later, when I got my first Mac (a Quadra 660AV bought with money from DJing), Think C.

I never used C in my professional career. My first job out of school took me away from a world where input and output was all printf() and scanf() to interactive CD-ROMs and Macromedia Director (now Adobe Director and 7 versions later), and after that, the languages remained pretty high level: Visual Basic, Python, Java, C#, NSBasic, PHP and Ruby, with only a slight detour through through Visual C++ and C++Builder.

My C Books Back Then

It’s almost impossible to talk about C without mentioning “K&R”, the nickname for what is considered to be the official bible of C, The C Programming Language, which was written by Brian Kernighan and Dennis Ritchie. The latest edition of the book — the second edition — is a bit long in the tooth as it was written in 1988, but for the most part, everything in this book should still apply to the current C99 standard.

I never owned a copy of the book in my student days. I signed it out when necessary from the electrical engineering/computer science library in Walter Light Hall. I did own a copy for a brief period in 2002 when my deadbeat ex-housemate left a lot of his stuff behind, but I sold it (along with most of his stuff) in order to recoup some of the money lost from his stiffing me on rent, utilities, groceries and the largest domestic phone bill I’ve ever grappled with.

The books I had while at Crazy Go Nuts University were the second edition of A Book on C and Understanding C Pointers (a book that seems to be no longer in print). I liked A Book on C enough to pick up the fourth edition on sale a couple of years ago, and someone out there has forgotten to give me back my copy of Understanding C Pointers (you know who you are!).

Back to C

I’ve decided to get back into C for a number of reasons.

I have to admit that one of those reasons is completely irrational: it’s ego. There’s certain geek cred that comes with having at least some proficiency in C. While I had those bragging rights back in school, I can’t honestly claim them now; I haven’t even written a file whose name ends in .c in over a decade. Luckily, I had a pretty good grasp of C back in school, and the noodling I’ve been doing with good old gcc suggests that I’ve still got it, which is pretty reassuring.

I’ve also been meaning to do some development with things that are programmed in C or C dialects:

• The Arduino electronics prototyping platform has its own programming language based on C. I’ve been meaning to try out hardware hacking with the folks at the local group HacklabTO.
• I’ve also been thinking about putting together some Mac OS X and iPhone apps, which require Objective-C.
• I’ve even been thinking about doing some GTK noodling, which is done in good ol’ C.

Finally, there’s the matter of just making myself a better programmer by working in C by refreshing my knowledge of the low-level stuff that C requires you to work with, and also the “brain stretch” that comes with working with a language and environment (what with going back to strong typing, compiling and make) that I haven’t worked in for some time.

I’ll be doing some C coding in my spare time, as well as noodling with the Arduino programming languane and Objective-C, and I’ll be posting my notes, observations and experiences here. As I’m fond of saying on this blog, watch this space!

Better late than never: C# 3.0 will feature map, reduce and filter, and Dare “Carnage4Life” Obasanjo explains how to rock these features. He concludes the article with “If your programming language doesn’t support lambda functions or have map/reduce/filter functions built in, you just might be a Blub Programmer who is missing out on being more productive because your programming language doesn’t support ‘esoteric’ or ‘weird’ features,” which sounds kind of weird in an article about C#, a language that could only be Blubbier if its name were BlubLang or Blub#. I suspect I’ve woken up in some upside-down parallel universe again!

Here’s a handy guide to reading C declarations, where things can get very confusing very quickly. Quick — what’s being declared in the line “int (*(*vtable)[])();” ?