Is there any compelling reason to move (quite a large project) from Delphi 7 to Delphi 2007? Specifically, is there better Vista/Win7/Win8 integration provided by Delphi 2007? (In the project I am already using a custom manifest file for Vista/Win7 etc.. and not the std XPMan component) Does 2007 add any new bugs to the scene? Thanks Rael
![]() |
0 |
![]() |
Rael wrote: > Is there any compelling reason to move (quite a large project) from > Delphi 7 to Delphi 2007? If you are going to upgrade, why not upgrade to something newer? > In the project I am already using a custom manifest file > for Vista/Win7 etc.. and not the std XPMan component) The XPMan component is obsolete. The VCL has built-in theming support now, so you do not need to provide a custom manifest unless you need UAC/UIPI support. XE2 adds a new option to use custom manifests. -- Remy Lebeau (TeamB)
![]() |
0 |
![]() |
On 2012/12/11 10:55 PM, Remy Lebeau (TeamB) wrote: > Rael wrote: > >> Is there any compelling reason to move (quite a large project) from >> Delphi 7 to Delphi 2007? > > If you are going to upgrade, why not upgrade to something newer? Well at this point it will be a cost in terms of time and updating 3rd party components to upgrade to newer unicode versions. So that is why I am looking at if there is any advantage - perhaps better Vista/Win7 integration - in moving from D7 to D2007. -Rael
![]() |
0 |
![]() |
> {quote:title=Rael Bauer wrote:}{quote} > Is there any compelling reason to move (quite a large project) from > Delphi 7 to Delphi 2007? > > Specifically, is there better Vista/Win7/Win8 integration provided by > Delphi 2007? (In the project I am already using a custom manifest file > for Vista/Win7 etc.. and not the std XPMan component) > > Does 2007 add any new bugs to the scene? D2007 was a nice release - very stable, and we happily used it (well, RAD Studio 2007) for several years. I'm sure it has its own bugs, every release does, but in general it was great. From memory, D2007 had basic Vista support (for example, the Application property MainFormOnTaskBar) but no special Windows 7 or 8 functionality, since those version of Windows weren't released back then. On the other hand, you're upgrading from something ten years old to something five years old. *Why?!* (I only just resisted putting that in all capitals.) Why not upgrade to XE3 and get all the benefits of everything that's been added and fixed since? You will need to handle the Unicode upgrade, but you'll have to do that anyway and the latest version is an awful lots better than D2007, which is itself I agree an awful lot better than D7. You can find a list of everything new in each version of Delphi here: http://stackoverflow.com/questions/8460037/list-of-delphi-language-features-and-version-in-which-they-were-introduced-depre . Skip the answerer's summary below the links - I think they missed a lot out. Follow the links themselves to see what's been added. I suppose what I'm saying is: sure, go to 2007, it's a decent upgrade. But it's not nearly as good as you could do. Cheers, David
![]() |
0 |
![]() |
Rael Bauer wrote: > Well at this point it will be a cost in terms of time and updating > 3rd party components to upgrade to newer unicode versions. You are aware, I hope, that you will need D2007 versions of the 3rd-party components you use in this project? Unless you have them already for other projects done in D2007 you will have update costs here as well. -- Peter Below (TeamB)
![]() |
0 |
![]() |
> If you are going to upgrade, why not upgrade to something newer? hehe, because in something newer you change all the DNA by replacing 8 bits string by 16 bits strings :) you can not believe how much are still on D2007 because of this ! it's sad :(
![]() |
0 |
![]() |
On 2012/12/12 07:22 PM, Peter Below wrote: > Rael Bauer wrote: > >> Well at this point it will be a cost in terms of time and updating >> 3rd party components to upgrade to newer unicode versions. > > You are aware, I hope, that you will need D2007 versions of the > 3rd-party components you use in this project? Unless you have them > already for other projects done in D2007 you will have update costs > here as well. > My impression is that source code would not need to be modified. Only new defines (usually in .inc file) might need to be added for 2007, and a 2007 package. Is this incorrect?
![]() |
0 |
![]() |
Rael wrote: > My impression is that source code would not need to be modified. > Only new defines (usually in .inc file) might need to be added for > 2007, and a 2007 package. And who do you think uses the defines? The compiler. The package source code would have to be recompiled in D2007 in order to recognze the new defines. Packages are version-specific, you cannot use a package that was compiled in one compiler version with another compiler version (except for one specific situation - D2006 -> D2007, as D2007 was a non-breaking release that was binary-compatible with D2006 only). So every component and every package that your migrated app uses must have D2007-specific binaries for it to use. If you are using third-party packages, that means either obtaining D2007-compatible binaries from the vendors, or recompiling the source code yourself if you have it. So if you are going to go through all of that trouble anyway, then you should consider skipping D2007 and jumping to a modern version (I would recommend at least XE2, if not XE3 yet). The Unicode support has been in place for 5 major releases now and is stable. Depending on what your code is actually doing, migrating to Unicode may be as simple as a recompile with no chanes, or it may require some code review. But the effort will be worth it overall, and should not take very long (most users have successfully migrated their projects to Unicode within a few minutes/hours, if not a few days at most). -- Remy Lebeau (TeamB)
![]() |
0 |
![]() |
Rael wrote: > My impression is that source code would not need to be modified. > Only new defines (usually in .inc file) might need to be added for > 2007, and a 2007 package. And who do you think uses the defines? The compiler. The package source code would have to be recompiled in D2007 in order to recognze the new defines. Packages are version-specific, you cannot use a package that was compiled in one compiler version with another compiler version (except for one specific situation - D2006 -> D2007, as D2007 was a non-breaking release that was binary-compatible with D2006 only). So every component and every package that your migrated app uses must have D2007-specific binaries for it to use. If you are using third-party packages, that means either obtaining D2007-compatible binaries from the vendors, or recompiling the source code yourself if you have it. So if you are going to go through all of that trouble anyway, then you should consider skipping D2007 and jumping to a modern version (I would recommend at least XE2, if not XE3 yet). The Unicode support has been in place for 5 major releases now and is stable. Depending on what your code is actually doing, migrating to Unicode may be as simple as a recompile with no chanes, or it may require some code review. But the effort will be worth it overall, and should not take very long (most users have successfully migrated their projects to Unicode within a few minutes/hours, if not a few days at most). -- Remy Lebeau (TeamB)
![]() |
0 |
![]() |
Rael Disclaimer: I'm still on D2006 and liable to stay there I've seen the slightly different question "should I upgrade to Xn" asked a number of times. There seem to be two items generally quoted as the reason - Unicode, Generics. Unless you need these I'd suggest ignoring the people suggesting making the major jump. I know there are a slew of additional functions but unless you want to spend a lot of time finding them and getting used to them since you're not already using them you probably won't miss having them <g>. I moved from D6 to D2006 and since for most of my 3rd party components I have the source it was a simple recompile (adding in new IFDEFS or simply removing all the conditional defines in some cases). You certainly won't get any Vista or later features, you may have to make some alterations for those systems (eg not writing into the ProgramFiles folder). What you will have to do is get used to the different layout in the IDE. That took me a while but I hate going back to D6 now. Roy Lambert
![]() |
0 |
![]() |
Roy wrote: > I've seen the slightly different question "should I upgrade to Xn" > asked a number of times. There seem to be two items generally > quoted as the reason - Unicode, Generics. And support for newer OS APIs. > You certainly won't get any Vista or later features, you may have to > make some alterations for those systems (eg not writing into the > ProgramFiles folder). It is more involved with that, if you want to take advantage of newer OS features. If you don't upgrade, then you have to declare newer API functions/types manually, do dynamic DLL loading when appropriate if you need to maintain backwards compatibility with oolder OS versions, etc. Depending on the features you want to use, this can be a simple effort or a hugh effort. I myself still write apps in BCB 6, but they support OS versions up to Win7, including handling UAC, Taskbar enhancements, new dialogs, etc. Some of that stuff is not trivial to backport to older IDEs (TApplication.MainFormOnTaskbar, for example). -- Remy Lebeau (TeamB)
![]() |
0 |
![]() |
Remy >It is more involved with that, if you want to take advantage of newer OS >features. If you don't upgrade, then you have to declare newer API functions/types >manually, do dynamic DLL loading when appropriate if you need to maintain >backwards compatibility with oolder OS versions, etc. Depending on the features >you want to use, this can be a simple effort or a hugh effort. I myself >still write apps in BCB 6, but they support OS versions up to Win7, including >handling UAC, Taskbar enhancements, new dialogs, etc. Some of that stuff >is not trivial to backport to older IDEs (TApplication.MainFormOnTaskbar, >for example). On the basis the OP asked for features supporting the newer versions of Windows that is a very valid point. Personally I'm still trying to write good apps with decent functionality that look fairly good rather than adopt the latest Microsoft eyecandy or confuse a user system <vbg> Roy Lambert ps Having seen Windows 8 I don't think anyone should support it - including Microsoft!!!!
![]() |
0 |
![]() |
On Wed, 12 Dec 2012 16:50:24 -0800, Remy Lebeau (TeamB) <no.spam@no.spam.com> wrote: >have it. So if you are going to go through all of that trouble anyway, then >you should consider skipping D2007 and jumping to a modern version (I would >recommend at least XE2, if not XE3 yet). The Unicode support has been in >place for 5 major releases now and is stable. Depending on what your code >is actually doing, migrating to Unicode may be as simple as a recompile with >no chanes, or it may require some code review. But the effort will be worth >it overall, and should not take very long (most users have successfully migrated >their projects to Unicode within a few minutes/hours, if not a few days at >most). you only forgot to mention that one can expect slowdowns varying from marginal to significant after porting to unicode version -- Vladimir Ulchenko aka vavan
![]() |
0 |
![]() |
Vladimir wrote: > you only forgot to mention that one can expect slowdowns varying > from marginal to significant after porting to unicode version Such as? -- Remy Lebeau (TeamB)
![]() |
0 |
![]() |
On 12/13/12 1:50 PM, Roy Lambert wrote: > ps Having seen Windows 8 I don't think anyone should support it - including Microsoft!!!! > LOL! +1
![]() |
0 |
![]() |
On Fri, 14 Dec 2012 09:34:04 -0800, Remy Lebeau (TeamB) <no.spam@no.spam.com> wrote: >> you only forgot to mention that one can expect slowdowns varying >> from marginal to significant after porting to unicode version > >Such as? not sure what your question really means. I tried to remind that unicode support isn't free and usually pure ansi versions tend to work faster. some parts of libs/apps can work up to say ~10 times slower with unicode strings -- Vladimir Ulchenko aka vavan
![]() |
0 |
![]() |
Vladimir wrote: > not sure what your question really means. I am asking why you think using Unicode can lead to significantly slower code. > I tried to remind that unicode support isn't free and usually pure ansi > versions tend to work faster. In what way? > some parts of libs/apps can work up to say ~10 times slower > with unicode strings Can you provide an example? -- Remy Lebeau (TeamB)
![]() |
0 |
![]() |
Remy Lebeau (TeamB) wrote: > > not sure what your question really means. > > I am asking why you think using Unicode can lead to significantly > slower code. If the hypothetical app is extensively using indexed access to (or adding/deleting portions from) strings, then, yes, unicodifying it can result in significantly slower runtimes.
![]() |
0 |
![]() |
Adem wrote: > If the hypothetical app is extensively using indexed access to (or > adding/deleting portions from) strings, then, yes, unicodifying it can > result in significantly slower runtimes. Again, can you provide an example? Indexing a UnicodeString, appending a string to a UnicodeString, extracting a substring from a UnicodeString, deleting a substring from a UnicodeString - they are implemented the same as their AnsiString counterparts. The only difference is the memory usage is doubled, that's all. That is hardly grounds for a "significant" speed loss by itself, especially on modern computers. -- Remy Lebeau (TeamB)
![]() |
0 |
![]() |
Remy Lebeau (TeamB) wrote: > Adem wrote: > > > If the hypothetical app is extensively using indexed access to (or > > adding/deleting portions from) strings, then, yes, unicodifying it > > can result in significantly slower runtimes. > > Again, can you provide an example? Indexing a UnicodeString, > appending a string to a UnicodeString, extracting a substring from a > UnicodeString, deleting a substring from a UnicodeString - they are > implemented the same as their AnsiString counterparts. The only > difference is the memory usage is doubled, that's all. That is > hardly grounds for a "significant" speed loss by itself, especially > on modern computers. No, no; I am not referring to memory doubling. If anything, my complaint is that it's not extended enough --I'd have liked it a lot more if they quadrupled it to 4-byte size. Anyway, returning to speed issue: Well, if we consider Unicode as BMP (2-byte codepoints), yes, there's going to be no significant speed loss. But, if we move beyond BMP, then we have to deal with combining chars, surrogate pairs etc.; or when we're working with UTF8 --i.e variable byte size per codepoint. In these cases, you can't simply index-access; you have to introduce extra intelligence; and that can cause speed loss --how significant that will be dependent on how often you have to do that. But, I grant you this: If your code deals only with ANSI/ASCI/BMP, you really do not have to worry about speed. [BTW, I am sorry for not giving you a snippet --which I don't think you need one, anyway--; the secondary reason for is that my XE setup seems to be screwed ATM.]
![]() |
0 |
![]() |
Hello Adem, > Anyway, returning to speed issue: Well, if we consider Unicode as BMP > (2-byte codepoints), yes, there's going to be no significant speed > loss. > > But, if we move beyond BMP, then we have to deal with combining chars, > surrogate pairs etc.; or when we're working with UTF8 --i.e variable > byte size per codepoint. AnsiString has the same issues when dealing with MBCS charsets. Not all Ansi charsets are fixed-length, any more than Unicode encodings are. In UTF-8, some codepoints are single-codeunit values. In UTF-16, most codepoints are single-codeunit values. But when dealing with codepoints that must use multiple codeunits, AnsiString and Unicode have the same variable-length complexity. If anything, some Ansi charsets, especially those that deal in RTL encoding, are more complex than Unicode encodings. As for combining charcters, they deal primarily with display and normalization, representation inside of a Unicode string is not as much an issue, they are either surrogated or they are not. > In these cases, you can't simply index-access You can't always do that with AnsiString, either. That is why API functions like CharNext() and CharPrev() exist, even for Ansi strings. You can index directly to a specific codeunit, but if you need to do processing on codepoints instead, then you have to process and decode the codeunits first to know where the codepoints are located. AnsiString and UnicodeString are the same in that regard. -- Remy Lebeau (TeamB)
![]() |
0 |
![]() |
Remy Lebeau (TeamB) wrote: > > But, if we move beyond BMP, then we have to deal with combining > > chars, surrogate pairs etc.; or when we're working with UTF8 --i.e > > variable byte size per codepoint. > > AnsiString has the same issues when dealing with MBCS charsets. The moment you mentioned MBCS charsets, made me feel like someone who's suddenly moved from the telegraph era to smartphones --simple reason is I never had to deal with them then. So, yes, you're right, of course; it's my selective memory generalizing from my personal point of reference of my own vaguely remebered personal past when everything was more simple and harder to comprehend.
![]() |
0 |
![]() |
Adem wrote: > The moment you mentioned MBCS charsets, made me feel like someone > who's suddenly moved from the telegraph era to smartphones --simple > reason is I never had to deal with them then. Developers who don't deal with internationalization tend to not deal with MBCS (or DBCS), which are the alternatives for handling multi-byte languages, like Chinese and Japanese, when not using Unicode. -- Remy Lebeau (TeamB)
![]() |
0 |
![]() |
On Mon, 17 Dec 2012 10:07:29 -0800, Remy Lebeau (TeamB) <no.spam@no.spam.com> wrote: >I am asking why you think using Unicode can lead to significantly slower >code. not "can", it actually does in some cases >Can you provide an example? sure, for example devex libs in some circumstances display unicode text ~ 10 times slower than ansi text -- Vladimir Ulchenko aka vavan
![]() |
0 |
![]() |