Delphi Clinic C++Builder Gate Training & Consultancy Delphi Notes Weblog Dr.Bob's Webshop
Bob Swart (aka Drs.Bob) Dr.Bob's Delphi Clinics Dr.Bob's Delphi Courseware Manuals
View Bob Swart's profile on LinkedIn Drs.Bob's Delphi Notes
These are the voyages using Delphi Enterprise (and Architect). Its mission: to explore strange, new worlds. To design and build new applications. To boldly go...
Title:

.DCU compatibility of Delphi 2006 and 2007

Author: Bob Swart
Posted: 3/6/2008 11:25:35 AM (GMT+1)
Content:

Delphi 2006, Delphi 2007 for Win32, and Delphi 2007 for Win32 R2 plus the Win32 identity of CodeGear RAD Studio 2007 are all .DCU-compatible with each other.
This may sound like no big deal, but if you've used Delphi longer than today, you know that in all previous versions of Delphi before Delphi 2006, each new version of Delphi would have a slightly different dcu (interface?) format, and would be unable to use any .dcu file compiled with another version of Delphi.

This has lead to some consequences for third-party component and library vendors: if you didn't provide source code for your components or libraries, then the .dcu files would be locked to a specific version of Delphi. Which is not recommended, of course.

When the work on Delphi 2007 started, it was already announced that Delphi 2007 for Win32 would be a non-breaking release - maintaining .dcu-compatibility with Delphi 2006, but it was not clear to everyone if the .dcu-compatibilty is still around for Delphi for Win32 R2 or CodeGear RAD Studio for that matter. I just tried it, and CodeGear RAD Studio is still able to use Delphi 2006 .dcu files. And vice versa - Delphi 2006 can also use .dcu files produced by Delphi 2007 for Win32 as well as CodeGear RAD Studio.

The only exception may be the dbExpress unit, which break this compatibility in three places: SQLExpr, DBXpress, and SQLConst. Only SQLExpr contains components. DBXpress has been deprecated. So that's an area to keep in mind when sharing .dcu files between Delphi 2006 and 2007...

Back  


15 Comments

AuthorPostedComments
Xepol 08/03/06 12:37:06Ya, except that they changed a few core packages which lead to some very strange problems that broke things in very strange ways.
Brett Graffin 08/03/06 17:13:17How about Delphi2008? Is there going to be a Delphi2008? By this time last year I was inidated with advertising about "Upgrading to Delphi2007". I haven't heard a word about any Delphi2008. And the bigger question is: If there is going to be a Delphi2008, is it going to be non-breaking as well?. I have "hundreds" of 3rd party pruducts that I bought over the years. Some I have to pay to get them upgraded to the "breaking version" of Delphi. Please tell me it's not going to happen again...
Harry Seldon 08/03/06 19:00:13IMHO, I think Delphi 2007 (December 2007 ISO) is the "goto" version because it is fast and now stable. It includess the February 2008 Help Update, so "December 2007 ISO" so they were trying to avoid having "2008" in the name of the ISO. FWIW, I consider Delphi 2007 to be primarily a bugfix upgrade of Delphi 2006. And with several huge bugfix updates to Delphi 2007, it may possibly be the most reliable version of Delphi we'll see for a few years because the next version adds unicode, and the next will add 64-bit (both likely to introduce at least some bugs.) Hopefully, the version after that will be a "stabalizing and optimizating" release like Delphi 2007.
Mario 08/03/06 19:44:18i can't upgrade to 2007 version cause dbx4 is not compatible with Firebird blobs fields, for me that's a breaking release :(
Jolyon Smith 08/03/06 20:35:06@Brett: Delphi 2008 is expected later this year. Unfortunately for you (and others in the same position) current information is that Delphi 2008 will be perhaps the most-breaking Delphi release yet, since this release will incorporate the step-up to Unicode support. That is, you won't get any choice - your projects in D2008 will be Unicode, whether you want it, need it, like it or not. i.e. No compiler switch. For existing applications not coded to correctly support Unicode, and still using "String" types, this means you will have to ANSIfy your projects (change "String" to "AnsiString" etc) to ensure continued correct behaviour of your code with D2008. Of course the same will apply to any 3rd party components/libraries - assuming you have the source. CodeGear are endeavouring to ensure source compatability as far as possible, but even this they have already said is not going to be 100% achievable, and does not alter the fact that you application will no longer be ANSI any more, and will be capable of accepting data input from users, and manipulate that data, for which it was never designed. For many people this may not be a problem, and as long as your source compiles you might choose to simply hope that behaviour has not been adversely affected by the switch to Unicode. But "cross your fingers" is unlikely to be appropriate if you are in a commercially sensitive situation, in which case I suspect you will need to at least "ANSIfy" your source as well as get updated components/libraries (or wait for them from the suppliers) before shipping builds made with D2008 (a.k.a "Tiburon" by the way). I personally am hopeful that CodeGear might yet change their minds, as there does exist (imho) an alternative approach to providing Unicode support that would not be such a breaking change, and which would in fact provide a more flexible Unicode implementation into the bargain.
Xepol 08/03/06 20:43:48Truely, the next version is gonna be one heck of rough ride for component writers in general.
Brett Graffin 08/03/06 21:12:18Thanks for all of the responses. Wow, my whole outlook towards D2008 is now different. “Ansify” strings. Yikes, that will kill me. I have 12 years of coding to go thru. You think they could come up with a compiler switch to allow "string;" to remain in code and behave Ansi-like. 3rd party products will need to be update? I'm dead. Fortunately after Delphi5, I always purchased source. But that was not always possible. Getting all of the 3rd part products to update, whether I fix it or they do, is probably going to make me do something I have not done in a long while. Not upgrade. That stinks, I want to support CodeGear. All of these new facts being presented make the situation sound pretty ominous. Yes, I can stay with D2007 for a few years, but I remember migrating from Delphi6 to Delphi2005 (I bought 7 and 8) did not actually use them. That upgrade was a “heartbreaking” upgrade. I lost CodeRush; and at least 20% of my components had to be substituted for a new product. It took months to get all of the code working properly under D2007. I made a promise to myself to stay current with future releases, so I would not have to do that ever again. Thanks for all of the replies. Even though it was bad news for me to hear.
Naughty Kiwi 08/03/06 22:37:36CodeGear should have another file type, .dcx. It would be an intermediary format. Not humanly readable, but comprehensible by the compiler so it can be recompiled into a DCU on any version of Delphi. Component developers could thus ship .dcx files rather than .dcu files for every Delphi version. Of course if the used units change...
Cesar Romero 08/03/07 00:33:54Mario, Blob fields problem was a bug in Midas.dll and dont even Interbase dont work, it was already fixed, I can confirm this, coz Im using this righ now in 3 different projects.
Xepol 08/03/07 02:04:48Cesar -> Maybe write the compiler so it can compile code encrypted with a public key.... Then distribute encrypted source that only the compiler can decrypt. Of course, then some cretin would come along and write a memory sniffer to strip the unencrypted code out of the compiler on the fly, so maybe not... (of course, if someone really wants source for a component, there are plenty of fast and easy disreputable ways, so really its a matter of the honest people vs the less honest people...)
HeartWare 08/03/07 13:49:15Thank you for testing .DCU file compatibility. Now I can (re-)install Delphi 2007 over Easter to get the latest version (for some reason, the update feature fails on my machine - probably because I haven't saved the installation cache).
Theodor 08/03/13 23:06:58Does RAD Studio 2007 (any of the 3 editions) contain the source to the VCL, like previous versions of Delphi? I installed the trial but don't seem to have the source code.
Bob Swart 08/03/13 23:15:20All non-trial versions contain the VCL source code (but it wouldn't be wise to give it away in the free trial version, so it's not included in the trial, but it is included in the real versions).
DelphiUser 08/03/28 17:27:46Repeating here what I said in Nick's blog: Microsoft has a UnicoWS.dll/MSLU solution, and I hope an interface may be put together a wrapper for Delphi. Isn't there a Jedi project for this, perhaps? (probably not yet, since it's only just become an issue.)
jojo 08/08/11 20:20:29Perhaps the following has some relevance to the discussion: http://blogs.codegear.com/abauer/2008/07/16/38864/


New Comment (max. 2048 characters, no HTML):

Name:
Comment:



This webpage © 2005-2019 by Bob Swart (aka Dr.Bob - www.drbob42.com). All Rights Reserved.