SuperPower Security Rights: Be a Superhero

It’s an attractive proposition being a superhero. You get superpowers: you can fly, you can see through walls, you can hear conversations from a mile away. But, of course, it’s no bed of roses either: there are villains bearing Kryptonite round the next corner; or there are bucketloads of personal angst because you can’t be a normal person; or it’s really hard to give someone a high five without smashing them through the nearest wall.

As a group, we software developers tend to be superheroes. No, I don’t mean that we write code that can make mere mortals gasp in admiration (although that is undoubtedly true), but instead I mean that we all tend to run with local admin rights. We can do anything on our machines because we’ve given ourselves the (super)powers and the access rights to do so.

Is this a good situation to be in? Well, I’ll certainly agree it means that, in developing our software, we’re not constantly bumping into roadblocks where we don’t have sufficient rights. We can install whatever software we need and remove it at a moment’s whim. We can write files pretty much anywhere in the file system. We can open up any old port with impunity.

Unfortunately, this relish in having and using our superpowers extends into the software we write. Our applications tend to require superpowers before they will run properly. If someone uses our program or system, he or she will have to have local admin rights too. And therein lies the problem.

One of the biggest security risks in any organization or society is the human one. People, no matter how many times you tell them not too, will open dodgy e-mail attachments. They’ll click on malevolent web links and click OK on the resulting "do you really want to install this" dialog. If only they were running with limited rights, we’d have less problems with viruses, trojans, spyware and the like.

But the superhero ethic is prevalent. Installing Windows XP gives the primary non-admin user admin rights anyway, and we tend not to restrict it later. Millions of normal people out there are running with local admin rights: they are superheroes on their own machines. But do they need these rights? Of course not: the majority of people are surfing, balancing their checkbook, using e-mail, or writing letters. Unfortunately, people haven’t been educated about the need for running under restricted rights; Microsoft hasn’t made setting it up easy enough; and too much retail software erroneously requires admin rights. It’s like everyone had lockable internal doors in their houses for extra security, but then just had one key for them all.

So my exhortation to you (and to myself — I’m as guilty as everyone else) is to restrict the local permissions of your normal login. See what happens. Learn how to install software by temporarily running as admin. Find out which software you run as a matter of course assumes you have admin rights. Get frustrated and berate other companies for their lousily secured software.

Also, see how your software works under a restricted environment. Learn where you should really be installing the user’s config files for your application so that they can be modified (hint: it’s not in a subfolder of C:\Program Files). Learn what devices are available to you, where the restricted rights make a difference and why.

It’s only when developers hide their superpowers that they can be normal people and improve security for everyone else.

Whither Delphi? (Pun intended)

I was reading Nick Hodges’ article last week on how to sell Delphi, when it struck me: Nick’s making a big assumption. Should the Delphi that is sold in this manner be the Delphi sold currently? Or, even, should there be a Delphi to sell?

It seems to me that Borland isn’t moving in the right direction with Delphi, no matter how they sell it. Why is Delphi the way it is? In most developers’ minds, Delphi is this holy trinity of the language, the VCL and the IDE. But, apart from tradition, why is the IDE there? Why hasn’t the VCL been updated to use newer interface models, to use other containers than the ubiquitous TList and TStringList?

I chatted a bit about all this with Charlie and Lino, but didn’t put figurative pen to virtual paper. Then I read a couple of blog posts on the Borland Bloggers site and suddenly pen and paper were required. The first blog post from the Borland Bloggers site was Corbin Dunn’s announcement that he was leaving Borland to go work for Apple on the Cocoa Framework. (In case you didn’t know Corbin was a highly visible member of the Delphi IDE team.) The second post was an apology for Delphi 2005 not having remote debugging.

From one of the referenced posts, it seems that they don’t have the resources (time? developers? money?) to add remote debugging to the IDE. It is entirely disingenuous for Chris to say "I’d like to point out that the existing remote debugging features were not simply removed from the product.  Although, it may seem this way to our customers, this is definitely more a case of ‘the feature was not added’ as opposed to ‘the feature was removed’." Quite simply, I find this a lame excuse for not having remote debugging in the Delphi IDE because the debugging kernel happened to be rewritten.

The Old Fashioned Blues

I installed Delphi 2005 last week; I had a small Win32 project to write and I decided to use the latest and greatest rather than my usual Delphi 7. Besides which I live on automated refactoring these days.

Ye. Gods. The VCL is so Twentieth Century:

  • Where are the base interfaces like those in .NET? Not there! The VCL is a hierarchical inheritance-based class library.
  • I needed a stream that understood text. Not there! So I faked it by writing text drivers that understood a stream and then used Reset, Rewrite, writeln, readln. I first wrote a text driver in Turbo Pascal 3 I think.
  • And where’s the automated formatting? Not there! Spoilt, moi? Heh, it’s back to "indent block." It’s funny, I used to have carved-in-stone standards about code formatting. Then I started using VS 2002. Automated formatting is so productive and efficient that I changed my formatting standards to suit VS with nary a bad thought. I don’t even know the keystroke for VS’s indent block command.
  • I needed a hash table. I almost started (yet again) to use one I’d written when I remembered that the Contnrs unit had a hash table, but bizarrely it’s called a bucket list. (No doubt that’s why the rest of the VCL doesn’t use it: no one knows it’s there.)
Throw out the IDE

Now, if Delphi no longer had an IDE, Delphi R&D would be able to concentrate more on improving the language, enhancing the VCL and adding extra functionality to it. But you need an IDE, no?

There is an IDE out there that does remote debugging, as well as normal debugging, syntax highlighting, code completion, project management, compiling, building, supports multiple languages, etc, etc. The next version of this IDE even supports debugging 32-bit apps on a 64-bit processor and other fab tricks. It’s called Visual Studio 2003. Why isn’t Delphi a compiler that can be added to VS?

Certainly, Delphi R&D would have to write VS add-ins to access the editor, produce a CodeDom, interface with the debugger, etc. But they wouldn’t have to write and maintain a code editor, they wouldn’t have to continue improving the debugger, playing catch-up with what’s going to happen in VS 2005 and with 64-bit operating systems.

And therein lies the problem, I think. The catch-up this year is going to be brutal. Not only is Danny going to have to implement things like generics, anonymous methods, iterators in Delphi The Language, .NET subdivision. For a timeline, I seem to remember a promise of "within a couple of months from the release of .NET 2.0". But Allen’s team is going to have to implement legion enhancements to Delphi The IDE.

I looked at a pre-release of VS 2005 Beta 2 this week. Good grief. There’s a lot of new stuff I remember from 15 months ago, but there is a whole lot more. The new debugging facilities are downright impressive.

Concentrate Resources where they are Needed

So, what should Delphi become? IMHO, for it to survive and grow (and pundits are two a penny on this subject) it should become an add-in to VS. Concentrate on language enhancements to make our developer lives easier and remember to port them to Win32. Concentrate on improvements in the VCL. Is the language going to be support "for in", let alone generics, and other new things? If there are missing components in .NET, or the components that are there are less useful than those in the VCL, write a Delphi component package to redress the balance. Sell it to C# developers.

The resources in Delphi R&D are small and finite compared to Microsoft’s Visual Studio group. I’d say concentrate those resources on where Delphi can make a difference, not on playing catch-up.

Let me end by saying that like Nick, I am at some distance from the Powers That Be at Borland and the reasons for their decisions. If you want, take what I say with a grain of salt, and consider me little more than the CodeFez equivalent of some bloke on a crate at Speaker’s Corner in Hyde Park. Nevertheless, I think it is time we all did some serious thinking about Delphi’s future.

.NET on Linux: C# Development with Mono and Glade, Part II

Now that you have a window you need to ensure that it will close properly. This involves making a single call to the Gnome API function named Application.Quit when the window is closed. If you don’t respond to the closing of the window, then the application will not exit properly. In particular, the application will remain in memory, even though the main window is closed. This might seem strange at first. However, if you think about it for one second, it makes sense. The window is being closed, but the act of closing a window is not really the same thing as exiting the application. So we need to respond to the closing of the main window in an application by also quitting or exiting the application itself. This section and the next explain how this process works.

The trick, of course, is knowing when the window is being closed. Fortunately GTK can send you something called a delete_event signal when the window is being closed. If you are Delphi programmer, you are probably used to thinking in terms of events, rather than signals. This is just a matter of terminology. A signal is the same thing as an event. A delete_event is associated only with windows; there is no delete_event sent when controls are destroyed. Instead, controls emit destroy events.

As mentioned above, in GTK terminology, an event is called a signal. Turn to the signals page in the property inspector, click on the Signal ellipses button and hunt for the delete_event. After selecting it, type in the name of its handler. This name, which you can make up, will be the name of the corresponding routine in your source code that will handle this event. In this case, the handler will be called MyWindowDeleteEvent.

After selecting the delete_event from the Signal ellipses button, I have typed in the name of the event handler, which in this case is called MyWindowDeleteEvent.

Let’s take a moment to make sure you understand what is going on here. The control we are working with, which happens to be a window called myWindow, automatically emits an event when it is closed. For instance, if the user selects the X in the upper right hand corner of this window at run time, then the delete_event will be fired. The developer then needs to trap this event and respond to it. One typically traps an event by writing a method that will be called automatically when the event is fired. In this case, we are making a contract, promising that we will create a method called MyWindowDeleteEvent, that will have the right signature, that is, it will accept the parameters that the delete event passes when it is fired. If we fulfill our half of the contract, then the method will be called automatically.

After setting up your event handler in Glade, you should press the Add button. This will add the event to the window.

The event, or signal, has been added to the window by filling out the dialog  and then pressing the Add button.

You can now choose the Save button in the main Glade window to write your project to disk. Give your project an appropriate name, such as GtkStart05. After saving the project, and assuming you use the proposed naming scheme, you will find two files on disk generated by Glade: and GtkStart05.gladed. The first file uses XML syntax to describe the window and signals you created. In the next section of this article you will learn how to automatically parse this file and then automatically create the controls and signals you defined. This entire process can be done with two, short, simple, lines of code. The second generated file, the one that ends in gladed, is a project file. The Glade development environment uses this XML file to manage your project.

Writing Version 0.5 Of Our Program

We have now used Glade to create a main window, and have ensured that it will fire off an event when the window is closed. The next step is to write source code that will create an application, create the main window, display the window, and respond properly when the user closes the main window. In our case, the proper response to closing the main window is to close the application itself.

If we were working in C, C++ or Ada, then Glade could create the source code we need automatically. This is similar, though not identical, to the process in Delphi or Visual Studio, where the code for the application is not only created, but integrated into the same tool set as the visual designer. In particular, you can choose Project | Options from the Glade main window, and select whether you want to generate C, C++ or Ada code. After making your choice, you can press the Build button on the Glade main window to generate the actual source code. Note that the Build button does not compile or link your source, it only generates the files you need to compile your program. If you are creating a C program, you can then go to the command line, run the script called, and the make files for your system will be created automatically. Then type make at the shell prompt and your project will be automatically compiled. I should add that there are tools in other languages, such as Python, Perl and Ruby, that will read a file like and then automatically generate the needed source code to create the windows described in it.

But in this case we are not working in C, C++, Python or Ada, and so we need to write code by hand in a text editor. Fortunately, that process is simple, since the required code is brief and easy to understand. It is shown in Listing 1. The code to compile and link the project is shown in Listing 2. To run the project, type mono gtkstart05.exe. If all has gone well, you should compile cleanly with no errors or warnings. When you run the project, a plain window should appear, as shown in Figure 7. When you close the main window, you should be taken back to your shell prompt. If the window disappears, but you are not taken back to the prompt, then something is wrong with your signal handler. You can, however, still press Ctrl-C or Ctrl-D to end the application and return to the shell prompt.

The simple, empty window that is created after we compile our source to create gtkstart05.exe, and then run that binary file from the command line by typing mono gtkstart05.exe.

Listing 1: The source code for version 0.5 of our simple introductory application.

namespace GtkStart
        using System;
        using Gtk;
        using Gnome;
        using Glade;
        using GtkSharp;
        public class GtkStart05
                public static void Main (string[] args)
                        new GtkStart05(args);
                public GtkStart05(string[] args) 
                        /* Load the Glade xml file */
                        Glade.XML gxml = new Glade.XML ("", "myWindow", null);
                        gxml.Autoconnect (this);
                /* Fulfill the contract we made in Glade to create a signal handler */
                public void MyWindowDeleteEvent (object o, DeleteEventArgs args) 
                        Application.Quit ();
                        args.RetVal = true;

Listing 2: Code to compile the project. Note that a path is temporarily defined pointing to the default location for the gtk-sharp libraries.

export MONO_PATH=/usr/lib/mono/gtk-sharp/
mcs /unsafe -r gtk-sharp.dll -r glade-sharp.dll -r gnome-sharp.dll gtkstart05.cs
export MONO_PATH=

The code shown in Listing 1 has a Main method that creates an instance of the GtkStart05 class, just as you would in any normal C# or Java application. The constructor begins by calling the predefined Application.Init routine from the GTK API. Needless to say, the purpose of this routine is to initialize your GTK based application.

The next line of code loads in the XML file that you created in Glade. Note that we have optionally chosen to pass in the name of a specific object, namely myWindow. The Glade API uses this window name to know which part of the XML file it is going to parse. If you don’t pass in any name, then it parses the whole file.

Note that Application.Init is part of GTK#, while Glade.XML is part of the Glade API, or more particularly, it is part of libglade. It is worth taking a moment to think about libglade. It is possible to create GTK widgets by hand. In other words, you don’t have to parse an XML file in order to create a window or a button when using GTK. Instead, you can create these controls by hand by writing code. Code of this type, that is code not based on XML, is generated when you push the Build button in the Glade main window. What libglade does is provide routines that parse the XML and automatically create the controls you want to access. The great advantage of this system is that it at least partially separates your user interface code, which is defined in XML, from the rest of your source code, which is written in C#. Of course, the separation is not complete, since some of your user interface code, such as event handlers, are in your hand written source code. But this system will allow you to regenerate the interface with Glade without overwriting any of the code in your source.

The libglade API’s and its related programming philosophy are described in depth at this URL:

After creating an instance of type Glade.XML, the next step is to call Autoconnect.

 Glade.XML gxml = new Glade.XML ("", "myWindow", null);
 gxml.Autoconnect (this);

The call to Autoconnect hooks up the signals defined in the XML file to the event handler you have defined in your file. In other words, it focuses on this bit of XML from

<signal name="delete_event" 
 last_modification_time="Thu, 18 Nov 2004 17:42:01 GMT"/>

It then hooks that XML encoded signal up to this signal handler from Listing 1:

public void MyWindowDeleteEvent (object o, DeleteEventArgs args) 
  Application.Quit ();
  args.RetVal = true;

In this code, note the call to Application.Quit. Needless to say, this call closes the application. It ends the application process and takes the user back to the shell prompt, or the GUI desktop. The signal handler is written in order to provide a place to make this call. In other words, the program responds to the delete_event so that it can make this call, and thereby smoothly end the program.

For the purposes of review, let’s take a second look at the constructor:

public GtkStart05(string[] args) 
  Glade.XML gxml = new Glade.XML ("", "myWindow", null);
  gxml.Autoconnect (this);

By this time we have examined all but the last call. As you can see, the sequence of calls in the constructor is completed by calling Application.Run, which is part of the GTK# toolkit. This call hands the control of the program over to the GTK. Your program never fully gets control back again until you call Application.Quit. Instead, your code simply processes signals of various types, such as those that are generated when buttons are pushed or data is entered in various types of controls. Your program continues to respond to events until such time as you call Application.Quit. At that point, your program exits.


That is enough for this article. In the next installment we will begin populating our window with controls, and responding to events generated by those controls.

In this article you learned how to create a simple window using the Glade development environment. You also saw how to create a simple signal, or event, that would fire when the window was closed. After creating the window and the signal, the article described how to save the information about your window to an XML file. The article explained how to load and parse the XML file, and how to connect the signal defined in the XML file to an event handler defined in your code. Finally, you saw how to respond to an event by closing the application itself.

Ten Things I Love about Delphi 2005. Okay, Eleven

Last time I wrote, to the shock of many I am sure, about the things I don’t like about Delphi 2005. Granted, a bunch of them were pet-peevish, but hey, it’s my column, and I can rant about pet-peeves if I want, right?

Well, of course you had to know what this column was going to be about. That’s right! Here it is: The Top Ten Things I Love About Delphi 2005. I had to do it, of course. You expect nothing less of me, I know.

  1. I love the History view. I especially love it when it is integrated with StarTeam. (Have I mentioned how much StarTeam totally rocks, and how you get a client license and the server if you buy Enterprise and above? I haven’t? Well, I just did!) The History tab has already saved my butt at least 100 times, mostly from my own silliness, and sometimes from the quirks of the IDE. It helps me be a bit more daring and brave with some hair-brained coding scheme that I come up with, knowing that I can always revert to an earlier version of my code. I have my history number at 90, the max. What’s your History Number?

  2. I love the integrated unit testing. I’ve only recently been seeing the wisdom and general coolness of unit testing, and the wizards in the IDE made doing it so easy that I started doing lots of unit testing. I started writing my code with the idea of it being tested. Shoot, I even started writing my tests before I wrote my code. And of course, once you get started, you get addicted, and then you are off to the races. Unit testing will help you write better code even if your code never fails a test. Unit testing garners the opposite of the advice I give on COM programming: If you aren’t doing it, start. If you are doing it, do it more.

  3. I love the ASP.NET Deployment Manager. I use this all the time now. I have two or three deployments for each of my ASP.NET applications so I can easily deploy an application from the office, from a hotel room, or lying in bed watching David Letterman. The thing just knows what files need to be deployed, and does it all with the push of a button. Can’t beat that.

  4. I love the DataHub/DataSync/RemoteConnection/RemoteServer components. I didn’t really have much of any idea what these things did. One day I started dropping them on a couple of forms. I hooked a few things up, set a few properties, and the next thing I know, I was serving up data over a .Net Remoting connection. I hadn’t even written any code. It was easier than getting Charlie to talk about open source software. Can’t beat that. Can’t do that in VS.Net.

  5. I love having all those languages in the same IDE. Despite the fact that I really can’t stand C#, I have to admit there is a lot of good code out there written in it. Delphi 2005 allows me to add in a C#-based assembly to a project and work with it, while still doing all my real coding in Delphi. I love the little icon in the toolbar that tells you what the current personality is. One of my favorite demos is to create a Project Group that has a Win32 VCL app, a VCL.NET app, a C# app, an ASP.NET app, and a VB app in it, and then hit Build All. Works a treat. Can’t do that in VS.NET.

  6. I love the for…in syntax. I find myself using this all the time now. All the time. It’s so natural now, I wonder how we ever got along without it.

  7. I love the StarTeam integration. This really rocks. (Have I mentioned how cool StarTeam is, and how wise and smart you’d be to start using it?). You can make a direct connection between a project in the Project Manager and a project in your StarTeam repository. You can easily check in and check out files right in the IDE. The StarTeam client is even integrated inside the IDE. Like I said, it rocks.

  8. Refactoring! I love the refactorings! This is probably at the top of the "How did I get along without this?" list. I love this stuff. I love "Rename Variable" and "Extract Method" the best. I find that I am actually starting to write code that I know will eventually be refactored. I’m making a big ol’ list of new refactorings that I’m going to start pestering Corbin about. This feature is really making my code better. Very, very nice. And unless I’m mistaken — you can’t do that in VS.NET without an expensive add-in.

  9. I like the new Welcome Page. Some people hate the welcome page, but I can’t really understand that. I guess some folks just can’t stand having valuable information at their finger tips. I like having the most recently used files right there, not hiding behind a menu. I like seeing the BDN feeds, as they contain lots of good info.

  10. I love ECO. Okay, I know almost nothing about it. I can’t hardly make it actually do anything just yet. But I sure do know what it is and what it can do, and that it does really cool things like making writing database applications about ten times faster, and a whole lot more fun. (Does anyone actually like writing SQL?) And you most assuredly can’t do that sort of thing in VS.NET. Microsoft will be glad to try to deliver some vaporware to you, but Borland is shipping this stuff today.

  11. I love the new icon. That Trojan helmet thing is cool. I really like it.

Okay, that was eleven. So I can’t control myself. Can you blame me?

.NET on Linux: C# Development with Mono and Glade, Part I

Glade is a GUI development environment for creating applications using the same type of visual development tools as one would use in Delphi, JBuilder, Visual Basic or many of the .NET languages hosted in Visual Studio. You can read about Glade at the following URLs:


Installing Glade

There are at least two versions of Glade available at the time of this writing:

  • The original Glade for Gnome 1.4, distributed as Glade 0.6.4 at the time of this writing.
  • And the fancier Glade 2 for Gnome 2.4 and 2.6, distributed as Glade 2.5 or 2.6 at the time of this writing. In particular, Glade 2.5 comes in this package: glade2-2.5.0-1.i386.rpm.

Be sure to install Glade 2, as the original Glade does not have support for the Gnome interfaces needed to build this kind of application. At the time of this writing, the most current version of Glade is 2.6, which is what I get on Fedora Core 3. But when I was on Fedora Core 2, yum retrieved Glade 2.5, which I was able to use without mishap. As mentioned earlier, I am not currently developing Mono applications on Fedora Core 3 while I wait for the Mono packages to be updated.

You can download Glade as a tarball or as a Debian package from But on Fedora Core 2 and Fedora Core 3 I installed Glade 2 by issuing this command:

yum install glade2

Note: You can read more about yum by reading my introduction to that subject.

Yum had to resolve numerous fairly complex dependencies in order to install the Glade package. It is the resolution of these dependencies that leads me to recommend yum. Trying to resolve all those dependencies by hand can be a frustrating process, and it is nice to just sit back and watch yum pull down seven or eight dependencies and install them all for you automatically.

NOTE: If you are currently running the Gnome desktop, you can discover the version by right clicking on the panel and selecting About. You can subscribe to the user’s list for Glade at

Installing Mono with Yum

The most difficult step in using Mono on Linux is the install. Unless you are a very experienced Linux user, you don’t want to try to take this step by hand. The Mono libraries have a number of complex and very specific dependencies, and trying to resolve them all manually can be a painful experience. Instead, you want to use an automatic install system of one kind or another.

There are two primary ways to install Mono on Linux. For quite some time, the Ximian RedCarpet, which I believe is now called Novell Zenworks, was the preferred method, and it is still a reliable system to use. However, you can also use yum to perform the install. I prefer using yum because it comes with Fedora Core and is supported by the Mono project as specified on their download page.

As described in my article, yum installs applications by first pulling down packages from a repository on the Internet. You need to tell yum where these repositories are located by modifying your yum.conf file. If you are using Fedora Core 2, here are the lines to add to your /etc/yum.conf file:


Then issue this command:

yum install mono-complete

All of the many files needed to support Mono will then be pulled down and correctly installed. Typically, this can save hours or even days of work.

After installing Mono, you want to make sure that GTK# is also installed on your system. GTK# is the API you will use to connect Mono to the code generated by the Glade development environment. Installing GTK# involves working with two packages called gtk-sharp-gapi and gtk-sharp:

yum update gtk-sharp-gapi
yum update gtk-sharp

After you are done, you should be able to type mono or mcs at the command line and get back some sensible output other than “command not found.” You should also find that the “Glade Interface Designer” is part of the Programming node of your menu. If it is not on the menu, try typing glade-2 at the command line to launch Glade from the default /usr/bin directory.

A Glade Primer

Now that you have everything installed, the next step is to bring up Glade and get to work. When you first bring up Glade 2, you see the main window.

Choose Project | New, and select New Gnome project, from the New Project dialog. In particular, selecting Project | New causes the New Project dialog to appear. In that dialog, select New Gnome Project.

In the View menu of the main Glade window, be sure that both View Palette and Show Property Editor are checked.  You can use the palette to create new windows, and then to decorate your windows with various controls such as buttons and labels. You can drop these controls on to a window in order to create a user interface, much as you would in Delphi, or Visual Studio.NET. All of this will be described in depth in this article, and in the next installment of this article.

In the upper left hand corner of the Palette, on the GTK+ Basic page, you can see an icon for creating a new window. Select this icon. The result is a new window. In the upper left hand corner, you can see that the new window is listed as window1 in the main Glade window.
The three main windows of Glade are shown to the southwest (the palette), northwest (the main window) and northeast (the properties window). The window in the southeast is the design surface created when you clicked the icon in the upper left hand corner of the palette.

The editable features of window1 are shown in the properties window, found in the upper right hand corner. You can, for instance, change the name or title of the window you created by editing the fields in the properties window. More generally, the properties window lets you set the properties of the currently selected control. You can see that window1 is selected. The name of the window, as you can see, is window1, and its title is window1. You can use the properties window to set the name of the window to myWindow, and the title to My Window.

The window has changed from window1 to myWindow and the title has changed from window1 to My Window. You can see the new title in the window shown in the southeast of this screen shot.

Open Source and Election Fraud

In Carteret county in North Carolina, an electronic voting machine failed. As a result, 4,500 votes were never tabulated. Since some of the races in North Carolina were tight, it is possible that the lost 4500 votes could have a significant outcome on election results. For instance, the race for agricultural commissioner is still being decided. At this time, the candidates are separated by only a few hundred votes. Could the 4,500 votes lost in Carteret county have decided the race for agricultural commissioner? We will almost certainly never know.

This is a specific example of a general problem. In fact, accusations of e-voting failures were wide spread throughout the November 2004 elections. As a result, there will always be a doubt about the legitimacy of the election in many races throughout the country. As computer programmers, we know it need not be this way.

The failure in the North Carolina election occurred in Carteret County. One explanation of the error runs as follows: Officials were told by the manufacturer of the voting machine that it had the capacity to record 10,000 votes. Unfortunately, the model of voting machine delivered to Carteret County could only tally 3,005 votes. As a result, the last 4,500 votes cast in the county were never counted.

Everyone in the country is concerned about this kind of problem. But as computer programmers, a story of this kind leaves us stunned. What do they mean the machine could only handle 3,005 votes? In this day of 32 bit operating systems, where the standard limit for an Integer value is over 2 billion, exactly how did they manage to create a limit of 3,005 votes? A failure on this magnitude takes real work to achieve! It is something only a proprietary software company, intentionally trying to cripple their software, would be likely to achieve.

This story takes on yet another twist for those of us who are advocates for open source. This is the ultimate tale of proprietary software gone bad. Few people can review the software that is created by the companies that make proprietary voting machines. The whole endeavor is rife with opportunities for fraud, for carelessness, and for ill-planned cost cuts. In short, proprietary companies should not be allowed in the same room as a voting machine, let alone entrusted with the responsibility of building one.

The solution, of course, is open source software. All voting machines ought to run open source software that is freely distributed over the Internet. Computer scientists of all kinds could then download the source, compile it, and test it for errors. It is unlikely to the point of absurdity to claim that publicly reviewed open source software of this importance could ever have been so fatally flawed as the software in Carteret County.

Programmers who designed proprietary software are likely to be hired at the lowest possible price. In short, it is unlikely that top quality engineers would be used to create a product as simple as a vote counter. With open source software of this importance, however, it is almost certain that many of the greatest computer scientist in the world would review the code. The difference in quality between the open source and the proprietary version of e-vote software would, in most cases, be monumental.

The Specifics of How to Solve the Problem

I would now like to go out on a limb and offer a few more suggestions for how to clean up the crisis in our democratic system. I envision open source software that uses something like MD5 checksums, and a paper trail, to ensure a high level of voter security. Certainly the MD5 checksum for the compiled version of the open source code ought to be a well know, and publicly available piece of data. If possible, machines should be designed so that they will run only if the checksums for the software add up.

Secondly, the machines that are used should be off-the-shelf commodities, rather than custom made hardware. This would both guarantee the quality of the hardware, and greatly reduce the possibility of incompetence or fraud in the manufacturing process. For instance, there are various commodity handhelds that could be certified to run the software accurately, and they should be used exclusively during elections. If handhelds are not convenient, then a certain model of off-the-shelf PC should be used.

As each vote is cast, off-the-shelf hardware used for creating credit card receipts could be employed to create duplicate copies of a paper trail. One copy would stay with the voter, the other be kept by the voting commission. On each receipt would be an MD5 checksum, or some similar technology, which would be a unique number that could only be generated by a particular person, at a particular address, at particular date and time, voting in a particular way. It should be impossible to calculate (reverse-engineer) the vote based on the checksum alone, but the uniqueness of this number would be guaranteed by the high quality of the open source software. The software, of course, could be reviewed at any time by any member of the world population who had access to a computer.

Perhaps it could even be possible to post the checksum numbers on a national web site. Then the voter, and the voting commission, could compare the value on the paper trail with the value on the web site. Any discrepancies would be immediately apparent, and the vote could be either thrown out, or recast. This system would only work, however, if one could be sure that the numbers could not be reverse engineered so as to reveal the vote.

In most states, less than 10 million people cast votes. If this checksum could be guaranteed to be unique all but one out of a billion times, then the accuracy would probably be close enough for "government work." In fact, I would hope the best computer scientists could come up with a number that would be absolutely unique, or be unique all but one out of a trillion times. With that degree of accuracy, election results across the country could be considered reliable enough to dismiss e-voting failure as a serious problem.


I have described a specific crisis in our electoral system, and proposed a specific solution. Most portions of the solution proposed here are not unique to me, but emerged from discussions I have had with others, or from reading articles similar to this one. I am sure many of you can think of problems with my proposal, and others may have new ideas that they would like to put forward. If so, please reply to this article and share your views.

The more people who contribute to this kind of discussion, and who can come up with specific ideas about how to improve e-voting, the better. We live in an open society, and the preservation of our right to vote is entrusted not solely to our government, and certainly not to any corporation. Instead, it rests with us, the citizens of this country, and the citizens of democratic countries every where in the world. As computer programmers, we are the ones who can come up with solutions to this crisis, and the open source community should lead the way.

Some links:

  • Single Transferable Vote:
  • The Voting Software Project:
  • Electoral Voting Reform:
  • Cambridge Election Commission:

Delphi 2005, first class!

Last week in Santa Clara, CA I conducted my first class on Delphi 2005. Thanks to the students from Sacramento for making the week so pleasant.

So, you ask, how was the week with Delphi 2005? How did it stand the test of exercising most of its features during the week? Did it crash at any time? Did we find weak areas? Did we find superb areas? Read on to find out.

First Impressions

It was so great to find myself teaching Delphi again. When I tried teaching Delphi 8 shortly after its release, the process was painful and demoralizing. We quickly made the decision not do that anymore so as to eliminate the sense of frustration experienced by the students and their instructor.

But working with Delphi 2005 was a very different experience. In fact, I have to say the week of teaching Delphi 2005 was pleasant! We found a lot of problems together but I could honestly say that the product was usable and productive.  Frustrating at times, but hey, it looks like we are getting a Patch any day now in December 2004.


ECO is a cool product. I like it a lot! It is very powerful! We ran two different exercises during the class:

  1. First we generated the model, code and UI based on the Northwind Database in MS SQL Server 2000. This worked beautifully.
  2. Then we built the whole model from scratch. We generated the code and the UI, and then exercised the Persist to XML option. It also worked beautifully!

My only comment on ECO is that the product is screaming for some wizards: there are way too many steps to remember. If you open the wrong model or file it is easy to get lost, and it can be difficult to get back on track.  I am grateful to Anthony Richardson for writing tutorials that saved the day!

Project Manager

The Project Manager is flaky! During the .NET Remoting chapters, having four projects open under one Project group caused weird problems during compilation. We kept getting errors that one project could not see the assembly of another in the same group. This happened several times.  Closing the Project group completely and reopening it fixed these problems, but it was annoying having to close and reopen the entire Project Group so many times during that exercise.

Import …where?

The students were very interested in Interop because of the amount of ActiveX and Win32 code they have. They knew that their migration would occur slowly over time; that it would be too difficult to do a complete rewrite all at once.  I looked for the menu item “Import Type Library” everywhere, under .NET and under Win32 — no GO! I can’t believe there is no “Import Type Library” in Delphi 2005! It is especially important in Win32, although it is much needed in .NET as well. 

The bigger surprise was not finding “ActiveForm” under the ActiveX tab in Delphi Win32. That was disturbing to the students, especially for those who use ActiveForms a lot.  But I quickly cooled the flames by reminding them that: “COM is like smoking! If you are doing it, you need to stop! And if you are not, then you don’t need to go there!”


The Editor was nice and behaved well during the week. The one exception was CodeSnipets. I would have liked to be able to highlight some code and drag that code to the CodeSnipet window to create a new entry.  It seems that this was intended to be a feature, but it is not working yet in the IDE. Personally, I believe it is a potentially great feature, and it would be very nice to have it working.


The Borland Data Providers appeared to us to be very nice indeed and to work well. We did not stress them out by any means. We did, however, successfully work through several examples that deal with the Connection, DataAdapter and Command Objects.


This feature is MUCH MORE stable than in Delphi 8. I like the Deployment Manager a great deal. It allows the developer to easily synchronize and deploy projects to any directory or FTP site. It even has pieces of the old check-in tool we used to use on the team at Borland to show diffs and visual representation of changes.


The debugger was very stable. I was impressed by the fact that the CPU window, now docked into the editor, can show IL, ASM and Delphi code all at once. This really gives the developer a better understanding of what is happening in their code.  I also found the inplace editing of Breakpoint conditions to be a cleanly executed and highly useful feature.


I am still not convinced that the changes from Delphi 8 to 2005 in the namespace area are sufficient to bring Delphi up to speed as a first class citizen in the world of namespaces.  The language is screaming for a new keyword “Namespace” that will fix the problems once and for all. Danny Thorpe, explained to me during our trip to Toronto that he is considering that approach. He said, however, that it will be a major job to implement that feature in the compiler. Furthermore, he was worried that it would not work well with the FAST one pass compiler we have now. I just don’t like to see all the stuff I see when I open a Delphi written assembly with the reflector.  When viewing an Assembly in C#, I would like to see my namepaces exactly as I declared them.


All in all, both the class and I were pleased with the experience we had while playing and working with Delphi 2005 for the whole week. There were a few rough spots, but the product stood up well to our fairly extensive testing.