Why upgrade?

[Stefan Glienke 2002]

RAD Studio itself is the best example: system enhanced is far superior to its own scaling - minus the blurry text in the code editor (which could easily be fixed by drawing on compatible bitmaps instead of DIB)

 

This is no new knowledge: https://blogs.windows.com/windowsdeveloper/2017/05/19/improving-high-dpi-experience-gdi-based-desktop-apps/

Edited February 27, 2020 by Stefan Glienke

[Lars Fosdal 1792]

From my experience, the complexity of dealing with multiple generations of breaking changes has been far more expensive in man-hours than the cost of keeping current.  Of course, that does not necessarily apply for everyone, and I can understand the cost perspective for a one-man shop - but for a corporate developer that is continuously developing internal systems, it is a no-brainer to stay current.  You get the fixes, you get the support, and since we do relatively frequent releases, we do the testing anyway.

Rio -> 10.4 will mean a lot of work on the FMX side - but on the bright side - you can finally stop having to think about two memory models when you write code for cross-platform.  That dual model has actually been a roadblock for cross-platform for us.  We did not want to spend time on that duality.

[Anders Melander 1783]

1 hour ago, Lars Fosdal said:

From my experience, the complexity of dealing with multiple generations of breaking changes has been far more expensive in man-hours than the cost of keeping current.

What breaking changes are those?

At one of my clients we upgraded all projects (many millions LOC) directly from Delphi XE & XE2 (for 64-bit) to Delphi 10.2 with no significant effort. The worst part was the tasks you'll have to do anyway every time you migrate a project from one version of Delphi to another.

If they had kept up to date all the way through, they would have had to pay maintenance on 20+ licenses to get the occasional new feature they didn't really need and they would have had to fix and work around all the new bugs they got as well.

[Lars Fosdal 1792]

The worst breaking changes were Ansi -> Unicode. Migrating a million line D5 project to XE2 was something that I would prefer not to attempt again.
Since then, there are been mostly type or constant renames, which are trivial in comparison.

Other challenges have been the deprecation of BDE and dbExpress.  Fortunately, FireDAC turned out quite well.

I agree that the transition between the "named" version has been pretty much trivial, but then again - we  usually don't migrate until the first Update pack shows up

 

Last night, four of our SQL Servers that still linger on 2008R2 refused to accept schema updates for two specific stored procedures that were using functions only found in 2012 and upwards.  The rest of our servers are 2012 and 2016/17.  That is a similar risk to your components no longer getting updates for your Delphi version since the component author drew a line in the sand and started using language features or classes that only exist in the newer Delphi versions.

[Fr0sT.Brutal 900]

IMHO there were no serious breaking changes since Unicode and x64. Moreover, correctly written code won't suffer from these changes at all.

[David Heffernan 2345]

2 hours ago, Lars Fosdal said:

From my experience, the complexity of dealing with multiple generations of breaking changes has been far more expensive in man-hours than the cost of keeping current.

This makes no sense to me. You only deal with breaking changes if you keep current. You present an either or choice that's actually a both or neither! 

[Lars Fosdal 1792]

By keeping current, you will deal with changes, one version at a time.

After the D5->XE2 experience, I very much prefer that option.

 

@Fr0sT.Brutal mentioned 64-bit. We didn't even go there yet, as the 64-bit debugger is utter and completely crap.

[dummzeuch 1505]

3 hours ago, David Heffernan said:

Nobody can made a blanket statement like 

5 hours ago, Sherlock said:

When given the option to upgrade: Upgrade.

 

Actually it's much easier to get money  from management for an update whenever it is being released than skipping a few versions and then argue that a particular release is so important that you must buy it. It's even easier with a subscription because then you don't have to argue at all, once you got the subscription. This gets worse with company size.

 

Of course that particular reason might not be valid for you or your company.

[David Heffernan 2345]

30 minutes ago, dummzeuch said:

Of course that particular reason might not be valid for you or your company.

OK, so you agree with me. 

[David Heffernan 2345]

1 hour ago, Lars Fosdal said:

By keeping current, you will deal with changes, one version at a time.

True. But that's not necessarily less work. By batching a few releases together you reduce the number of context switches. That can easily be significant. 

 

If you do maintenence then you need to maintain a greater number of Delphi installations per dev machine if never skip. 

 

In my case I have to apply bespoke patch to rtl code to fix all the floating point defects that Emba won't fix. And that requires a chunk of work for every distinct version of Delphi. Skipping reduces that overhead. 

 

So blanket statements are easily seen to be bogus. It all depends on context. 

[Lars Fosdal 1792]

32 minutes ago, David Heffernan said:

So blanket statements are easily seen to be bogus. It all depends on context. 

Which is why I started with

3 hours ago, Lars Fosdal said:

From my experience, the complexity of dealing with multiple generations of breaking changes has been far more expensive in man-hours than the cost of keeping current.  Of course, that does not necessarily apply for everyone

 

[Dmitry Arefiev 101]

43 minutes ago, David Heffernan said:

In my case I have to apply bespoke patch to rtl code to fix all the floating point defects that Emba won't fix.

Could you please provide RSP numbers. May be even you can provide your patch.

[FredS 138]

1 hour ago, Lars Fosdal said:

as the 64-bit debugger is utter and completely crap

 

In Berlin the 64bit debugger outperforms the 32bit on my systems.

Certainly crap from Godzilla on..

[Lars Fosdal 1792]

Every bloody time I've tried to use the 64-bit debugger, breakpoints stopped working, evals were wrong, stepping stopped working, so in the end, I simply decided it was too soon. I really hope they get it right eventually.  

[FredS 138]

11 minutes ago, Lars Fosdal said:

Every bloody time

 

In Godzilla and beyond, at least for me.. Occasionally I run Rio when there are a lot of compiler directives in a file.

Rio is a better Notepad++ than Berlin but eventually you need to run the code and it all ends by closing Rio and re-opening Berlin..

 

 

[David Heffernan 2345]

1 hour ago, Dmitry Arefiev said:

Could you please provide RSP numbers. May be even you can provide your patch.

I submitted many QC reports, including one with a detailed document explaining how to make the floating point control word handling threadsafe. These got deleted when QC was killed. I can't be bothered to add them again. 

 

Marco and David M know about this.

[hsauro 40]

2 hours ago, David Heffernan said:

In my case I have to apply bespoke patch to rtl code to fix all the floating point defects that Emba won't fix. And that requires a chunk of work for every distinct version of Delphi.

I know it’s off thread, but this sentence piqued my interest, what kinds of defects are you referring to? I used to do more numerical work on Delphi than I do these days but it would still be interesting learn more about these.mmaybe you’ve written them up or mention them somewhere?

 

I just saw your last reply to someone else who had the same question, I think you answered the question there.

Edited February 27, 2020 by hsauro

[David Heffernan 2345]

58 minutes ago, hsauro said:

I know it’s off thread, but this sentence piqued my interest, what kinds of defects are you referring to? I used to do more numerical work on Delphi than I do these days but it would still be interesting learn more about these.mmaybe you’ve written them up or mention them somewhere?

 

I just saw your last reply to someone else who had the same question, I think you answered the question there.

The most significant issue is that Set8087CW and SetMXCSR are not threadsafe.

 

It's a bit of effort to fix it because you need to patch things like the code that handles external exceptions, which also interacts with fp unit control state.

 

I wrote a comprehensive explanation of the issues, and how I addressed them. On request from Emba staff. I submitted that doc as a QC report. Emba then killed QC and asked me to resubmit all my disappeared QC reports. That pissed me off. 

 

Doc is here 

 

https://drive.google.com/file/d/0B2MV9dPR57BUbnVvNW0zaEFnYTg/view?usp=drivesdk

Edited February 27, 2020 by David Heffernan

[hsauro 40]

8 hours ago, David Heffernan said:

The most significant issue is that Set8087CW and SetMXCSR are not threadsafe.

 

It's a bit of effort to fix it because you need to patch things like the code that handles external exceptions, which also interacts with fp unit control state.

 

I wrote a comprehensive explanation of the issues, and how I addressed them. On request from Emba staff. I submitted that doc as a QC report. Emba then killed QC and asked me to resubmit all my disappeared QC reports. That pissed me off. 

 

Doc is here 

 

https://drive.google.com/file/d/0B2MV9dPR57BUbnVvNW0zaEFnYTg/view?usp=drivesdk

Thanks for the link.  I read through the document, it doesn’t seem such an unreasonable thing to implement for the company. They should allow developers such as yourself to contribute to the libraries, perhaps in return for free licenses. The company either lacks interest, expertise or doesn’t have the bandwidth.

[Alexander Elagin 143]

16 hours ago, Lars Fosdal said:

The 64-bit debugger is utter and completely crap.

You haven't tried to use the Linux debugger yet, have you? The 64-bit debugger in 10.1 is a piece of cake compared to 10.3 Linux one...

[Sherlock 663]

16 hours ago, David Heffernan said:

OK, so you agree with me. 

So do I. And I concede, that I should have mentioned FMX in my blanket statement. For VCL changes are quite rare, especially in "same name" releases (i.e. 10.3.2 -> 10.3.3).

[Lars Fosdal 1792]

2 hours ago, Alexander Elagin said:

You haven't tried to use the Linux debugger yet, have you? The 64-bit debugger in 10.1 is a piece of cake compared to 10.3 Linux one...

Once. That was enough.

[David Schwartz 426]

While I understand and appreciate the arguments some of you are putting forth, in this case we are building apps that are only used in-house. We're similar to a SaaS business where customers post files to an FTP area and they go down a production line and stuff pops out the other end. They don't see what's going on under the hood, nor do they care. We have VMs that are still running WinXP. Most of our code has not been rebuilt since 2011 and it's still functioning perfectly. I honestly don't know why there was discussion about upgrading from Tokyo to Rio since most of the software was built so long ago and there's no need to rebuild it.

[Hector McGillivray 1]

On 2/25/2020 at 7:10 AM, Sherlock said:

What everybody involved forgot, is the amount of customizing that went into the software for some special really needy customers - customizing, that went unnoticed or at least undocumented. 

I have suffered from this, as a customer, more than once. Complete rewrites, for behind-the-scenes benefits (often of dubious merits to the company, and of no benefit to the customer) that remove critical features essential to operations. I have submitted bug reports on missing features that have had responses like "We didn't think anybody used that" and even "We didn't know that it did that". The amount of use-case knowledge that gets lost in a total rewrite should never be underestimated.