Shareware Beach

I’ve always wondered why so many obviously skilled software developers spend a lot of time developing and supporting excellent software packages only to release those as freeware, earning their pay at the day job. There’s a lot of freeware out there that its developers could make a fine living on if they took the plunge into the shareware world.

I guess it’s the same reason why so many people keep doing the day jobs they complain so much about: it’s easier to be fed than to do your own hunting.

It’s no surprise that Borland’s recent announcemet to spin off its development tools’ business sparked a new wave of “Delphi is dead” discussions in various newsgroups and online forums. Personally I think that Delphi’s future hasn’t looked brighter for quite some time.

Certainly, until we know who the buyer(s) will be, there is some uncertainty as to the direction they will take with their aquisition. However, it is certain that the people currently developing Borland’s development tools are very focused on driving their products forward. Though Borland has announced the spin-off as a sale, it looks more like a divorce to me.

For quite a number of years now, Borland has spent a lot of time and money on its “Application Lifecycle Management” business. Basically this is a bunch of software that makes it easier to manage large software development projects. This business is quite different from the developer tools business. ALM solutions are sold by salespeople to enterprise decision makers, while developer tools are usually sold through retail channels and web shops (just like shareware). Attempting to serve two quite different markets seems to have led to a split in the company. Another key point is that Borland’s developer tools are mostly home-grown in Scotts Valley, while most of the ALM products have been acquired by buying up other companies. That results in different corporate cultures in the two business units.

There’s also far less synergy between the two parts of Borland’s business then one might think. Surely, tight integration between development and ALM tools is a good thing. But the issue is that customers want choice, and too much integration could be perceived as vendor lock-in. A company using Rational might decide not to use Delphi because Delphi will only work (well) with Borland’s ALM products. Another company using Eclipse might think that Borland’s ALM products only work (well) with JBuilder. Such arguments would be difficult to disprove by salespeople, because any product will always integrate better with other products form the same company than with competing products. By splitting up the businesses, Borland is free to integrate its ALM products as well as it can with whichever development tools are popular, while the development tool business can connect its tools to any ALM solution.

My opinion is that the people creating Delphi, JBuilder, etc. want to leave Borland just as much as Borland’s management wants to sell off the development tools to focus on the sexier ALM business. Though we will never know the full story, I think it’s great that Borland is being open about its plans to sell. Though it may fuel some panicky discussions, it’s better than Borland having to deny rumors and then have to admit that the rumors were true after all when the deal is announced, as often happens.

When there’s talk about Delphi’s future, there are always people saying they’re switching to Microsoft development tools. I fail to see the wisdom in that. Sure, Microsoft’s development tools will always be ahead of all other development tools when it comes to supporting the latest Microsoft technologies. But there’s a flip side to that medal.

In the late ’90s, many developers chose Visual C++ and Visual Basic over Delphi because Microsoft is financially far stronger than Borland (which is true). Ironically, Delphi is still going strong, while Microsoft has pretty much abandoned Visual C++ and Visual Basic. VB is no longer being developed for Win32, and VB.NET is a different programming language. While Visual Studio 2005 supports C++, MFC applications can’t be easily ported to pure managed code.

Delphi, on the other hand, is still in active development for Win32 and Win32 VCL applications can be easily ported to .NET using the .NET version of the VCL. I’ve already ported most of JGsoft’s in-house VCL components to VCL.NET. This turned out to be very straightforward, even though some of the components are very complex (like EditPad’s text editor control). Essentially, any code using pointers needs to be rewritten. The only situation where you’re likely to deal with pointers in Delphi is when dealing with Win32 API calls. This gives me confidence to use Delphi to code for Win32 today, knowing I’ll have a straightforward upgrade path to .NET should I ever want it. Sure, Delphi will support new technologies like Windows Vista later than Visual Studio. Frankly, that’s fine with me. By the time Delphi does support Vista, most of my customers will still be using XP, and that will still be the primary OS I

All this is no surprise to me. Microsoft is a platform vendor. They make money selling Windows. Visual Studio is a complimentary product aimed at helping programmers crank out more stuff that requires Windows. If Microsoft wants to sell a new platform, like .NET to compete with Java, it’s in Microsoft’s best interest for programmers to start cranking out stuff that runs on the new platform, but not on the old one.

Borland on the other hand, or whatever the new home of Delphi will be called, is a developer tool company. They make money selling tools to make it easy for programmers to crank out stuff that runs on whichever platforms people are using. It’s in Borland’s best interest to make Delphi compatible with all the popular platforms out there, and to provide their customer base with an easy upgrade path when new platforms emerge.

Tools from a development tool company will always have greater compatibility with whatever’s out there than tools from a platform company, while tools from a platform company will have better support for that company’s platform than 3rd party tools. Which one is best for you depends on your goals.

After six months of waiting, I finally have a brand new ADSL connection. While it’s certainly possible to run a shareware business on a dial-up connection, comfortable is something else indeed. It’s just such a bother to wait for the modem to connect, wait for pages to load, etc. that I gave up on many Internet-activities, such as regularly posting something on my blog.

But I’m back now! I got the most expensive package my ISP offered, paying 2700 baht or about US$70 per month for a 1024/512 kbit business package. So far, my connection has been better than expected. It actually delivers the advertised speed on international connections most of the time. Thailand is not exactly known for reliable and/or fast international internet connections.

Fortunately, things are improving all the time. The fact that the former state agency will finally lose its monopoly on international telecoms this year is no stranger to that. If they hadn’t gotten their act together by now, some of their soon-to-be-former customers would quickly compete them out of the market.

I’ve been using Delphi 2006 for a little over a month now, and I must say I’m quite pleased with it. EditPad Pro 6 betas 4 and 5 are the first releases of JGsoft products compiled with Delphi 2006.

One major gotcha with Delphi 2006 that doesn’t seem to have received much publicity is that Borland no longer officially supports Windows 95 and NT4 as deployment platforms. Delphi 2005 already required Windows 2000 or XP for the development system, but still supported Windows 95 and NT4 as deployment platforms. This doesn’t mean that your Delphi 2006 application won’t run on Windows 95 or NT4, but there may be issues. If supporting Windows 95 or NT4 is vital, I recommend sticking with Delphi 7 or earlier.

The main benefit of Delphi 2006 is the new IDE. At least, new for those of you using Delphi 7 or earlier. Since Delphi 7 is what I used previously (and still use–I won’t migrate everything just yet), that’s what I’m comparing Delphi 2006 against. Some of the features I mention as new may actually have been introduced in Delphi 2005 or Delphi 8.

The new IDE does feel sluggish. I don’t know if that’s because it’s a .NET application, or because of all the new features, or both. However, it’s perfectly useful on my 2.8 GHz Pentium D 820, which is not exactly the fastest CPU you can buy. The IDE does not take advantage of dual core CPUs. CPU usage never goes above 50%.

The IDE enhancements that I’m enjoying the most are releated to the debugger. When you hover the mouse over an identifier, you get a tooltip showing the value it holds. In Delphi 7, the tooltip is pretty useless when the identifier is an object, since it just indicates the value of the pointer. In Delphi 2006, the tooltip shows a list of field values. If you click the + button you can expand the tooltip like a tree view to see inherited class values and the values of fields that are themselves objects. The same tree-expansion system also works in the local variables list and the watches. Very nice.

The local variables list is now also capable of showing the variables local to any of the calls listed in the call stack. That makes it very easy to check the state of calling methods, without having to set breakpoints in each of them.

Class completion (Ctrl+Shift+C) has gotten a little smarter. In Delphi 7, it will insert new methods in alphabetic order only if the methods are already in perfect alphabetic order. Otherwise, the new method goes at the bottom. In Delphi 2006, class completion makes a best efforts at maintaining alphabetic order, even if the methods aren’t alphabetically ordered. Double-clicking on an event in the Object Inspector now does the same.

Error insight is also quite nice. Just like the spell checker in many word processors marks misspelled words as you type, error insight marks syntax errors as you type. It does makes mistakes sometimes, marking correct code or missing certain errors, but I still like to keep it turned on. Its particularly useful for catching typos in identifiers or mismatched brackets or begin/end keywords. Its much more convenient to catch those right away rather than at the next recompile, when your brain has moved on to a different section of the code.

The many refactoring commands are also very nice. The one I’ve used most so far is to rename an identifier. It’s quicker than a search-and-replace because it works across units, and safer because it doesn’t mess up other identifiers with the same name (e.g. two classes with a property of the same name). The biggest disadvantage of the refactoring commands is that I keep forgetting to use them. I’ve been editing code without them for so many years making it hard to break my habits. I’m planning to learn to use the refactoring commands more often one by one, and gradually make myself comfortable with what then can and cannot do.

The good old tabbed component palette is gone. The new pallette shows expandable categories containing all the components with a glyph and their names. I actually didn’t like the new palette at first, because it took up a lot of space showing only the components of one or two categories. Accessing another category required scrolling. Though the tabbed pallete could only show one category’s components, it did show the tabs of all categories, making accessing any component a two-click process at most.

Fortunately, the new component palette is quite configurable. Just right-click on it and select properties. I set the button size to medium, which is the same 24×24 pixel size used by the old palette. I also turned off the option to show component captions. Though many of the glyphs have changed, I didn’t find it hard to get used to them. Now, I can access the components from the categories that I use most in an instant. I can keep the components of several categories visible at a time, without obscuring too many of the other collapsed categories.

Another big change is the embedded VCL designer. By default, forms no longer float like in Delphi 7, but sit docked in the code editor window. You switch between a form and its code by clicking on a tab. This works nicely on a single display computer, since it can’t practically display the designer and code editor side by side anyway. But when using a dual monitor system, using one screen for code and another for design is very practical. To do this with Delphi 2006, you first have to disable the embedded designer. Select Tools|Options in the menu, click on VCL designer in the tree at the left, and deselect the checkbox at the right.

The VCL adds a bunch of new components to the “Additional” category. TTrayIcon puts an icon in the system tray, and can show tooltips and balloons. TLabeledEdit combines a TEdit with a TLabel. TCategoryButtons is the component the Delphi 2006 IDE uses for its component palette. If your application needs some sort of object or tool palette that’s too big for a toolbar, this seems like a very nice component. If you use it, I do recommend you offer your users the option of showing or hiding captions, etc. like the IDE does. The TButtonGroup component shows a group of buttons just like TCategoryButtons does, except that it cannot categorize the buttons.

The TFlowPanel and TGridPanel components seem to have been inspired by the layout managers that Java has had for a long time. They make it possible to arrange components flowing from left to right and top to bottom, or in a grid. When the form is resized (and the layout panel along with it), the components are automatically reflowed or the grid is resized. Basically, these components relieve you of the task of specifying pixel coordinates and sizes for the controls on your form.

The Delphi 2006 IDE has been very stable for me. It’s not perfect, but not worse than Delphi 7. I’ve had two crashes where the IDE simply vanished after class completion gave an assertion failure. Sometimes, the IDE slowly starts eating up all available memory. When that happens, the code editor starts needing a second or more to process each keystroke. Saving the project, closing the IDE, and restarting it makes the problem go away. I suspect it’s a memory leak in one of the features like error insight that contantly monitor what you type. It’s a bit annoying when it happens, but nothing to worry about.

You will need a beffy computer to run Delphi 2006. While Delphi 7 always stays under 100 MB of memory usage for me, Delphi 2006 usually eats up about 200 MB or 300 MB. However, Borland does seem to have had some success in improving Delphi 2006’s performance and memory usage when compared with Delphi 2005. It also helps that Delphi 2006 can be started with just one personality. Instead of launching the IDE with all installed personalities, you can make it load just the one you’ll be using.

Delphi 2005 was almost unusable on my previous development system with only 512 MB of RAM. Delphi 2006 does work just fine on my notebook which has a 1.86GHz Pentium M CPU with 512 MB of RAM. But it’s definitely more comfortable on my desktop with has a 2.8GHz Pentium D 820 with 2 GB of RAM. You don’t really need a fast CPU (the Pentium D 820 is probably the slowest dual core CPU), but you’ll definitely want at least 1 GB of RAM to work comfortably.

Speaking of personalities, another big change compared with Delphi 7 is that Delphi 2006 not only includes Delphi for Win32 and Delphi for .NET, but also C# for .NET and C++ for Win32. If you plan to use C++, you do need to install Update 1 to upgrade the C++ personality from preview to production status.

So, would I recommend an upgrade to Delphi 2006? There’s a number of factors to consider. First, you’ll need a much beefier PC than you ran Delphi 7 or earlier on. Second, while the new IDE features are very nice, you’ll have to consider if they’re worth the money, particularly if you’re planning to stick with Win32 development for the time being. Based on the fact that Borland is now using years as version numbers, I’m expecting to see a new Delphi release every year. Borland’s roadmap for Delphi certainly seems to indicate that. DeXter, now known as Delphi 2006, was released late 2005. Highlander, focusing on .NET 2.0, is scheduled for 2006, and Delphi Longhorn, focusing on Windows Vista, for 2007. That’s going to make keeping up with each new version expensive. So you might want to plan ahead and look at the features you really need.

That said, I do feel more productive with the Delphi 2006 IDE than with Delphi 7. Particularly the debugger features I mentioned earlier are very helpful.