Related
I have an old Delphi application and i want to migrate it to the newest Delphi version. The problem is that the application is huge and migrating whole app at once would be too complex. I wonder what is the best approach to do this... Maybe form by form, placing a form into a dll and then using older forms in the new Delphi app and replacing them one by one (after clients confirm one form is working ok to continue with the next one). Not sure if this would be possible at all...Any other ideas?
I presume that based on your comments you do not have comprehensive test cases. In that case, you are simply in a world of pain, and there is nothing that will truly mitigate that. Without test cases, any approach you take will generate errors and bugs that will take you quite a while to catch them all. Build that into your expectations. In fact, with those as your expectations then you need to schedule a large testing phase and maybe that is a good approach. Upgrade all at once and test over the course of a few months.
You could first identify all 3rd party components that will eventually be needed and upgrade them to the latest version one at a time. That way you can at least identify bugs in a controlled manner per 3rd party component. Again, since you are relying on manual testing, this also will be error prone, but maybe you can focus on areas that use the upgraded component preferentially.
here my advice.
Before you start migrate, do a refactoring of your existing source-base.
1.) Remove un-used stuff.
2.) Try to move as much as possible to standard delphi components.
3.) Remove "un-used" units from your uses-statements.
4.) If needed, try to do some layering (App-UI,App-Logik,DB-Layer,Libraries)
5.) Look for 3rd-Party Components/Libraries, which might be not needed anymore in the latest Delphi Version, because the functionallity is now included in Delphi. If you spot such components/libraries, try to encapsulate them.
Now you have a new version of your software (still in the old delphi). Test it as exact as possible (Unit-Tests would be perfect).
If this is done, then you start to migrate to newer Delphi. I recommend to do it in one go (instead of dll and one by one).
I do not think there is enough information presented to give you specific advice.
My answer would be to bring in knowledgeable experts to look at your code, talk to your staff, look over your documentation and tests, and then present you with smart options. This can likely all be done via Zoom/Skype online. If you think about how much money you are going to end up spending on the conversion, and how much money you will spend on fixing problems because you went off in the wrong direction (and how many customers you could lose due to bugs/performance issues) this would be an extremely cheap investment.
There are a number of firms with Delphi experience that could help you. (I do not work for one and this is not an ad.) There are some well-known Delphi consultants that would likely have some free, or small flat-fee type, initial conversation.
If you are using a version before the Unicode switch in Delphi 2009, there are a number of online resources to assist. Delphi Conversion Unicode Issues
If you want some real-time advice and chatting about specific issues, check out a Telegram server dedicated to Delphi programming with nearly 800 members. There are nearly always some Delphi experts online answering questions. https://t.me/delphidevelopers You should be able to get some consultancy contacts from that server.
Our company have a software that has been in development for over 10 years, so there are some really dated stuff in there. It's still quite functional and everything, but I see the new features on Delphi XE and it makes me want to switch. Problem is that the source code itself is over 300mb of .pas files (1gb total with components, etc).
We're using custom components, old jvcl stuff and the latest devexpress.
How hard can I expect things to be if I decide to migrate from Delphi 7 to Delphi XE?
Thank you.
The only real problem is conversion to Unicode. You should learn how Unicode support is implemented in Delphi - start from Marco Cantu White Paper: Delphi and Unicode
It is impossible to estimate the amount of work required to upgrade old applications to Unicode without knowing the actual code. If you were using string types in the standard way, the conversion would be easy. Any low-level tricks with string types (like storing binary data in strings) are now deprecated and the correspondent code should be rewritten.
Some small tools either migrate without needing to do any modifications, or just a couple of unicode fixes to get it to run.
However, if your codebase is as huge as you're explaining, you shouldn't completely rely on what anyone here is going to tell you. Just get a copy of XE and load the code. See what problems you run into to get a feel for the amount of effort it's going to take.
At this moment I've ported all of my code to XE (even old projects). I re-use the same libraries as much as possible, so once I've converted most of those, "porting" applications from Delphi 7 to Unicode Delphi's was usually merely a repetitive task to either deal with updated interfaces in the libraries, or to fix compiler errors and warnings.
Most common errors that I've encountered:
Unicode stuff. This will take 90% of the time. It's annoying if the code does a lot of low-level string handling, but most of the problems can easily be fixed by adding some typecasts.
the compiler bitches when you use c in ['a'..'z']. You're supposed to use CharInSet() for unicode strings.
If you set ShortDateFormat, you'll get a compiler warning that you should use FormatSettings.ShortDateFormat instead. In new code that's a good idea. If you're porting, just ignore it initially if you just want to get going.
Additionally, you'll probably upgrade your third party libraries to newer versions, so that you don't have to port those yourself. It's not uncommon for those to have changed their interfaces or workings, so i'd download some trial versions of those to see what has been changed.
You mentioned SQL in one of your response comments... Does your database support unicode? If not, you could be in for a lot of work. You may need to convert databases on-the-fly or make a conversion tool for your users. You may need to upgrade the database or even switch to something else. For example, DBISAM is not unicode capable, but the vendor makes ElevateDB which is. The transition is not trivial. And some other libraries like Hyperstring, written largely in assembler, are another sore spot.
I've been doing quite a few of those conversions.
You should prepare by making your current code base testable. Preferably using automated unit tests, but at least have a good end-user testing plan.
Then you should plan for the biggest portion: the Unicode conversion for both your app and your database.
Finally there are less major, but potentially very time consuming aspects:
if you are using BDE, this is the time to get rid of it
the Delphi XE is more strict than Delphi 7
3rd party library versions that bump up quite a few versions and are usually far less backward compatible than the VCL is
When you have ported it, it is time to change things: since you have seen the whole code base, now you know where your weak points are, so you can start refactoring them and get a better app than you had before.
My project is about a million lines of code and I recently ported from CB9 to XE. To cut down on the amount of work I first rewrote a lot so I was no longer dependant on 3rd party component packs, then carefully went over everything string related (unicode) and only then moved to XE. The preparation was a lot of work, the actual port was relatively easy.
It is definitely a challenge for this MIGRATION to be executed. But need good PLANNING!
We first need to find all the possible components which also needs to be migrated along with the Code. If there are 3rd party components used in Delphi7 project which are not available then its quite complicated to get further on.
Secondly, the other type conversion related to Unicode, which is quite easy.
And finally ofcourse we need to get other supporting libraries, BDE, and Database Adapaters in place.
For Rich User Interface, Delphi FireMonkey can be used.
Delphi is getting better and better as it has now support from Desktop to Web to Mobiles application development.
Our company have a software that has been in development for over 10 years, so there are some really dated stuff in there. It's still quite functional and everything, but I see the new features on Delphi XE and it makes me want to switch. Problem is that the source code itself is over 300mb of .pas files (1gb total with components, etc).
We're using custom components, old jvcl stuff and the latest devexpress.
How hard can I expect things to be if I decide to migrate from Delphi 7 to Delphi XE?
Thank you.
The only real problem is conversion to Unicode. You should learn how Unicode support is implemented in Delphi - start from Marco Cantu White Paper: Delphi and Unicode
It is impossible to estimate the amount of work required to upgrade old applications to Unicode without knowing the actual code. If you were using string types in the standard way, the conversion would be easy. Any low-level tricks with string types (like storing binary data in strings) are now deprecated and the correspondent code should be rewritten.
Some small tools either migrate without needing to do any modifications, or just a couple of unicode fixes to get it to run.
However, if your codebase is as huge as you're explaining, you shouldn't completely rely on what anyone here is going to tell you. Just get a copy of XE and load the code. See what problems you run into to get a feel for the amount of effort it's going to take.
At this moment I've ported all of my code to XE (even old projects). I re-use the same libraries as much as possible, so once I've converted most of those, "porting" applications from Delphi 7 to Unicode Delphi's was usually merely a repetitive task to either deal with updated interfaces in the libraries, or to fix compiler errors and warnings.
Most common errors that I've encountered:
Unicode stuff. This will take 90% of the time. It's annoying if the code does a lot of low-level string handling, but most of the problems can easily be fixed by adding some typecasts.
the compiler bitches when you use c in ['a'..'z']. You're supposed to use CharInSet() for unicode strings.
If you set ShortDateFormat, you'll get a compiler warning that you should use FormatSettings.ShortDateFormat instead. In new code that's a good idea. If you're porting, just ignore it initially if you just want to get going.
Additionally, you'll probably upgrade your third party libraries to newer versions, so that you don't have to port those yourself. It's not uncommon for those to have changed their interfaces or workings, so i'd download some trial versions of those to see what has been changed.
You mentioned SQL in one of your response comments... Does your database support unicode? If not, you could be in for a lot of work. You may need to convert databases on-the-fly or make a conversion tool for your users. You may need to upgrade the database or even switch to something else. For example, DBISAM is not unicode capable, but the vendor makes ElevateDB which is. The transition is not trivial. And some other libraries like Hyperstring, written largely in assembler, are another sore spot.
I've been doing quite a few of those conversions.
You should prepare by making your current code base testable. Preferably using automated unit tests, but at least have a good end-user testing plan.
Then you should plan for the biggest portion: the Unicode conversion for both your app and your database.
Finally there are less major, but potentially very time consuming aspects:
if you are using BDE, this is the time to get rid of it
the Delphi XE is more strict than Delphi 7
3rd party library versions that bump up quite a few versions and are usually far less backward compatible than the VCL is
When you have ported it, it is time to change things: since you have seen the whole code base, now you know where your weak points are, so you can start refactoring them and get a better app than you had before.
My project is about a million lines of code and I recently ported from CB9 to XE. To cut down on the amount of work I first rewrote a lot so I was no longer dependant on 3rd party component packs, then carefully went over everything string related (unicode) and only then moved to XE. The preparation was a lot of work, the actual port was relatively easy.
It is definitely a challenge for this MIGRATION to be executed. But need good PLANNING!
We first need to find all the possible components which also needs to be migrated along with the Code. If there are 3rd party components used in Delphi7 project which are not available then its quite complicated to get further on.
Secondly, the other type conversion related to Unicode, which is quite easy.
And finally ofcourse we need to get other supporting libraries, BDE, and Database Adapaters in place.
For Rich User Interface, Delphi FireMonkey can be used.
Delphi is getting better and better as it has now support from Desktop to Web to Mobiles application development.
We have a medium-to-large size application. One version runs on Delphi 6 and another one on Delphi 2006.
One argument would be support for Unicode. We need that to cater to Customers around the world.
Other things I have read about are: better IDE (stability, speed), better Help and some cool additions to the language (e.g.: generics)
What about third-party components? We use DevExpress, DBISAM and many others. Are these already ported?
Touch/Gestures sound cool, but we have no use for that in our application.
Better theme support (eg., TStringGrid/TDBGrid now support themes).
Support for Windows Vista and Windows 7, including support for the Direct2D Canvas in Win7 and the Touch/Gesture support you mentioned.
Improved refactoring, including support for refactoring generics.
Built-in source code formatter.
IDE Insight allows you to find things in the IDE itself.
Enhanced RTTI.
Improvements in the debugger, including new custom data visualizers and the ability to create your own. There are two included with source (one for TDateTime and one for TStringList). Also better support for debugging threads, including the ability to name threads for debugging and set breakpoints on specific threads.
The ability to add version control support to the IDE via interfaces. This will allow version control developers to add support directly in the IDE itself.
The help is much better than in previous versions. It's been completely redesigned again, and is much more comprehensive and complete. There's also an online wiki-based version (used to generate the help itself) that you can add or edit.
Background compilation allows you to continue working while you're compiling your project.
As far as third party controls, that's up to the specific vendor; you'll have to check to see if Delphi 2010 versions are available for each of them individually. (You might check the Embarcadero web site, though, to see if they have a list already available; I seem to recall hearing of one... Ah, yes. Here it is. )
Last upgrade for old version
With old version of Delphi (before Delphi 2005), you have only before january 1 2010 to upgrade.
After you will have to buy a full version.
Productivity
http://www.tmssoftware.com/site/blog.asp?post=127
Purely as a reactive measure. Lets say that there is a new feature in the latest version of a yet to be released operating system. Lets say that this feature breaks certain features inside your application. IF there was to be a global fix for it, it would most likely not be placed in older versions of the compiler, but the newer versions which "officially" support the new operating system. The largest problem about waiting too long is that when such a measure is needed its generally at the zero hour when sales are at risk.
Upgrade NOW, and help prepare your application to be more reactive to future changes.
Don't convince him for a Delphi 2009/2010 upgrade, Do it for a Software Assurance.
The refactoring tools and overall
speed and stability of the IDE will
make the development team more
productive.
Working with the latest tools will make it easier to recruit top talent.
The IDE is definitely a step up from Delphi 6 and/or Delphi 2006.
If Unicode is important to your customers then Delphi 2009/2010 is a clear option. But if Unicode is important to you, rather than your customers, then I'd be careful.
Unicode is not "free". If your users/customers have concerns w.r.t memory footprint and/or performance, and/or your application involves extensive string handling, then Unicode exacts a price that all your customers will have to pay, and for customers who are not themselves concerned with Unicode support, that price comes with zero benefit (to them).
Similarly if your application sits on top of a currently non-Unicode enabled database schema. Migrating existing databases from non-Unicode to Unicode is non-trivial, and if you have customers with large production databases, incurring downtime for those customers whilst they migrate their data stores is something you should consider carefully.
Also you will need to be very aware of any interfaces to external systems - your code will unilaterally "go Unicode", and that may adversely impact on external interfaces to other systems that are not.
In such cases you would do well to tie the transition to Unicode with other compelling feature improvements and benefits to make the transition compelling for other reasons.
Also, if you genuinely have customers with a real need for true Unicode, then the transition is not as simple as recompiling with the latest/greatest compiler and VCL. True Unicode support will involve a great deal more work in your application code than you might at first appreciate.
Of course, having a Unicode capable compiler/VCL is a crucial component, but it's not an answer on it's own.
The Unicode change has a significant impact on 3rd party components. Even if you have the source to your 3rd party code you may find yourself facing Unicode issues in that code unless the vendor has taken steps to update that code in a more current version. Most current vendor libraries are Unicode by now though I think, so unless you are using a library that is no longer supported by the vendor, you should be OK on that score.
I would also exercise caution when it comes to those "cool" language features such as generics. They sure do look cool, but they have some seriously limiting characteristics that you will run into outside of feature demonstrations and can result in maintenance and debugging difficulties as the experience of the community in working with them is limited, so "best practice" has yet to emerge and the tool support perhaps hasn't yet caught up with the uses to which those features are being put in actual code.
Having said ALL that.... Since you cannot realistically choose any version other than Delphi 2010 to upgrade to, then if you are going to upgrade at all then you have to bite the Unicode bullet and will find yourself presented with lots of tempting language features to tinker with and distract you. ;)
And now that Embarcadero are imposing a more draconian policy w.r.t qualifying upgrade products, you will have to get off of Delphi 2006 if you wish to qualify for upgrade pricing for Delphi 20*11* onward, whether you decide that 2010 is right for you or not, otherwise when the time comes to upgrade to Delphi 2011 you will find yourself treated as a new customer, and if you thought that upgrade pricing was steep, check out the new user license costs!
D2006 was an awful version of Delphi. It's worth upgrading just to be rid of all the memory leaks and random IDE crashes and glitches. Justify it to the boss as a massive decrease in lost productivity. That means less money wasted paying you to not produce code because your dev tools aren't working. It'll pay for itself very quickly on that basis alone.
As for D6 vs. D2010, that's a feature argument. Start with Skamradt's response, that it helps your code be future-proof. Underscore it with OS compatibility. D2007 was the first version that understands Vista. D2010 is the first version to understand Windows 7. If you're compiling with any older version, your app is obsolete before you even deploy it because there's no guarantee it's compatible with modern versions of Windows.
Then you've got actual language features. The main improvements IMO from 2006 to 2010 are Generics, which helps out with all sorts of repetitive tasks, and extended RTTI. Robert Love has been doing some great blog posts lately on how the extended RTTI can simplify common real-world problems. (Plus Unicode, of course.)
Playing the devils advocate, there may be reasons not to upgrade. For instance you might be missing the source to certain components or you may still need to support Win9X.
I think you'll probably find the best reason to upgrade (leaving all the new wizz-bang features aside) is that you'll be significantly more productive in the new IDE. If you don't / can't upgrade I'd recommend grabbing a copy of Castalia, which can give you access to many productivity enhancements (e.g. refactoring) in Delphi 6.
DBISAM is updated, I just emailed them this past week concerning a project I hope to be upgrading from Delphi 3 to Delphi 2010.
All the other packages I looked into upgrading for that project (WPTools, Infopower, TMS) all state on their websites that they offer compatibility with 2010.
I never had D2006 (I have 2007) so I can't speak to any defects in that particular release (D2007 isn't that great, either) but it's generally a good principal to keep your tools in good shape. For a saw that means sharp, for software that means current. Especially in a new-OS year, you probably want the corresponding version of your primary development environment.
It seems to me there are 2 aspects in developing professional applications:
You want to earn money: you have to stick to your customer's demands, keep your stuff KISS, maintainable and so on... You have to be productive: no matter of generics, RTTI, widgets like flowpannel, gesture and so on because it takes time to learn and more time to use. In this way, change from D7 to D2010 is not nessary relevant. Change for another IDE like REAL Basic allowing multiplaform target is more accurate.
BUT as a developer there is a child and a poet in you, fascinated by new technologies or/and algorithms... This is the creative part of the job. You got to be creative if you want to be impressive and innovator. Upgrade to Delphi 2010 is a must have, searching for new classes, new objects is a way of life in today's programming.
That's my humble point of view and the reason that keep me spend my money to upgrade Delphi from I to 2010.
Best regards,
Didier
Lists of compatible components that already support Delphi 2010 including DevExpress (article will be periodically updated from our technology partner database) is at
http://edn.embarcadero.com/article/39864
Argument - tens of thousands of tools and components available for the things you might need in addition to the open api(s) for components and the IDE.
Item 9 of the The Joel Test: 12 Steps to Better Code is:
Do you use the best tools money can buy?
Perhaps this argument is germane here.
On the other hand if you are maintaining legacy code and not generating anything that has dependency on new OS or tool features, it is a hard argument to win. I would not however recommend generating entirely new projects on tools that old.
Unicode has been supported on Windows since at least NT 4.0, and for Windows 95/98/Me since the addition of MSLU in 2001 - so surely Delphi 2006 supports it!? [edit]Not fully supported in the component library it seems.[/edit]
I suggest that the one compelling argument is in order to ensure Vista and Windows 7 compatibility. I understand that 64bit target support was planned for Delphi this year. That may be another argument; but again it only applies if you actually intend to target such a platform, and in a way that will give a tangible benefit over 32bit code. [edit]I emphasised planned because I did no know whether it had made it into the product, but that it might be a consideration for you. It seems it has not, so the argument you put to management might be even less strong.[/edit]
Management are not going to be impressed by the "I just want cool tools to play with", you have to approach it on a "Return on Investment" (ROI) basis. Will you get your product out faster or cheaper using this tool? Are the existing tools a technical barrier to progress? Conversely, consider whether spending time porting your legacy code to new tools (with the associated validation and testing) will kill your budgets and deadlines for no commercial advantage?
I'm interested in finding something out. In Delphi the default since the begining when buying components has been to be able to purchase them with source (even if it might be a slightly more expensive option). This made sense in Delphi for a number of reasons, firstly Borland led the way by providing the full source of the VCL with every install of Delphi, but also having the source was considered essential since when you upgraded Delphi you had to recompile and sometimes Authors went out of business.
I'm interested in finding out whether any Delphi component writers out there have ever had reason to regret selling their component 'with source'? Has someone tried to release a competing product based on your code, or passed it off as their own?
The reason I ask is because it still seems to be the exception rather than the norm to provide a 'with source' option when purchasing an ActiveX control or a .NET assembly. Maybe a reassurance that people don't want the source for nefarious purposes might convince more component writers to allow source code to be purchased along with the component.
I have personal experience with this. I used to sell a component and function library for Delphi (Clipper Functions for Delphi, AKA CFD); we went from version 1 in '96 to version 5 in 2000 when I took a job that wouldn't allow moonlighting. We had 5000+ registered users at the end; I still provide quite a few of them with free updates and occasional bug fixes.
I never had any reason whatsoever for not making source available. In fact, there was no option to purchase CFD without source. I wouldn't buy any commercial Delphi component library that my app would depend on without source, for the very reasons you cite (recompiling with new Delphi releases and vendors going away).
Unless the component writer is using some form of obfuscation the source for any .Net assembly can be obtained by using reflector.
I've used this on assemblies from Microsoft as well as other vendors to track down problems in their code. In some cases I went ahead and patched the problem and recompiled it; but do that at your own peril.
For all Delphi components which I developed over the past 10 years, full source code was always included. It would however be a big advantage to have a compatible binary (DCU) format (similar to Java and .NET) in Delphi for trial versions, or for low cost 'personal editions' - versions which do not attract the real commercial developers, because of the missing source code. Compiling DCUs for Delphi 5,6,7,2006, 2007 and 2009 is possible (if the Delphi licenses are there), but managing so many different code versions requires a lot of work for automatic build and packaging systems ...
I have an issue especially with .Net skinning libraries. I have found none good enough that would include the code for a fairly economic price. I'm talking about prices that go over the $1000USD price line, which I think it´s astronomic for a freelance developer, for just a piece of software. But, those things that are harder to implement in each language are the most expensive as well, so there is a relation between those two factores in the difficulty of implementing something similar your self. I know this is no answer for your question, but my own view of things.
I don't have personal experience with this, but I do know that source code watermarking is available and some vendors have used it. Not sure how successful it would be.
I have never heard news of anyone releasing a competing product with source code from another commercial vendor. It does however happen frequently with open source ones though.