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

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)

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

> {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

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)

> 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 :(

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?

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)

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)

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

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)

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!!!!

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

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)

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

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

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)

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.

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)

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.]

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)

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.

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)

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