Chris Bensen: Upgrading Delphi

It is always interesting (frustrating) following the upgrade/stick/switch turmoil that goes along with any consideration of moving from a stable devil you know tool versus the shiny new thing. Often the implicit upgrade cycle you would hope to happen is hindered by a slow release cycle on the tool of choice or lack of compelling features. These items have been beaten to death by others but I thought some personal insights from similar struggles I have seen may as well be added.

In any upgrade it is generally the "little things" that surface to haunt you so anyone that has been through a prior upgrade always entertains the idea that there are many of those gremlins just waiting for a chance to laugh at you publicly after you have deployed to your clients.

I participate in two significant products, one based on Delphi 6 and another still on Delphi 5. In both cases the volume of code, testing capacity, and potential re-platforming as are always cited as significant barriers to attacking the upgrade cycle. Due to 3rd party dependencies the latter project has an extremely high bar for upgrading. In both cases the problem is firmly rooted in not carrying out a natural and continuous upgrade cycle with robust testing. Until you have the "must have" in the new version you can't really afford to make the move. The business case simply does not exist and diminishes the further you get from the tip release of you development tool.

Rather than suggest you should not upgrade I think a pragmatic approach that I have found moderately successful is worth highlighting. For much of the server components of one of the products the code has been maintained in each new release of the Borland/CodeGear toolset but always back-compiled and tested using Delphi 6. So, all along the code was maintained in Delphi 7, BDS 2005, BDS 2006, and finally in RAD Studio 2007. That is great, after getting over the the initial hate for some of the IDE changes (SDI) you start to rely heavily on the new features like live templates, refactoring, code metrics, and models. Still nothing new is needed for the product that goes out the door though so upgrade sell is weak based on a "feature case."

But there are definitely reasons to upgrade. Recently, we were doing capacity testing and were a bit disappointed with our numbers and needed a quick hit. Without a single change to compiler options, code base, etc. we performed the same capacity testing with the application suite complied under RAD Studio 2007. We immediately saw a consistent 25-30% capacity volume increase. The majority of this is easily related directly to the the new memory manager (FastMM) and better inlining of key functions. Most of these items we could get if we were willing to alter the system to include or use 3rd party tools but the whole point was OOTB improvement. Since it was server-side code VCL changes really were not a factor.

We did not need the increased capacity immediately so we simply tucked it away in the "good to know" column. Had we needed it I am sure an upgrade on the server components would have happened right then (not a strong enough business case). We are now taking steps to assess a full upgrade on the client and server components and work out a process that will not leave us hung on an older version as we are now. What is the biggest hang up? Proper coverage for the testing. You can never have enough and dealing with tool related problems is never a good sell. An upgrade advisor tool that can run on a project would certainly be nice to have.

Over time though there has been a persistent set of issues that never quite seem to be addressed when you are trying to push a particular upgrade. Don't get me wrong, I am fully in the "upgrade often and stay upgraded" column but this list contains the items that most often leave me hesitant:

1. Install Experience - What you get after you finish the install is great... but getting there is appalling and there is no amount of counter argument that can ever suggest it is acceptable. Most persons that have installed any recent BDS/RAD Studio have most likely installed other products that are equally complex. I can get through OS + Service Packs often faster than I can do the same for RAD Studio. Suggestions that this is an MSI (Windows Installer) problem only serve to alienate those who actually know that it isn't MSI, rather it is how it is being used. MSI may not be fun but it is often a necessary evil.
2. Software Assurance vs Upgrade Cost - Upgrade costs always factor. The problem is they shouldn't, CodeGear has a fabulous subscription service called Software Assurance. While information about Software Assurance is more readily available these days it is still difficult to get your head around it and why it makes so much sense. Make subscriptions the only sales model and show clearly how your frequent release cycle makes this a cost benefit. There are blogs and even calculators out there that demonstrate this but "direct from CodeGear" means something.
3. Difficultly in showing the big benefits - The integration of dUnit, nUnit, MS Build (hmmm, wanted NAnt myself), FastMM, for each looping, code metrics, refactoring, generics, live templates... the list goes on and anyone following along with the upgrades is inherently aware of them and enjoying them but each of these is small by itself and information on them is more often found in blogs or secondary sources. These factors all play into quality and effort reduction improvements in our own projects in terms of quality, defect rates, and performance. The leading question is how do you turn that into a strong business case. The sales pitch "have less defects, more developer time, and a faster more robust product" may exist on the CodeGear site but I haven't seen it.
4. Documentation - Having used Delphi for so long I can't really appreciate the documentation woes that exist but on the occasions I find myself hunting for something in the help I realize just how difficult it can be for an OOTB experience. The help has been improving in first-use and correctness with each release but in some ways is still not on par with Delphi 7 and earlier releases (the language guide is still hard for me to locate to this day). The "little things" kill you here. Try finding the list of VERxxx compiler defines... (tell me if you find it).
5. Features only beneficial on new projects - ECO... everything I have seen and played with suggests this is a great addition to Delphi but the fact remains it is similar to re-platforming when it comes to making use of it. Give me MAC's, 64-bit, Unicode and even CF. These are core improvements I can use on products that have hundreds of man-years invested.

In the end the Delphi product is targeted at developers but the install process is so burdensome that it is difficult for a business application developer to potentially have to spend time on assessing and using the tool when the install experience takes up valuable time and leaves the wrong taste in the mouth and leaves little for a concrete experience in the software.

After all the non-positive comments above I still have to say that the upgrades are well worth the effort but that is more from the fact that I know the benefits are in there from constant exposure to them as opposed to looking at any given

information on the CodeGear site and going "Wow". So, if you have been hedging on upgrading I strongly encourage you to get past the OOTB experience and get used to the product. The benefits are there and your productivity will actually increase. You may even like the SDI interface after some time ;-).

Chris Bensen: Upgrading Delphi
Why aren't you upgrading Delphi- Reasons and myths

Labels: Borland, Delphi

Technorati: Borland, CodeGear, Delphi

MSN Desktop Search Delphi code

It was quite some time ago that I discussed an IFilter implementation using Delphi code. Here is the code for that blog post.

 

Source download link (v2.1)

Technorati: Borland, Delphi

Labels: Borland, Delphi

Borland Drops StarTeam Standard and Web Editions

Well it looks like Borland will continue the pattern of introducing version control sub-systems that I like and then removing them from the line up after two or three years. It appears the Standard Edition of StarTeam does not meet with the Borland ALM direction so anyone using it can either move up to the Enterprise licensing or somewhere else. The notice indicates that version control is a commodity so I would expect they believe that anyone who thought that the standard SKU was satisfactory will transition to sub-version or some other free tool.

This is twice now that Borland has provided a version control solution with the Delphi license and then go on to drop support. Both times I was quite happy with the solutions and happily moved to them. TeamSource was a great small shop tool and I really liked the model and integration. I didn't mind switching to StarTeam either and had become rather attached to the great linking support and build tagging.

The problem with this announcement is that the it leaves StarTeam in an all or nothing (planned it would seem) position and if you already have the rest of the change request/ticketing/project management bits taken care of outside of the Borland suite of tools. So, the upgrade scheme isn't really going to fly with me :-(.

The documents that are linked below make no references to the status of StarTeam within the DevCo/DTG but I am sure something will pop up shortly.

Further reading:

Borland Support Newsletter October 2006
Borland StarTeam Standard Edition CR-only Sunset FAQ
Borland StarTeam Edition Sunset Customer Notification

Delphi 2005 Rollup Update

Allen Bauer has posted a rollup of his recent Delphi 2005 fixes. It is really good to see Borland rolling out these informal (read pre-beta) patches as they are being corrected in the next major release.

You should also head over to the Borland site to pick up the preview release of the compact framework support (compiler only). This is just what many of us were asking for and it is a great thing to see them deliver. I haven’t had much time to play with it myself yet but it is definitely on the list and I will be converting a smallish golf related applet over to it as soon as I can.

Kudos to the Delphi team for their devotion.

Delphi and the Compact Framework, Real Soon Now?

David I posts about a preview they are showing at the SDC sessions. From the blog post it appears that we may very well see a preview compiler targeting the .NET Compact Framework prior to the next major release of Delphi.

While details are sketchy it is extremely positive to hear about the compiler showing up prior to the next major release. Hopefully we can do our bit and flush out any major platform issues as part of a preview so the next major release can have something robust and workable.

Some background materials:
My point of view
Danny's preview of Delphi on CF
Allen's follow up on VCL/WinForms positioning


Kudos to the Delphi team for pushing it out the door :).

This is probably a good time for you to pick up Software Assurance if you haven't already. After you figure out what it is it doesn't make sense to not have it if you are using any Borland Tools.

Delphi and CaliberRM, getting an error

I was delighted to see the CaliberRM 2005 plugin being released (preview at least). However I had already downloaded and fiddled with the 5.1 SDK so I was left with a wonderful Unable to load Java VM specified in C:\Program Files\Borland\CaliberRM SDK 7.0\lib\CaliberRMSDK70.ini error message each time I tried to install the package. Pretty much the same thing I got when I wanted to try CaliberRM after having installed Delphi 2005. In my prior attempt I simply gave up. I continued on with my review of CaliberRM and must say that I really do like it (or anything like it). I tried it on a small project and the additional process and breakdown resulted in some extremely clear requirements being pumped out the other end. So, even within integration into the Delphi IDE I am impressed with the tool as a whole.

I figured the updated plugin would fix my problems... all it did was change the error message from the 5.1 SDK message to the 7.0 SDK message :(. Since my eval period is coming to a close I really did want to see it working in the environment. I tried reinstalling the SDK (well, a repair install on Caliber anyway) but that didn't resolve the problem. Since the SDK seems to be merged with the StarTeam SDK I figured I would start searching on that for some tips... StarTeam Support Entry solves the problem very nicely.

Now I can finally see if the integration is of any benefit :).

Delphi2005 and tlibimp

It appears the new type library import wizard is broken (or inconsistent). If you want to ensure you don't get component wrappers generated for a particular type library you should open up a console (dos box) and execute the following command "..\bin\tlibimp.exe -Ha- -Hr- -Hs- msxml4.dll" after having changed in the "\bds\3.0\imports\" folder. Change the library name and path(s) as required for your case.

As usual, you can edit the uses clause to remove the extra units that are automatically inserted (normally leaving only Windows and ActiveX are sufficient). This can be a benefit depending on your intended use as the compiled binary will have less dependencies and you can have a significant benefit on your binaries size.

Delphi.NET and the Compact Framework

Danny has provided an update on Delphi support of the Compact Framework. It all sounds very promising but...

For myself, and I would guess many others, we are being faced with a new challenge where PDA/Phone devices are much more prevalent to our solutions. In the past I have been very blessed by the hard work of the Delphi team to provide not only a top of the line visual tool for both client and server components but a complete tool that can be used for absolutely every need no matter how low level (only missing out on driver development but thank the gods I haven't had to do that). I enjoyed being able to easily contrast Delphi against VB, C++, and Java. If you wanted fast development, good maintainability, and robust software you choose Delphi. When it came to micro devices, in days gone past, it was easy to explain why alternate tools were required for Windows and Palm devices however with the broad availability of J2ME and .NET CF it is becoming much more difficult to continue to suggest that two skillsets are required to develop and deploy against these devices.

Without even marginal support for the Compact Framework Borland has, not intentionally, reduced Delphi to the position VB once owned for Win32 development. While VB has been available on micro devices for some time prior to CF.NET it was really a weak contender with extremely limited capabilities to actually use the platform. Using and supporting CF.NET gives Borland a clear chance to provide a viable alternative for long standing Delphi fans that are not greatly interested in a full scale switch over to C# or Java. If someone wants to suggest we don't have to consider the benefits of having only a single language their developers can support then they simply don't understand the cost savings and risk mitigation that are achieved when everyone in a dev shop can be tasked with code changes. The days when it was acceptable to keep a couple resources around for the C++/Java bits done on compact devices are gone.

What I am looking for from Borland is the ability to create and deploy applications to these devices. What I am not looking for are things like VCL.NET, advanced debugging support, and designer support. I would certainly take those features if they were offered but they are definitely not high on my list of needs. Having done development for Palm, Embedded VB, Embedded C++, and some recent CF.NET work I know that the most important capability I value is quite simply the ability to make it work on the platform.

Application servers, web clients, and full rich clients are still my bread and butter. Micro devices, while increasing in importance, still remains the candy to be offered as value adds to those primary services. The only thing I need right now is being able to target the CF.NET platform in if the methods are primitive.

So, if you want Borland to let you in the playground, rather than watching from outside the fence then head over to Danny's most recent blog on CF and let him know the things that you require most and that we need it sooner rather than later.

Delphi, Uses, IFilter, and MSN Desktop Search

It has been ages since I have posted anything and I have not gotten around to posting on some of the items I had in the queue but that will happen eventually.

I am sure many people are aware that the desktop search choices are coming out fast and furious. I have about 500K files/items on my local computer and I am definitely in the habit of misplacing a particular file often enough.

I hadn't bothered with the first Google Desktop Search (GDS) as it would not index content outside of a pretty refined set of file types. The recently released version corrects that problem and is a pretty small download. It does a much better job in what it will index and is extensible with some programming (using IDispatch based interfaces, tsk tsk). I am sure it will be a decent tool but I don't really have a high degree of trust in letting it into my Outlook data just yet. I have it installed on a Virtual PC to give it a test and play around with it. Since I use google as my mainstay web search it isn't a stretch to doing it on my desktop as well.

I have had the MSN Desktop Search beta installed since it was released. I simply couldn't pass on an opportunity to quickly search through my Outlook e-mail. The packrat in me has led me to having an archive policy set to six months and over the years I am up around 3GB of archived e-mail. Searching into those archives in a reasonable fashion is a dream come true. MSN Desktop Search does it both quickly and reliably. Searches against Outlook are incredibly fast and it hasn't let me down on a single search yet.

A secondary, although more often used, search need is grepping through the volumes of the source code (predominately Delphi). Typically I have stuck with the dos based grep and/or the Delphi editor supplied version. This works for many cases but the search speed certainly doesn't compare to what you find from either of the two search engines I have tried thus far. For code and html documentation libaries you simply can't lose by installing one of these search engines.

But... I want more. The MSN Desktop Search takes advantage of the IFilter interface that was designed for other Microsoft Search technologies such as Index Server and SharePoint (I am not convinced that the new search is anything other then a new face on an already pre-existing and robust technology). Using the IFilter interface permits you to use any existing filters that may exist such as the PDF filter that is linked on the beta download page. But, more importantly, it allows the addition of new filters that you can develop yourself for custom formats or specialized needs.

This was my first step into filter development so I started with something simple that would be of potential benefit to myself. I have many shared modules between many projects so a change in a particular module can have far reaching impacts. These projects can be old mothballed projects, up and coming work, and large efforts with many external dependencies that I need to watch for. Before, or more likely while, making some changes it is definitely an asset to initiate a light impact analysis to see any dependencies that should be watched for. So, to this end I figured a uses filter extension would be just up my alley. Since it involves parsing the Delphi source it also permits extending the search patterns to include searching for where classes and functions are used versus defined. Part of this is about just having some fun doing it versus building up an impact tool... good for helping with first guess estimates.

The uses filter parses Delphi source files, establishing the list of used units. Additional custom properties are added with the list as well as setting the standard keywords property with that list. This means I can execute a search such as "keywords:unit_name" and I am then presented with a list of Delphi source files that use that particular unit. This helps keep the search results short and usable since the words are not scanned in every e-mail, document, and text file floating around your local machine.

The picture belows shows a search that shows modules using two units at the same time. You will note that the named units are in the keywords properties (this also means we don't find units where the unit may have been historically used and may have been commented out, etc).



Delphi, of course, is the tool I used. After stumbling around for a while I ended up building up a filter interface file with the relevant declarations for constants, types, and interfaces. I then created a new ActiveX project and created the basic framework code with support for the necessary interfaces and stub implementations. Be an appropriately lazy developer, I decided to implement the filter as an extension/aggregate of the stock text filter the desktop search was using and simply tag my extra bits on afterwards. This means I wasn't losing any basic text search capabilities either. To this end, I was able to get the filter up and running pretty quickly with the help of the filter test tools from the MS SDK. Using Martin Waldenburg's excellent mwPasLex source code made accurately extracting the uses from the source files a breeze. After setting a few registry entries (see the MSDN IFilter for details) I was up and running with a working copy pretty quickly aside from the long re-index times required for good testing. The moral of that story is don't test on a machine with 500K files; thank heavens for virtual PC.


I am still testing and tweaking the code otherwise I would make it available on the site. If you happen to be interested in having the code (for any purpose) just leave a comment with a suitably spam-proofed e-mail and I will forward along the current version. I want to figure out how I can get the desktop search to respect my new properties for both display and searching. I didn't want to use the keywords property but all my initial attempts to get the search engine to use my "uses:" prefix simply failed. If someone knows how that works (not on SharePoint or Index Server) I would be quite interested since I think is where the real power resides.

Delphi 8 Update #3 - Fixes for .NET 1.1 SP

Well, it has definitely been too long in coming although I can understand they had other things to keep them busy ;-).

I am downloading it now. If you try to download I suggest you use the list files and then download the file contained in the zip. My attempts to download it through the download link just left me in a cicle of re-agreeing to the licensing agreement :-(.

Here is the link

A Great Support call between Borland and Microsoft

Allen's blog entry should ensure you smile at least once today. I am sure we have all then there to one degree or another. Thanks for the post Allen.

DiamondBack really moves some markers

The guys at Borland seem to have pulled out all the stops and implemented some of my most sought after capabilities. Specifically we have for ... in syntax (qc #6922), Multi-unit namespaces (i.e. real namespace support as we expect it) [Allen], and finally we will have function inlining support as well.

It does appear that Generics and.NET 2.0 support will be a post-release concern. Hopefully when the release comes out we will all remember that lots of positive movement has been achieved before we start complaining out the "other" new stuff we all wanted.

Thanks to Robert Love for blogging on these new features from BorCon.

As always, more information, more questions

A very well written note regarding the next version of Delphi. I must confess to agreeing with the content. I am even pleasantly suprised to see Nick with some very good comments along the same vein.

To date, 90% of my work still keeps me in Delphi 6 with a few jaunts into D7 and virtually no reason to spend much time in D8.NET (not saying there is no dotnet going on...).

I don't know the answers but I know the Delphi language and underpinnings are an elegant solution that needs to be marketed and promoted in a manner that adequately highlights its ability to produce solid solutions.