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
Related
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.
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 write a lot of components and libraries for Delphi, most of which require the use of BPL Packaging so that they may be installed into the IDE.
This is simple enough and works well, right up until you want to maintain a single set of Package Project Files (in a single Project Group), but also want to compile and distribute those same packages for different Delphi versions.
Up to now I've been creating a different Package Project for each version of Delphi, and explicitly defining a Delphi Version Identifier as a suffix (e.g. Kinect_XE.bpl and Kinect_XE2.bpl).
I am aware that, in the Project Options for a Package Project, under Description, there are the fields LIB prefix and (more importantly for my needs) LIB suffix.
I am further aware that if I place a value in LIB suffix, it'll be appended to the end of the compiled BPL's filename.
My question, however, is first whether it is possible to have the IDE automatically populate the LIB suffix field with the IDE/RTL Version number, and if so... how?
I'm fairly certain this is possible, as it would appear that vcl120.bpl (and its counterparts for each respective version of Delphi) can be Referenced (as requirements) of your own packages using just vcl rather than having to type the full vcl120. It is, in fact, this same behaviour I'm hoping to achieve... where my packages can intra-reference eachother (as neccessary) without having to provide version-specific references to accommodate the suffixes.
Equally important is that resolving this will enable me to maintain a single set of Project Files in a single Project Group (with the obvious exception of XE2 where its Project Files don't necessarily behave very well with previous versions of Delphi due to the Platforms addition).
I suspect that I may need to put a value like $(VER) (or something similar) in the LIB suffix field, but this appears not to work and I've scoured Google looking for the correct solution.
Hope you can help!
UPDATE 1
I am now writing an IDE plugin to be used with (in the very least) Delphi 2007 to XE2, which gives DLL and BPL projects a new option called AutoSuffix. When toggled On, any IDE with the AutoSuffix plugin installed will immediately apply the correct IDE version suffix to the project.
The AutoSuffix plugin will be made available (freely) for everyone within the next 24 hours, and this question updated accordingly.
UPDATE 2
Okay... Delphi 2007 is being a pain! I've made AutoSuffix work with 2009 to XE2, so far, but 2007 requires a little more time (patience appreciated).
UPDATE 3
It would appear as though Embarcadero have heard our collective cry for simplier package unification between versions.
Mark is going to push this through to see if future versions of Delphi can accommodate a {$LIBSUFFIX AUTO} feature. I hope to hear back very soon whether this will be the case. If so, it certainly affects the way AutoSuffix will need to work on XE2 and older versions (as presently it doesn't provide the simple AUTO switch.. it has its own method).
My hope now is that EMB will take this request seriously, provide it as an integral feature going forward, so that it becomes a simple case of using AutoSuffix on existing versions to unify the process accross all versions!
AFAIK for Delphi up to XE2 there is no automatism for doing this.
Concerning the requires clause: when you require another package you are actually using the dcp, which doesn't inherit the LIBSUFFIX. Thus it is sufficient to require VCL.dcp during compile time, while VCL160.bpl is actually used during runtime. The DCP includes the complete BPL name to resolve that.
This makes the LIBSUFFIX approach superior to the simple "rename the package for each version of Delphi" one.
A solution like that suggested in QC83229 would make it easier to port a package to a newer Delphi version, but then you are still stuck with dproj files that are not backwards compatible.
I normally use different folders for each Delphi version, where only the project files are stored. For a new Delphi version I only have to copy a folder and change the LIBSUFFIX.
LIBSUFFIX directive is in *.dpk file, and you can edit *.dpk file manually.
You can write, for example
{$IFDEF CONDITIONALEXPRESSIONS}
{$IF CompilerVersion = 20.0}
{$LIBSUFFIX '120'}
{$IFEND}
{$IF CompilerVersion = 21.0}
{$LIBSUFFIX '140'}
{$IFEND}
{$ENDIF}
The bad thing is that IDE does not respect your manual edits of *.dpk file and deletes them then you make changes in a package. That is why some component vendors that use conditional defines in *.dpk file say in installation instruction if asked to save changes say 'NO'.
My suggestion would be to add this as a configurable option to project option sets (see QC #86491.) Rather than updating all the packages it would be sufficient to update a single option set file.
In fact, it seems the DllSuffix tag is recognized by the option set files in Delphi XE/XE2. Adding <DllSuffix>160</DllSuffix> to the <PropertyGroup> section of an option set file will cause the suffix to be appended to the package in the project manager. However, you still have to open the project options and click OK in order for it to be saved to the .dpk file.
I agree that it would be extremely useful with this feature (I would think also for the packages in the RTL.)
{$LIBSUFFIX AUTO} feature was added in Delphi 10.4.1:
In previous versions (version 10.3 and earlier) of C++Builder and
Delphi developers building packages needed to manually set their
package’s library suffix setting. The DocWiki “What’s new in version
10.4.1” mentions a new IDE projects option for setting the library suffix:
“Package AUTO libsuffix: packages can now have an automatic version
suffix, instead of manually updating and specifying the right version
suffix with each new release. (The compiler quietly supported this in
10.4, but full support for the feature in the IDE and package project settings is introduced in 10.4.1.)”
Quick one I hope - I'm just about to delve into a Delphi 5 legacy app that makes calls to a DLL (also written in D5), passing a string which the DLL can modify if required.
I have the code to both the DLL and the app. Pasted right at the top of the DLL source is a remark about using ShareMem, and it needing to be the first line in the uses clause of the project etc.
If I was porting this whole thing to D2007, is there a better (or more modern) way of getting a Delphi app to share string data with a Delphi DLL? Does the D5 ShareMem stuff still apply to Delphi 2007 applications (with FastMM etc)? I haven't even had a bash at recompiling the whole thing yet - just wondered if this bit was going to be a problem and if there was an alternative/recommended way of doing this?
FWIW, the DLL is totally first party (it's only used by this particular app - so recompiling it under D2007 as well wouldn't be a problem).
To use the FastMM included with D2007, use SimpleShareMem as the 1st unit in both your application and the DLL projects.
Or download the full FastMM4 from SourceForge, set the Flags in FastMM4Options.Inc (ShareMM, ShareMMIfLibrary, AttemptToUseSharedMM) and put FastMM4 as the 1st unit in both the application and the DLL projects.
Use only a FastMM4. FastMM4 is a great memory manager and automatically includes a ShareMem like solution! FastMM4 is compatible with D5 and up!
The reason you need sharemem is that the reference counting on ansistrings breaks when passed to a dll. One solution is :-
If you are able to restrict your strings to shortstring then you can dispense with sharemem. I have written some two dozen dlls, mostly drivers for hardware and I have not had to use sharemem once.
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!