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:

  • http://glade.gnome.org/index.html
  • http://www.gotmono.com/docs/gnome/bindings/glade/glade.html

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 http://glade.gnome.org/download.html. 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 http://lists.ximian.com/mailman/listinfo/glade-users..

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: http://stv.sourceforge.net/
  • The Voting Software Project: http://vote.sourceforge.net/
  • Electoral Voting Reform: http://www.electoral-reform.org.uk/
  • Cambridge Election Commission: http://www.ci.cambridge.ma.us/~Election/