I love consistency. I believe it is one of the primary reasons I was predisposed to be a programmer. Input X into a function and get Y in return - and get the same result every single time forever. Which leads me to the topic of the day: How do you upgrade software that you write? Releasing updates is a fine balance. Too many releases cause pain, and too few releases cause pain - just in different ways.

Let me start with my premise: All software is released with bugs (I'll concede that zero defect software exists, e.g. medical devices, NASA, etc., but that is not even close to the norm in the business world today). Some bugs are small, some are huge. Some you can work around, some cripple the usefulness of the application. Some are known, some are yet to be discovered, but the bugs are there. How do you address getting fixes to these bugs to your customers?

One method is to have rapid patches, addressing the most severe bugs first. I love this approach. It does come with some extra burden to make sure that your software is up to date with the latest and greatest software, and you may need to install several patches over the course of time, but I like the incremental approach.

Another method is to roll as many bug fixes into a patch and deliver less frequent updates. This is certainly better than no updates, but the end result as an end-user is that I end up living with bugs on my computer even though the vendor has fixed the bug ages ago (comparatively speaking).

So, the logical conclusion is that you like one approach or the other. If you like the first method, it is illogical to then turn around and question why this is being done (i.e. "What's wrong? Is the software too buggy?"). Of course it has bugs. See my premise earlier if you don't believe me. But the fact that the vendor is taking quick steps to address the bugs is a great thing. If, on the other hand, you prefer the second approach, then it isn't fair to criticize the length of time between the updates. Both of the complaints above are just a matter of degree. It is impractical, and dare I say, impossible, to do both approaches simultaneously.

Borland has moved from lengthy, all-inclusive patches to a model closer to the rapid patches. I see countless examples of people who used to deride Borland for adopting the all-in-one patch model now complaining that they are releasing too frequently, and that, somehow, it reflects on the quality of the application. Unfortunately, in business, money matters. Schedules are set, profit targets are projected, books are balanced, and goals are measured against the bottom-line. Rarely does a software product ship "when it's ready". It ships when management says it must ship. The developer's job is to make it as good as they can in that time-frame. I wish that would change, but that's not going to happen until the entire software industry realizes how that can impact their bottom line. So, my bottom line is this: While software from any company is not perfect, I love the fact that Borland is releasing frequent patches.

I just read this post on how Ancient Egyptians must have understood Object Oriented systems by Rockford Lhotka. Rockford has (arguably) the book on Business Objects in .NET. He's also been on DotNet Rocks.

After reading his blog entry, I found myself truly laughing out loud. I was imagining a bunch of Council Leaders in ancient Egypt sitting around in a meeting trying to capture all of this in UML. Maybe you could draw a correlation to UML and hieroglyphics. Perhaps they were sitting around in a JAD session trying to fine-tune the roles and responsibilities. Which leads to the real question: Who was the PHB in this scenario? At any rate, it's definitely worth a read.

Atmapuri posted this message in borland.public.delphi.non-technical about his obsersavtions on memory leaks in Delphi 2005. He also posted some steps to disable Together to make the memory leaks go away, and also some information on what could be affected by doing this. Obviously, do this at your own peril.

The 10,000 foot view highlights from his post:

The severity of the memory leaks is proportional
to size of the source file being edited.

To completely resolve them:
Remove or rename the following packages
to disable Together:

"tgide90.bpl"
"borland.studio.together.dll"

in the \Bin directory.

It is not sufficient to disable Together from the Project
menu!!! The memory leaks due to Together will
happen as soon as you use the code editor and while
the Delphi is starting.

And here is the list of things he thinks get affected when you do this:

It affects ECO II modeling in Delphi.NET and C#. ECO II will still
work, but modeling will not. If you use W32 only
I think you dont loose anything.

Check the original post out for more detailed techincal information. Great stuff, Atmapuri!

Wow, Borland has been busy. They released a patch for Delphi 8 and a patch for Delphi 2005 in the past couple of days. I love seeing this kind of effort to get the tools as stable as possible. Thank you to the whole Delphi team for getting these to us!

As a quick bit of background, the Delphi 8 Update 3 patch fixes the problem with .NET 1.1 SP1 and is binary incompatible with previous Delphi 8 versions. The Delphi 2005 Update 1 patch solves the most pressing issues with the RTM version of Delphi 2005 (most notably, memory leaks!).

I was reviewing some multi-threaded code for a friend last night. The code was causing problems, especially on a multi-CPU machine. The code was using global variables and no synchronization to protect access. So I did some searching on google and found some very good primers on threading in Delphi.

• Multithreading - The Delphi Way
• Waking From Threadmare
• Children Of Threadmare

Borland has started interviewing some R&D engineer, and is broadcasting the chats over the internet. You can hear the chats live, and even ask questions. Here is the schedule of chats. This page lists all of the chats, but keep an eye on EventCentral, Borland's new calendar program, for more information about the chats and other Borland-related events.

After the chat is over, Borland is making a transcript of the chat log and an audio replay of the chat available. So if you can't make one of the chats live, you can hear it later. Here is the list of available chats. Borland continually updates this page as more chat replays become available.

Here are the steps I use to debug an NT service that was created with Delphi 6. While this works for me, there may be room for optimization.

1. Our applications differentiate between a service and server version by conditional define. If you do the same thing, be sure to remember to compile the server with your "SERVICE" directive in Project | Options
2. In Project Options | Linker, check the options for "Inculde TD32 debug info" and "Include Remote Debug Symbols"
3. Do a full build on the server
4. Register and install the service (e.g. "mysrv /regserver" and "mysrv /install") . The regserver part is needed if your serivce is a COM service.
5. Set breakpoints where you want them in the server code
6. Open up the Services Control Panel applet
7. Select the server in the applet, and press Start
8. *VERY QUICKLY*, go back to Delphi and select Run | Attach Process, select the service executable (e.g. MySrv) and press Attach
9. You may get a CPU view in the Delphi IDE at this point. If so, press F9 again.
10. You should be able to run a client now and have the breakpoints be respected. You may be presented with the CPU view when the breakpoint is tripped. Just go to the source window, and everything should work as normal.

NOTE: The reason for the CPU view is due to a MS problem in ntdll.dll. For some reason, they shipped Win2k and above with a hard breakpoint in the file. I used this Delphi expert, and things worked much better. You may need this file in order to get debugging working. Then again, you might not. ;)

I've had limited experience using unit testing, but I have read a considerable amount on the subject - especially as it pertains to Java. Most of the time, I want to add unit testing, but it's always a hard sell to management. It's an even tougher sell to management when you come in to a project that has been selling. After all, "The product works fine. Sure, it may have some bugs, but we'll fix those in due time.". I come from a more proactive school of thought where I'd rather we find ways to prevent bugs in the first place, and have the code be maintainable enough to fix it when a bug does creep in.

That's where unit testing comes in. If you can find a way to automatically identify bugs before they get into your codebase, you're much better off. Additionally, writing unit tests typically results in writing more maintainable code. After all, I would hope that you wouldn't want to write one test case to exercise a 3,000 line function. :-(

All of the above is just an introduction to John Kaster's BDNTV episode on unit testing in Delphi 2005. Check it out. It's short, but still very informative.

I've been playing with AQTime for a little over 1 week now. All in all, I love it. My company bought 2 licenses because we saw the potential in the product.

Here are the things I like so far:

• Support. The people on their newsgroups are fantastic.
• The GUI. They make liberal use of DevExpress components throughout, and do so quite capably.
• The new Assistant window that helps guide you through the profiling process.
• The samples and documentation.

The things I don't like so far are greater - not necessarily in number, but in quality.

• Leaked Delphi objects are reported as "VCL native memory.N", where N is the number of VCL objects that have been created so far. AQTime 3 reported the actual object name here.
• If you use run-time packages (at least with Delphi 6), AQTime 4 won't show you any leak information. AQTime 3 showed me leak information without fail. According to Atanas, the next version of AQTime 4 should fix this problem.
• In AQTime 3, they used to have a profiler called Reference Count Profiler. This would help you identify bad AddRef/Release lifetimes. The claim is that AQTime 4 can get by without this, but I'm not sold yet - especially given the first 2 points.
• I have a support issue open trying to get DCOM Server support done properly in AQTime 3.

Now, I realize that I'm just coming up to speed with this product, and this may very well be a case of RTFM and/or learning curve. I reserve the right to move things from the "like" to "don't like" category as I learn more about this very powerful product. But the bottom line is that, for most of our profiling right now, we are using AQTime 3, as it seems a bit more capable than AQTime 4.

During my perusal of their newsgroup, I noticed a little tidbit that said something to the effect of: AQTime 4 is a new version of AQTime that merges together the old Unmanaged profilers and the newer .NET profilers. During the effort to get AQTime 4 produced, they understandably looked for ways to improve the product. They probably shared new codebases, consolidated the list of profilers, etc. The combination of all these things means that I'm waiting for patches to AQTime 4 before I can use it to it's fullest extent. I know of Atanas' well-deseverd and excellent reputation in the Delphi community, so I'm not worried that I'll never get what I want. I just hope it's sooner rather than later.