Do you need an ARM64 compiler for Windows?

[Anders Melander 1783]

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 June 21, 2022 by Anders Melander

[Brian Evans 105]

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 June 22, 2022 by Brian Evans

[RonaldK 18]

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 June 22, 2022 by RonaldK

[Lars Fosdal 1792]

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 😛

[Anders Melander 1783]

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.

[Fr0sT.Brutal 900]

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 😉

[weirdo12 19]

Lars, to answer your question - no.

[tgbs 14]

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

[dummzeuch 1505]

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

[tgbs 14]

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

[Clément 148]

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 August 2, 2022 by Clément

[Anders Melander 1783]

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!

[Berocoder 14]

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 ?

[David Heffernan 2345]

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

[Lars Fosdal 1792]

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.

 

[Brandon Staggs 278]

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 April 2 by Brandon Staggs

[RonaldK 18]

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?

[A.M. Hoornweg 144]

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.  

 

[Anders Melander 1783]

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?

[A.M. Hoornweg 144]

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.

 

[Anders Melander 1783]

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?

[David Heffernan 2345]

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. 

[A.M. Hoornweg 144]

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.

[Brandon Staggs 278]

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.

[Vandrovnik 214]

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? 🙂