I am trying to migrate my own projects to delphi 2010. But it seems to be very difficult.
I use TntControls for old projects. If I remove this library, some runtime functions must be re-implemented by myself. For instance: convert UnicodeString to a specified code page.
The "SizeOf", "Length", FillChar() still confuse me. Compiler will throw a warning, if SizeOf() should be replaced with Length(). But I have not found any idiot-safe tutorials for me.
A confusing warning, when trying to cast an AnsiString to UnicodeString. This conversation won't cause a data lose, will it?
Many code (zip, string utils, etc.) must be retested.
Too many headaches... Can someone share experience on migrating existing project from a very old delphi to delphi 2010?
conversion Unicode string to specified code page with only Delphi: Simpler than ever. Thanks to the String class ability to create a string of a desired codepage, and convert cleanly from one codepage to another.
FillChar is bytes, not characters, name is now unfortunate. Not that confusing really.
That warning is there to make you think, which it did. Job done.
Oh yes. But that retesting and re-reading has been the biggest benefit for me.
I have migrated all my projects to Delphi 2009/2010 and found the benefits included:
A. a thorough re-reading of my code brought many ways I needed to clean it up (because it's a bloated old mass of accidents and incremental code-sludge, like most RAD/delphi projects end up), few of which are purely unicode or port related, but all of which made the products better for being forced through the changes.
B. a cleaner world, with fewer third-party components. Dropping TNT, and a dozen or two third party components will make your project smaller, more orthogonal and easier to support.
C. There's no reason in porting to make it one way. None of my project ports are actually "moved" permanently into Delphi 2009/2010. They all build in both worlds just fine. I use the type UnicodeString widely in all my code wherever I need it, and I make a typedef to WideString, when compiling on Delphi 2007 or older versions.
D. The delphi 2010 ide works great on Windows Vista and Windows 7, and the language is a joy to work with. Delphi 2009 and 2010 don't crash, which Delphi 2007 and Delphi 7 often do for me.
If you don't need to support Vista and Win7, and you're 100% happy and glitch-free running TNT components, and your app doesn't make you money, then leave it where it is. If it makes you money, invest your time, and you will soon see the rewards. Delphi 2010 and 2009 are easily the best delphi versions ever, and the only major headache that remains is that the documentation has remained below the quality of Delphi 7 ever since they moved off WinHelp format help files.
If you're using Tnt and you're converting between code pages already, then yes, switching to Delphi 2010 will cause you extra work because you'll need to remove code for things that Delphi now handles intrinsically. Ultimately, your code will be simpler, but it will be a hassle to get it there in the meantime.
SizeOf, Length, and FillChar are very basic concepts that you, as a professional software developer, owe to yourself to understand. Be cognizant of whether you're dealing with character data or non-character data, and when dealing with the latter, don't use character-related types. You've got TBytes; use it. Don't use strings as byte buffers. When you want to know how many bytes you have, use SizeOf; when you want to know how many "things" you have, use Length. Generally avoid FillChar; you probably don't need it as much as you use it today anyway. Since the "char" that things are filled with is almost always zero anyway, you might consider using ZeroMemory instead. It has fewer parameters and is just as fast as FillChar, especially since Delphi supports function inlining.
The compiler warns you when converting from AnsiString to UnicodeString because it's not a simple string assignment but rather a conversion, guaranteed to allocate more memory and copy everything one character at a time. It's a performance warning, not a data-loss warning. Conversions in the opposite direction are both (even when assigning to Utf8String, which technically will never lose data from a UnicodeString, if it's filled only with valid Unicode characters). The best way to avoid the warning is to not use AnsiString in the first place. Use plain old String except for code that really does need to know what code page to encode things as.
I don't think the "retest" argument is very strong. The library code especially should have unit tests that you've been running every time you recompiled. Retesting is something you do several times a day; there's no special effort involved unless something goes wrong.
Related
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.
I have an old application running BDE under Delphi 7, and have now bought Delphi XE. I see a lot of people say the main problem migrating the code is changing to unicode. And possibly a database supporting unicode.
But, do I really have to do this? Can I not just stick to BDE and some "good old string format"?
I am hoping to get away with a quick swap to Delphi Xe here, not necesarily using all new features etc etc....
Rgds PM
The data fields that connect your data to the database didn't change. A TStringField still has a Value property of type AnsiString, which matches the old behaviour.
When you inspect all the warnings the compiler will spit out, you might come away with little effort and keep the BDE alive.
Besides that I suggest replacing the BDE with a more recent solution in the foreseeable future - not only because of Unicode.
It's pretty hard to avoid using the new UnicodeString which is what string is now aliased to. You can write all your code with AnsiString if you wish, but why bother? As soon as you use any non-trivial library (e.g. RTL, VCL, third-party) you are swimming against the tide. If you do attempt to continue with AnsiString you'll actually make life more difficult for yourself in my view.
If you give it a go you should find that it's not that big a job to move to the new Unicode string type. The vast majority of existing code will work unchanged.
I made the same move from D7 to XE and the change was a killer. My app, like yours includes a database - in my case its Interbase and the Interbase Express components that are part of Delphi. I made the choice to move to Unicode, but it wasn't pretty.
I read the papers, but compared to my experience they seemed incomplete or maybe even incorrect on some points. I think the papers are written from the point of view of a Delphi application with no database. I believe there were critical errors in Interbase Express (Delphi) and in Interbase. I think at least one bug has been fixed in IB and a couple in Delphi - if you move to the XE version. (I don't want to consider going through that again right now).
I wound up adding fixer-uppers in my code to help Delphi out. On the newsgroups and in QC people told me I didn't understand. Well finally, there are changes coming that fix those problems so there must really be issues there someplace.
The conflicting views expressed in this thread indicate the confusion with Unicode. On some of those issues I don't know how it would work, even having gone through it. But, I have doubts about getting through it at all and holding onto the BDE. That could well have built-in issues that will not be fixed, and which you can't deal with. There are some entries in QC you can check to see some of the outstanding issues.
When my application was in D7 my IB database was ansi. When first converted to Delpi XE, it seemed to run ok - although that was only a brief check. IB supports Unicode and I converted my data there. Would you / could you do that with your data? Only after that did I find the problems. I think any meaningful conversion to Unicode means you first convert your data storage to Unicode, then your Delphi app.
So after all that, why are you moving to XE if you don't want unicode? Is it just to upgrade or is there something you are trying to accomplish? I hope this long post helps.
We also have many applications running BDE with Delphi-7 and are considering the jump to DelphiXE. The jump is not nice...if you want your program to run in Windows7 64 bit, you will need to convert the BDE or download BDE express or another tool. BDE has memory leak issues so we have converted those components, but will remain in Delphi-7 for older products and use Delphi XE for new projects.
Good Luck.
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.
Which tool/approach would you suggest to convert of a large 16bit Windows GUI application, written in old Borland Pascal 7 / OWL, to Delphi?
Understanding the pretty heavy differences between OWL and VCL, as well as the differences between the pointer manipulations in 16bit pascal and the state-of-art using of strings and objects in Delphi - are there any ways/tools which could help to avoid almost complete rewrite of the application?
I think you need to determine;
a) how much of the code is to do with business logic, data(base) manipulation and things like proprietary file structures, mathematical processing etc? This is stuff that might lift largely 'as-is' because it's more likely to be written in 'pascal' with much smaller, obvious elements of OWL/BP7. For instance, when I did this with an application I had a series of units that dealt with loading/saving proprietary files, stuff to calculate easter, stuff to do maths on arrays etc - all of this stuff went from BP7 to Delphi (1) with almost no changes.
b) how much of the code is to do with the GUI (and nothing else) - message loop handlers, dialog element constructors, properities of controls etc. This stuff will take a lot of work to port to Delphi and unless you can find someone with a nice line in .RES->.DFM (or similar), I think you'll be looking at building this bit from scratch. No bad thing because if it's a 16bit Windows app then you'll probably want to take the opportunity to at least make it look a bit more 'modern' anyway. I think this will be the most labour-intensive part of the project.
c) how much of the code is using stuff that you know can be done differently in Delphi, but that would work as it stands in pascal right now? This is where #BloodySmartie's point about migrating to an older version of Delphi makes sense to me. You ought to be able to port that project to something like Delphi 5/7 making obvious (and well-understood) changes to things like string manipulation. The more of this stuff that you can leave unported, the better in my view. Get something that runs and that you check basic behaviour with, and then embark on a process of refactoring/refining to make the most of Delphi as and when the resources allow it. You might have (as I did) arrays of pointers in BP7, where each pointer goes to an array of pointers which ultimately lead to an object - this was how we got around memory limitations in the 16bit Windows world. When I first ported my app, these arrays of pointers to arrays of pointers still worked fine in Delphi and I left them alone until I had the time to do something more 'Delphi-like' with the structures.
But before you do all of that - why are you porting the app? If you're porting it because you're about to make a reasonable number of changes to the app's functionality anyway, then it might really be the right time to rewrite the app. As you're rewriting in Delphi, you are still going to be able to use chunks of functions and procedures that are business-rule based anyway, so it's not necessarily a complete and total rewrite from scratch.
I guess there is no tool to support your migration but i'd try to start in an old Delphi Version like 1,2 or 3. This syntax should be much nearer on BP7 than the syntax of newer Delphi Versions.
At this time, you should first try to just bring your app logic to delphi, without any visual stuff. Then use the form designer to rebuild your GUI.
A important point you should pay attention to is that a DOS string is an ASCII-String, while the Delphi strings up to Delphi 2007 are ANSI-encoded. In Delphi 2009, the string keyword describes a unicode string.
Long-long time ago when I swapped OWL to VCL (in C++) it was just easier to write everything from scratch. There might be some code parts that don't deal with user interface and string manipulations, but otherwise it's totaly different.
In fact one of my biggest app is still in OWL, because I just don't bother to rewrite it. As long as it works, let it be.
we also had - and still have - tons of owl-applications.
so we did port the 16bit owl to 32bit owl and are therefor still developing and maintaining our owl-based applications (actually with Delphi 2007 for win32).
you may find this way easier and faster than switch to vcl.
cheers
Andrej
FrameworkPascal.com provides an effective solution with minimal changes to the original windows 3.1 code. We did it for a while but now we provide a rounded solution with 32 bit compatible OWL units. We also provide with it ODBC SQL units, MAC address based security technology and special units CRT like units which can handle code written for DOS text and graphic modes mode, mixed, with and new 32 bit graphics and targeted at Windows 32/64 GUI applications. Legacy code can be which can be compiled with OWL Windows MDI starting with model applications demos which can be quickly modified.
Here's one from the "No question's too dumb" department:
Well, as the subject says: Is there an impact? If so, how much? Will all the string literals I have in my code and in my DFM resources now take up twice as much space inside the compiled binaries? What about runtime memory usage of compiled applications? Will all the string variables now take up twice as much RAM? Should I even bother?
I remember something like this being asked during one of the early pre-release webcasts but I can't remember the answer. And as the trial is only 14 days I'm not going to just try it myself before the third-party libraries I need have been updated (supposedly in about a month).
D2009 uses UTF-16 for the default string type, although you can make variables UTF-8 if you need to.
Jan Goyvaerts discusses the size/speed tradeoff in a good blog post.
String literals in DFMs have been UTF-8 since at least D7. Hence, there will be no increase in size due to strings in DFMs with D2009.
I have now finally gotten my hands on Delphi 2009 and after making the necessary adjustments my project now compiles and runs just fine. :)
To get results quickly I initially had to comment out one slightly more complex module of the app so it's not 100% comparable yet but it already seems safe enough to predict that despite a significant amount of string literals in our source code (excessive debug log messages) the size of the binary compiled with Delphi 2009 will probably be roughly the same as before - if not actually less!
I wonder, does the Delphi compiler actually perform any kind of compression on the binaries or at least its resource sections in any way? I really would have expected the change to UTF-16 string literals to have a bigger impact in this particular app. Are the literals really stored as (uncompressed) UTF-16 inside the binary?
I haven't had time to investigate differences in the memory footprint yet.
EDIT: Not directly Unicode-related but definitely related: Andreas Hausladen recently posted an interesting bit about the (significant) impact of the {$STRINGCHECKS} compiler option (BTW: turned on by default) on compiled executable size: http://andy.jgknet.de/blog/?p=487
I have been waiting for an Unicode VCL for too many years, finally we see it. I don't think most applications need to worry about the size issues as they don't have that many string literals anyway or store massive amounts of data in-memory.
Usability issues are more weighted to justify Unicode use as much as possible.
If some developer wants to create a tiny exes, they can hand optimize using AnsiString (if i18n is not an issue).
I haven't used Delphi in years, but it probably depends on what Unicode encoding they use. UTF8 will be exactly the same for the regular ASCII character set (it only uses more than one byte when you get into the exotic characters). UTF16 might be a bit bloated.