Jump to content
Lars Fosdal

Do you need an ARM64 compiler for Windows?

Recommended Posts

Since I brought up DevExpress' association with Russia in this thread I think it's only fair that I share the response I just got from DevExpress on the matter.

 

I sent the following to Julian Bucknall (DevExpress CTO) earlier today:

Quote

Hi Julian,

I've been asked by the companies I work for to act as their representative in the following matter. That said, I personally fully support the views and opinions expressed.

 

Being a DevExpress VCL subsciber, given the War in Ukraine and the situation with Russia vs. The World, we'd like to inquire about what DevExpress is doing about the fact that, as far as we know, DevExpress' owners are Russian and the DevExpress VCL developers are also Russian.

 

Since Russia is now cut off (or being cut off) from the technologies DevExpress is supposed to support and we fully expect that Russia will soon be living in the technological middle ages behind the Iron Curtain, DevExpress does not currently look like a safe bet as a 3rd party technology provider. As you probably know, most companies using DevExpress VCL are often heavily invested in it and therefore highly dependent on it and the lack of communication from DevExpress on this matter, the decision not to publish a roadmap and the change we've experienced in the responses from your support people, has made us reconsider our subscriptions.

and I just got the following response (emphasis mine) from Ray Navasarkian (DevExpress CEO):

Quote

Developer Express Inc is a U.S. corporation and 100% owned by U.S. citizens. As such, we have always complied and continue to comply with all regulations/sanctions instituted by the U.S. Government. Due to the horrific war in Ukraine, the tragic loss of innocent life, and America’s new sanctions regime, we chose to cancel all software development/support contracts in the Russian Federation on March 2, permanently.

 

The reputation of our software component products, the quality of our support services, and our 24-year track-record speak directly to our commitment to the VCL developer community. Over the last quarter century, we have done our very best to meet and exceed customer expectations.

 

I am in no position to adjudicate whether we are a safe bet. While we are not perfect, I do think our VCL products offer unique (if not unmatched) capabilities.

Over the last 2+ months, we've issued two minor updates and we recently published our VCL help files online. We will issue another update in August and expect to issue a major release by year end. If you have specific business needs/requirements, please do let me know. I'll be happy to discuss them with you. One important note: We chose to abandon FMX development in late 2020. Julian described the situation in the following blog post: https://community.devexpress.com/blogs/ctodx/archive/2020/12/03/fmx-grid-future-plans.aspx

 

Regarding a roadmap - We did not publish a roadmap in January/February because in some respects, we are at a development crossroad. Last year we invested heavily in our VCL chart library. While we had high hopes, our initial CTP did not have much market traction. Though I do not want to abandon all our work, this may be necessary. Right now, our focus is on products like the QuantumGrid - products that are used most by our VCL customers.

 

Regarding support - if you are referring to our decision to reduce support services for those individuals that submit 50+ tickets per year, this is an unavoidable reality. We want to help everyone, but we cannot continue to be the custom development shop for a handful of customers. If you are referring to discussions as to why we offer more products for the .NET Framework, then this comes down to market size. Yes, we'd love to release a VCL Dashboard and/or Diagram control, but the size of the market prevents us from doing so. We simply would not recoup our R&D investment (not to mention the cost to support these products). If you have submitted a support ticket and we failed to respond in a professional/timely manner, please let me know. I'll be happy to investigate the particulars and see how we can improve.

[...]

Should you have additional questions or concerns, feel free to contact me at your convenience.

 

So I guess that puts that topic to rest for my part. I too would have liked a roadmap and I can't quite understand why they can't produce something, but apparently that's just the way it is.

 

3 hours ago, Fritzew said:

back to work

Indeed!

Edited by Anders Melander
  • Thanks 2

Share this post


Link to post

Microsoft has in the past put large amounts of resources into the 'next big thing' followed by it being abandoned. Chasing them is a path to ruin for any smaller companies. Even good products get poor support when they decide to chase something else. Windows Phone 7, 8 and 10, and Windows RT all on ARM and all now deprecated dead ends for example. Or the whole UWP / UWA mess where it seems to be on the way out then comes back. Not a very stable base for third party support. 

 

Not sure it is worth chasing ARM64 yet. 

Edited by Brian Evans

Share this post


Link to post

All these points:

9 hours ago, Anders Melander said:

we chose to cancel all software development/support contracts in the Russian Federation on March 2, permanently.

 

9 hours ago, Anders Melander said:

Though I do not want to abandon all our work, this may be necessary. Right now, our focus is on products like the QuantumGrid - products that are used most by our VCL customers.

 

9 hours ago, Anders Melander said:

Regarding support - if you are referring to our decision to reduce support services for those individuals that submit 50+ tickets per year, this is an unavoidable reality.

Is this "roadmap" interesting for new or existing customers?

Hard to believe that many existing customers stay in maintenance after reading this.

So there was a good reason why no more roadmap came out. There is nothing in the pipeline.
I hope Embarcadero's missing roadmap isn't for the same reason.

Edited by RonaldK

Share this post


Link to post
21 hours ago, David Champion said:

... open a Non-Technical forum where we as members can speculate wildly and stir up

general dissent.

It is called off-topic 😛

  • Thanks 1

Share this post


Link to post
53 minutes ago, RonaldK said:

Hard to believe that many existing customers stay in maintenance after reading this.

So there was a good reason why no more roadmap came out. There is nothing in the pipeline.

From our POW there are primarily two reason to pay maintenance on a product (any product):

  1. If you need access to the latest version regularly, the yearly subscription fee is cheaper than paying for a new license each time.
  2. Support the supplier financially so they are able to keep the product alive.

Since DevExpress seems to have done "the right thing" here, we're not about to punish them for that. Yes, we can expect lower output from them for a while while they get a new team up to speed, but unless development complete stalls, for an extended period of time, we can live with that.

 

With regard to the mentioned limit on support I think it's entirely reasonable. That was not our problem. Our problem was more pertaining to the perceived increasingly non-committal responses we got when we raised issues regarding deficiencies in the products. Now that I know the state of things it makes much better sense.

  • Like 2

Share this post


Link to post
15 hours ago, Anders Melander said:

There's a difference between someone spying on me for their own gains and someone trying to harm me just because they're angry at everybody else.

Sure thing. However, backdoor holes left for spying could be revealed by someone else and used with all possible harmful purposes. Contrary, I've never heard of any Russian developers that are "angry at everybody else" and do any harm with their software. They seem to know the difference between business and politics while others seem not. I know several cases when other developers were so angry to put some destructive code into their products to be executed when being run in Russia. Not mentioning numerous companies leaving the market screwing up all their contract liabilities.

Back to the topic, the quote you gave shows that rules of the game are maintained. Formalities are valid, nothing to worry about things you don't know 😉

  • Like 3

Share this post


Link to post

Linus Torvalds has announced Linux 5.19, and this time released a version of Linux from an Arm-based Apple MacBook running Asahi Linux. 

 

Link

Share this post


Link to post

I am working on a cheap Fujutsu Esprimo mini PC.

 

(I am sure that at least as many people are interested in this as in Linus Torvalds having bought an expensive Apple thingy. 😕

  • Haha 2

Share this post


Link to post

My point is that Linux is everywhere, especially in servers and non-GUI devices. And today, with the energy problems, more and more ARM processors will enter them. And it's silly for the Embarcadero not to take this seriously

  • Like 1

Share this post


Link to post

Till in DevExpress front:

 

https://community.devexpress.com/blogs/vcl/archive/2022/07/25/vcl-subscription-upcoming-features.aspx

 

" In this blog post, I'll summarize new VCL features we expect to ship in mid to late August. As always, thank you for your continued support."

 

Might not be the roadmap, but they are working.

 

Edited by Clément

Share this post


Link to post
1 hour ago, Clément said:

Might not be the roadmap, but they are working.

Sure, but that's hardly worth USD 600/year. Most of the stuff on that list is just repackaging of their existing features.

Pfft!

Share this post


Link to post

I assume those Delphi developers that using a Mac M1, M2 or M3 would be happy if Embarcadero would recompile Delphi IDE and compiler to Windows ARM.
What is the potential problem with that ?

Share this post


Link to post
3 hours ago, Berocoder said:

I assume those Delphi developers that using a Mac M1, M2 or M3 would be happy if Embarcadero would recompile Delphi IDE and compiler to Windows ARM.
What is the potential problem with that ?

I mean, how hard could it be????

  • Like 1
  • Haha 2

Share this post


Link to post
1 hour ago, David Heffernan said:

I mean, how hard could it be????

IDE and Compiler: Pretty hard! That would not be a recompile.
VCL and RTL: Should be possible to port, assuming the Windows APIs are mostly "the same" for ARM as for x64.

 

Share this post


Link to post
Posted (edited)
6 hours ago, Berocoder said:

What is the potential problem with that ?

Embarcadero's ARM compilers use an LLVM backend. This leads to differences such as how exceptions are handled. This is not a trivial difference and this is likely only scratching the surface of the problems that would have to be resolved. They haven't even given us a 64-bit Intel IDE yet. I doubt ARM64 is anywhere near. This is also likely one reason native Windows ARM compile target is not going to be available soon or if it is, will not be a simple matter of recompiling for many non-trivial projects.

Edited by Brandon Staggs
  • Like 2

Share this post


Link to post
3 hours ago, David Heffernan said:

I assume those Delphi developers that using a Mac M1, M2 or M3 would be happy if Embarcadero would recompile Delphi IDE and compiler to Windows ARM.

What benefits do you expect from this?
Performance: I doubt that an ARM IDE will really be faster than the current x86 version?

Share this post


Link to post
15 hours ago, RonaldK said:

What benefits do you expect from this?
Performance: I doubt that an ARM IDE will really be faster than the current x86 version?

 

Please remember that all installed design time packages (BPL files) and their associated runtime packages must be compiled to the same architecture and bitness as the IDE itself.  BPLs are just DLLs and the IDE loads them directly, in-process. This means that moving away from 32-bit x86 would be a huge breaking change for the deployment of third party components.

 

Frankly, I've never understood why the design time packages are hosted in the IDE process itself because bugs in components will affect the IDE. Many of us will know the phenomenon that the IDE may throw an AV exception in some BPL when you terminate Delphi.  

 

Share this post


Link to post
1 hour ago, A.M. Hoornweg said:

This means that moving away from 32-bit x86 would be a huge breaking change for the deployment of third party components.

No more than any other major upgrade of Delphi.

 

1 hour ago, A.M. Hoornweg said:

Frankly, I've never understood why the design time packages are hosted in the IDE process itself because bugs in components will affect the IDE.

How would you have designed the system then?

  • Like 1

Share this post


Link to post
2 hours ago, Anders Melander said:

No more than any other major upgrade of Delphi.

 

How would you have designed the system then?

My preference would be to have the component packages in separate helper processes.

 

Share this post


Link to post
Just now, A.M. Hoornweg said:

My preference would be to have the component packages in separate helper processes.

Yes, that much was clear. So how do you accomplish that?

Share this post


Link to post
3 hours ago, A.M. Hoornweg said:

My preference would be to have the component packages in separate helper processes.

 

I can imagine this working fine for non visual components but what about components that paint themselves on the design surface? Cross process window hierarchies are basically untenable. 

Share this post


Link to post
2 hours ago, Anders Melander said:

Yes, that much was clear. So how do you accomplish that?

If you'd ask me to attempt a thing like that, I'd first look for a suitable bidirectional RPC framework. Something having capabilities like COM.  COM was used by IDE's such as Visual Basic to host (in-process) VBX controls but it works across processes as well. The "helper processes" would only need to contain the designtime part of the components, at runtime they do nothing.  Such an approach would move the design time components out of the address space of the IDE.  Also, the "bitness" of the helper processes and the IDE would be independent from each other.

Share this post


Link to post
12 hours ago, A.M. Hoornweg said:

Frankly, I've never understood why the design time packages are hosted in the IDE process itself

It was required to accomplish the original RAD concept for Delphi. It is a dual-edged blade to be sure, but in this case, I will take the bugs that come with having an active IDE that actually runs the components. While you could guarantee that DLLs won't crash if you don't load them into the process (obviously), you aren't going to be able to reproduce all of that with another method, and I am not interested in the compromise.

  • Like 1

Share this post


Link to post
9 hours ago, A.M. Hoornweg said:

My preference would be to have the component packages in separate helper processes.

 

I hope they keep it the way it is - can you imagine how many broken versions we would have to suffer if they now moved .bpls to another process? 🙂 

  • Like 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×