Drs.Bob's Delphi Notes (weblog)

Delphi Clinic

C++Builder Gate

Training & Consultancy

Delphi Notes Weblog

Dr.Bob's Webshop


	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

Author Posted Comments
Xepol 08/03/06 12:37:06 Ya, 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:17 How 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:13 IMHO, 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:18 i 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:48 Truely, the next version is gonna be one heck of rough ride for component writers in general.
Brett Graffin 08/03/06 21:12:18 Thanks 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:36 CodeGear 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:54 Mario, 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:48 Cesar -> 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:15 Thank 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:58 Does 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:20 All 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:46 Repeating 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:29 Perhaps 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:

Author	Posted	Comments
Xepol	08/03/06 12:37:06	Ya, 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:17	How 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:13	IMHO, 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:18	i 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:48	Truely, the next version is gonna be one heck of rough ride for component writers in general.
Brett Graffin	08/03/06 21:12:18	Thanks 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:36	CodeGear 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:54	Mario, 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:48	Cesar -> 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:15	Thank 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:58	Does 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:20	All 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:46	Repeating 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:29	Perhaps the following has some relevance to the discussion: http://blogs.codegear.com/abauer/2008/07/16/38864/