Is there any information on the project file, source code and *.dfm file compatibility between the different DELPHI versions.
If I do not use the latest features of DELPHi XE3 can I still open the code base and compile using eg. DELPHI 2010 ?
( I Know Unicode Issues, or Component changes like INDY 9 to INDY 10 will block the down grading , but this an other topic for me)
The bad think e.g. not working : use your Delphi 7 project, open and compile using DELPHI 2010, you can not reopen the project with DELPHi 7 because some objects will have extened properties from opening the project with 2010. Manual rework back to DELPHi 7 style in that case is rather time consuming.
Can a developer team work together, were members are using different DELPHI XX versions?
It's possible to do what you want but I cannot imagine why you would want to. When we ported our app from D6 to D2010 we had shared source that would build in both versions.
This was purely a transitional arrangement. As soon as we were confident in the D2010 port, we severed the umbilical cord. And at this point we embraced the new features of D2010 with relish.
In order to make this work we used the following crutches:
Helper functions to mitigate the ANSI/Unicode differences.
Unit aliases to deal with unit renaming. For example the themes units changed names from D6 to D2010 and the unit alias feature hid that.
Oodles of conditional code.
All this was needed because we had a porting task and so had to compile in both versions. The old version for our existing product maintenance, and the new version so that we could test and develop the port.
But I see no reason for you to do any of this., not least because it leads to very complex code. If you want your app to build in D7 then always build it in D7. Since you cannot use features of modern Delphi and retain compatibility with D7, why use anything other than D7? When you buy modern Delphi you also gain access to old Delphi versions.
Related
The following question has had me wondering for some time now as to how 3rd party component developers are able to ensure there components are compatible with all the various IDE versions?
I am just a single developer who uses Delphi XE and occasionally Lazarus, if I developed some components in Delphi XE how would I ensure they are compatible up to Delphi XE6 for example, and also compatible with older IDEs?
I don't mean in a coding sense because I believe you use the IFDEF flags when checking the Delphi version numbers. I mean if you don't have access to different Delphi versions how do you test the component?
It is not possible for me right now to purchase XE6 or a new Delphi IDE for a while - if it all, and even if I could I would not have previous IDE's like Delphi 5,6,7 etc.
So how do other component developers do it?
Purchase all the IDEs? which seems unlikely
Download Trials for the IDEs? which also seems unlikely
Get people to test the component if they have another IDE? Seems possible
Make it Open Source and let others test it? Also seems possible unless you want it Close Sourced
What it comes down to is I want to make a few simple components but I want them to be compatible with as many Delphi versions as possible should they ever be released to the public.
I don't have the means to get all the Delphi IDE versions and downloading trials may also not be possible. Even if I bought XE6 or the next release I would not be able to test with Delphi 8 for example.
So, how do 3rd party component developers make there components compatible and tested on various IDEs? Am I missing something obvious here, how can you have access to every Delphi IDE Version?
As a component vendor myself (I am the primary developer of Indy) who needs to support multiple versions, I can only speak for myself, but here is how I do it:
Purchase all the IDEs?
If possible, yes. I have a number of IDE versions installed in VMs, which I use for testing purposes. And for some versions that I do not have installed, I do have their RTL source code for reference purposes, at least. On the other hand, as a member of TeamB, I get free IDE licenses, which helps. Not everyone can afford to purchase every version, although newer versions do provide free licenses for older versions, so you should take advantage of that. I recently installed Delphi 7 through this. If a components works in Delphi 7 and Delphi XE6 then there is a good chance it will work in all versions in between (barring any version-specific RTL bugs, etc).
Download Trials for the IDEs?
N/A for me, but that might be a viable option for some people.
Get people to test the component if they have another IDE?
I do this with Indy. Although I do have several versions, I don't have every version. Other users who have versions I don't have myself do help. If nothing else, for setting up version-specific project files and testing install procedures.
Make it Open Source and let others test it?
This also helps. If you want to develop closed-source components, you could setup a private repository and give access to select users/volunteers. Most users want/need source code (to find and fix bugs when used in their projects, to satisfy corporate policy requirements, etc), so you should make sure you offer an option to pay for source code.
When you buy the latest you get access to all the previous versions (from v7 on - thanks Uwe Raabe)
Previous versions
I am using the first approach: Buy all versions. I have all Delphi versions back to version 3 (from 1997), but only 6 to XE6 are installed on my machine (with the exception of Delphi 8 which in my opinion should better be forgotten). But of course I didn't buy them all at the same time, I started with Delphi 3 and updated from there on.
Unfortunately it becomes more and more complicated to get older versions installed and running on "modern" operating systems (currently Windows 8.1 so far) so sooner or later I will be forced to switch to virtual machines. Not yet, though. Switching to VMs has the drawback that you can't batch compile using different Delphi versions:
call CompileForDelphi6.cmd
call CompileForDelphi7.cmd
etc.
like I do for GExperts.
There is a code base in delphi 2006 with no development for last many years. If the development needs to be activated what are the options.
Continue developing in 2006. (Not sure of IDE support etc.)
Migrate to Delphi XE2. (Not sure of what it takes)
Recode it in Java.
It seems the second option is more viable but what it would involve to do that? I read some things on Unicode support and also not sure of graphics library support.
Just to put thing in perspective, I am a Java programmer all along with experience on C/C++. However I am trying to understand it more from the perspective of what is the least resistance path to go to market strategy.
Thanks in advance.
I cannot say anything about recoding it in Java. Depending on whatever the code base does, it might be a good option, given that you say you are experienced with Java (and, I assume, not with Delphi).
Regarding Upgrading to Delphi XE2:
Check whether any 3rd party components have been used.
If not, you will probably be able to upgrade to Delphi XE2 with very few changes.
If yes, check whether the source code of these components is already available.
If not, you will have to buy new licenses of these components (and this time take the license that includes the source code!) if you want to upgrade to Delphi XE2. If you are really unlucky, the company who developed these components has gone belly up. Then you are either stuck with Delphi 2006 or you will have to find a replacement for these components.
If you already got the component's source code, you might still want to check whether to upgrade them to Delphi XE2. It might save you some headaches. Upgrading well written components is not a problem for an experienced Delphi developer (I have done so countless times over the years), but might prove nearly impossible for somebody who doesn't know the possible pitfalls.
The only breaking change between Delphi 2006 and XE2 (actually it happened between Delphi 2007 and Delphi 2009) is the switch to Unicode strings. Switching an existing code base might be painless or a real pain in the lower back, depending on how well written it is to begin with and how it (ab)used strings.
Another option you have not yet mentioned, might be upgrading to Delphi 2007, which basically was more of a bugfix to Delphi 2006 than a real release in its own right. If I remember correctly Delphi 2006 packages worked with Delphi 2007 without even recompiling.
A year ago I moved from 2006 to XE (not XE2). This was quite painless. The biggest thing was unicode. But even that was relatively easy (in my specific case probably). Most is handled by Delphi in a correct way. Biggest problems were the import components, especially when character strings were used as byte strings, which in my field (music, midi) is the norm. There is a white paper on strings conversion on Embarcadero.
I only use components with source available. If you don't, you might have have to repurchase the licenses.
It is a long jump taking 2006 to 2011/2012!
But it is possible if you consider that:
You have to convert String variables using the new conversions methods ;
You have to check all the versions between 2006 and xe/xe2 to know how the libraries have changed, bacause some have been spplited, others merged, and a few deleted ;
You have to buy/download the upgrade (if any) of your 3rd party components.
If you do that 3 things, the applications will compile just fine.
It's always easier to upgrade the IDE than rewriting the code, if there's any complexity in code beyond trivial cases like "Hello, World".
Big road blocks in Delphi 2006 might be: old components without source code, unicode issues, possible use of obsolete technologies (BDE mainly), and possible some low level hacking, like using undocumented features.
You get old versions of Delphi free when you buy XE2 licence. However Delphi 2006 is not there. Delphi 2007 is almost same (but better). It may even be possible to use D2006 binary packages with Delphi 2007.
When rewriting, first task for you is to find out what the software actually does. Line by line. Then you need to duplicate that in Java, hopefully in Java style, and then you need to verify against the old software that the functionality is actually there, duplicated.
So, you can choose between complete rewrite or something between recompile and partial rewrite, if there's problem with old components.
Read also this, old but good text: Things You Should Never Do, Part 1
That said, you need business reason for rewrite, and someone willing to pay for it.
I started occupational programming with Delphi when the Turbos came out , and have licenses for Delphi 2006 Turbo Pro and Delphi 2009 Professional. I have been asked to support another in-house tool, written by another occupational programmer, who has since retired.
It's a Windows program, but it was developed with Delphi 6 using the CLX library rather than the VCL.
From what I gather, the CLX library was QT based and was removed prior to Delphi 2006.The support only consists of a few bug fixes and some minor tweaks, so I would rather not port the code to VCL, if i can avoid it.
Is it possible to install CLX support into either Delphi 2006 or 2009?
Maybe not a direct answer but if you upgrade to Delphi XE, you will also get license keys for some of the older versions of Delphi down to 7, and Delphi 7 included CLX (it was dropped in Borland Delphi 2006).
The short answer is: no. Unfortunately I don't know any long answer which could tell you how to workaround this.
No, you can't add support for CLX to your other Delphi versions.
If it's in-house software, then your company should still have the in-house Delphi installation used to develop it. Multiple Delphi versions can co-exist on the same system; install earlier versions before installing later versions.
If the former employee took that installation with him when he left, can you get it back? I wouldn't expect it really belongs to him anyway. You said he retired; that wasn't a euphemism for died, was it? If not, then you can still contact him.
If there isn't an easy way (and I suspect that there is not), you may need to continue using D7. D2009 is going to introduce the hassle of Unicode, and even going to D2006 is going to cause problems with 3rd-party libraries.
You could run both versions of Delphi on the same machine, but another option would be to use a VM for the legacy development. Either set up a new instance, or you could use the VMWare Converter to convert the other developer's entire machine into a VM image, which you could run on your machine, via the free VMWare Player.
BTW, VMWare Converter is a GREAT way to preserve old environments, to allow maintenance on older software that really needs to use a particular Delphi version, on a particular OS, "just like I left it". If you have a bunch of dusty computers under your desk, consider this option. VMWare Converter is the only tool I know of that will easily convert a physical machine to a useable VM that will run anywhere.
It is possible to work with a Delphi 5 project in the Delphi 2009 IDE by referencing the Delphi 5 version of dcc32?
If so are there any issues to watch out for concerning the way that project settings (search paths, conditional defines etc.) are implemented in 2009?
Edit: Just to clarify I am also upgrading the project to Unicode but will still need to debug and run releases in the old configuration
It depends on what you're trying to accomplish and what limitations you are willing to accept.
As far as I know, you can't use the Delphi 2009 IDE to maintain Delphi 5 projects directly. For example, even if you stick to functionality that's common between the two, some properties that are not supported in Delphi 5 are written to your DFMs, causing an error at run time.
I've maintained projects and library code that were written in Delphi 2005/2006/2007 that was also being used in Delphi 6/7. I usually edited and debugged these using the latest IDE. I had separate project files for each target version and made sure they all used the same memory manager. Finally, I had an automated build process and unit tests that would strip incompatible properties out of the DFMs (my own DFM Scrubber), make sure all of the targets always compile and run unit tests, which are also recompiled for each target.
All in all, it's more effort and I wouldn't recommend it unless you have a specific requirement to do so.
No. That said, it is still Delphi, and assuming you have source or D2009 versions of any custom components it can be modified to compile in Delphi 2009. The layout of the VCL has changed quite a bit since D5, so expect to have to modify your uses clauses and probably rewrite some small chunks here and there, but it is doable.
You either port your code to Delphi 2009/2010 level (Unicode), or you may as well not install the product.
I suggest you open the project and see where it fails, close the project (without saving anything), find the component versions you need and install them, and once the project opens up in design mode (all components are installed) you can start porting.
Read the Unicode Delphi migration (porting) information available at the website.
Ask your self each time you see PChar, and Char, if it needs to be PAnsiChar, or AnsiChar instead? If you are reading bytes from a disk, a com port, or a network connection, you will need to change from Char to AnsiChar, from PChar to PAnsiChar, otherwise, you might just leave the Char and PChar as they are and they will become Unicode. Always be aware that Char is not a Byte, anymore.
You also must replace explicit references to narrow Win32 API calls with versions without the A (ansi) suffix. Example: CreateFileA might need to become just CreateFile.
W
In the company that i work, we develop all the GUI in C#, but the application kernel is mainly developed in Delphi 5 (for historical reasons), with a lot of components made in COM+. Related to this very specific sort of application a I two questions:
Experienced guys in Delphi and/or COM, do you have any workrounds to work with the buggy TLB interface ?
Some of the bugs are: IDE crashing during edition of a large TLB, lost of methods IDs, TLB corruption, etc.
Here, we haven't found any good solution. Actually we tried do upgrade do the new 2007 version. But the new IDE TLB interface has the same bugs that we found before.
How do you control TLBs versions ? The TLB file is in a binary format and conflict resolutions are very hard to do. We tried to do it exporting the interfaces descriptions to IDL and commiting into CVS, but we didn't found any good way to generate TLBs from IDL using Delphi. Additionaly, the MIDL tool provided by Microsoft, didn't parse correctly the IDL files that we exported from delphi.
I think you should have a good look at Delphi 2009.
Delphi 2009 has changes to the COM support, including a text-based replacement for the binary TLB files.
You can read more on Chris Bensen's blog.
In the distant past (before I started working for CodeGear) I gave up on the odd Delphi-ized IDL language that the IDE presented, and wrote my own IDL and compiled it using MS midl. This largely worked; the only catch, IIRC, was making sure dispids (id attribute) were correct on automation interfaces (dispinterfaces) for property getters & setters - there was some invariant that tlibimp expected but midl didn't guarantee.
However, now that Delphi 2009 uses a safe subset of midl syntax, and includes a compiler for this midl in the box and integrated into the IDE, these problems should be a thing of the past.
We have also just installed Delphi 2009 and it does seem to have improved the support for Typelibraries. However I have worked with COM and type libraries for quite some time and here are my general gotchas that I have found over the years. I would agree its pretty buggy and is all the way up to Delphi 2006 (our version prior to using 2009).
Always have every file writeable before opening. This may sound obvious, but when working with source control sometimes we forget to do this and try to remove readonly flag after opening a file - Delphi cant deal with this. Ensure tlb is writable before opening.
If editing a standalone typelibrary you MUST have a project open. For some reason if you open a type library on its own it will not save. Create a blank project and then open your typelibrary. For some reason this allows the type library to be saved.
If your type library is used by an application or COM+ ensure that application is shut down or COM+ disabled before opening the type library. Any open apps will prevent the type library from being saved.
However I think your best solution is probably an upgrade. You get Unicode support too.
Using Delphi 2009 has greatly taken much of the pain out of huge TLB files, and conversion of our existing objects was painless, but our com objects don't use any third party libraries.
We will be migrating our gui applications over once the library vendors release supported versions.
Same experience with the TLB interface here: we simply stopped using it.
We work with several separate IDL files (hand-build) for different parts of our framework, making use of the #include construct to include them into the IDL of the actual application, then generate the single tlb using MIDL and tlibimp it. If the application has no IDL of it's own, pre-compiled version of the different framework TLB files are available.
Whenever the framework enters a new version, a script is run to re-generate the GUIDS on all necessary interfaces in the IDL files.
This has served us well for many years, and for us to move over the new Delphi 2009 IDL/TLB toolset will have to be not only integrated into the IDE, but also versatile when it comes to automated builds and whatnot. Can't wait to get my hands dirty with some experiments!