Leaderboard

Windows on ARM does not need to unseat two entrenched ecosystems to be successful like Windows Phone did. There is no comparison. Most of the people buying a Windows computer do not need to care if the CPU is ARM or x64. On the flip side, however, since ARM-based Windows machines run x64 apps just fine, there is no real pressure on Embarcadero to rush offering a compiler.

We're not talking about some stripped-down WinRT "Windows store only" operating system that doesn't run 99.99% of the software made for Windows, like the previous Windows on ARM devices. The current offering from Microsoft runs both x86 and x64 binaries and does not require the Windows Store (unless someone buys a Windows-S version of the OS, but that is also shipped on x64 and has nothing to do with ARM). The Prism emulation layer is seamless. As long as you aren't expecting to run AAA games on one, or other software requiring that kind of hardware, ARM is a viable choice, and in fact a superior choice if you need portability with energy performance. This is an expansion of the Windows ecosystem because vendors now have the ability to offer hardware with far better energy performance than what x64 CPUs allowed in the past. A hardware vendor does not have to take a bet that Microsoft will succeed with a new platform -- Microsoft has owned this market for 30 years. Of course Delphi needs to offer an ARM64 compiler for Windows. And why should that be a problem? Delphi has shipped with ARM compilers for years.

Delphi is notoriously without any public timelines. They have on occasion published very vague outlooks, but AFAIK no public roadmaps of any reasonable detail exist. During their last release webinar it was Ian, I believe, who suggested this is entirely due to Idera's policies. The old excuse about different countries having different laws about forward-looking statements was mentioned in that context, if I am not mistaken. One wonders how other technology companies with far deeper pockets (hence, bigger targets for lawyers) are able to make all sorts of roadmaps and timelines. I wouldn't blame anyone working on Delphi for the lack of a roadmap, but it's still kind of a running joke for the last decade or more... Prior attempts at Windows on ARM were complete failures, but this one is obviously going to stick, and has nothing in common with Microsoft's previous attempts. I have a Snapdragon Windows PC and it's definitely "for real this time." I don't see any reason why Delphi shouldn't offer Windows on ARM as a compiler target.

Hi In general FMX works like the VCL for desktop platforms. The main differences are : - positions are single instead of integer (position.x, position.y instead of Top/Left) - Text replace Caption property everywhere (instead of for a TForm) - each visual component is a container - many more alignments than for VCL components - the components are styled and can be completely changed with styles (but don't try that to start). - no TDBxxx components, use LiveBindings to link data to visual components - for macOS the first option of the TMainMenu is fusion with macOS App menu, add an empty one (and hide/remove in FormCreate it if its not macOS) if you want the classic "file" option To debug / deploy to macOs you need a Mac available locally or on Internet and PAServer installed on it. I've done many things on FireMonkey with a lot of open source projects on GitHub (not only games 😉 ). Replay videos (in French) of my Twitch live coding streams are available, but you can check this series (the page is in French, the videos are in English) : https://apprendre-delphi.fr/coding-bootcamp-2023.html To the books list I had the "Delphi Programming Projects" from William Duarte. For other samples then the ones available with Delphi you have this code repository https://github.com/FMXExpress/Cross-Platform-Samples and some others I've listed on https://github.com/DeveloppeurPascal/Delphi-samples/blob/main/OtherDelphiSampleRepositories.md If you have a first project to create, give us some tips, we will find the available resources around it.

Thank you all. I ordered both of the books that were recommended. Quick question while I'm waiting for the books to arrive -- which FMX component is the closest match to VCL's TListView in report mode? Thanks!

Have you ever tried GDI+ Win32 apps compiled by Delphi?

From the Microsoft website (https://learn.microsoft.com/en-us/surface/surface-arm-faq😞 Emulated apps run via the Prism emulation engine, which minimizes performance loss and ensures that most x86/x64 applications operate seamlessly on Arm64 systems. Users shouldn't notice any significant difference between native and emulated apps apart from potential performance variations. Can I run Windows programs that aren't in the Microsoft Store on my Windows 11 Arm-based device? Yes, non-Store Windows apps can be installed and run on Windows 11 Arm-based devices. Most applications run natively or through Prism emulation, providing smooth performance.

How are Delphi apps performing on your Snapdragon Windows PC? Is the Windows-on-ARM emulation layer slowing Delphi apps down? Does the Delphi IDE run on your Snapdragon Windows PC?

Got a reply on my ticket: Yes

That's my same knowledge. And that's why I asked in the first place.

But this 2025 Surface Pro 11 unboxing video looks very promising:

Microsoft has done several attempts at Windows on ARM for over a decade and they have all been total failures. Anybody who targeted it ended up wasting a lot of time and money. The most recent effort does have two things previous attempts didn't: full win32 API support and the ability to run x86 binaries. That alleviates the need for application developers to produce ARM binaries until Windows on ARM gains some traction as a platform. Adding support before the platform gains some traction is unwise. We are in fool me once, fool me twice, fool me three times territory for Windows on ARM.

As always: Into the pockets of the parent company Idera. It's called a "Gewinnabführungsvertrag" in Germany. On the other hand how do you know that there are millions of Delphi users? And more importantly: Do you know that they have paid for a license recently? Maybe 99% of these supposed millions are still using Delphi 5 or 7?

You should rather read that as "they will open up the next major construction site as soon as there is money and manpower available, and it will take several releases until it is usable"...and even that should be taken with a grain of salt.

No library developer would test things like this. I mean why stop at FMX/VCL? What about database frameworks. Does it have dependencies on any of them? Does it work in a Windows service? Should there be a test for that? It's simple to see by inspecting the uses clause, so the developer just does not need to do any of that.

I don't know what research RDP did (probably asking some GenAI ), but Spring4d does not contain thread-safe collections - for those needs, refer to libraries such as OTL or protect them by primitives in your own code according to your use-cases. I don't step into that territory because you cannot simply make general-purpose collections thread-safe. It already starts with simple things like: how do you protect a list where one thread adds/removes items and another iterates over it? It then requires a different API, and it's complex to design a general-purpose thread-safe collection library because everyone has their use cases, which you cannot simply combine.

I don't know why Embarcadero insists on putting the _DEPRECATED_ATTRIBUTE1 macro in between a function's name and its arguments. That just annoys me. All examples of [[deprecated]] and __attribute__(deprecated) that I have seen use it either in front or in back of the function declaration, not in the middle. Even the DocWiki documents it as belonging at the end of a declaration: https://docwiki.embarcadero.com/RADStudio/en/Deprecated That is because the _DEPRECATED_ATTRIBUTE1 (and __DEPRECATED_ATTRIBUTE3) macro ignores the message text when you are compiling with the classic compiler (at least in 12.2 - I don't have 12.3 installed yet to check this): // CLANG vs. BCC attributes #if !defined(__clang__) ... #define _DEPRECATED_ATTRIBUTE0 [[deprecated]] #define _DEPRECATED_ATTRIBUTE1(msg) [[deprecated]] // Ignore message as bcc's implementation is capped:( #define _DEPRECATED_ATTRIBUTE2 [[deprecated]] #define _DEPRECATED_ATTRIBUTE3(msg) [[deprecated]] // Ignore message as bcc's implementation is capped:( ... #else ... #define _DEPRECATED_ATTRIBUTE0 // Could use __attribute__((deprecated)) #define _DEPRECATED_ATTRIBUTE1(msg) // Could use __attribute__((deprecated( msg ))) #define _DEPRECATED_ATTRIBUTE2 __attribute__((deprecated)) #define _DEPRECATED_ATTRIBUTE3(msg) __attribute__((deprecated( msg ))) ... #endif This behavior is clearly wrong/outdated for the classic compiler, given that you demonstrated [[deprecated("message")]] is able to display message text just fine, and that behavior is even documented on the DocWiki: https://docwiki.embarcadero.com/RADStudio/en/Deprecated I have reported the issue: RSS-3285: _DEPRECATED_ATTRIBUTE1 and _DEPRECATED_ATTRIBUTE3 ignore message text for classic compiler Given the above macro declarations, the only possibility I can think of is that your real project is not actually compiling with the classic compiler (which you can verify by looking at the build output messages).

In <System.Net.Mime .hpp>, is there a 'deprecated' attribute on the declaration of AddStream()? Also, which C++ compiler(s) are you using, exactly? The DocWiki says only the classic bcc32 compiler supports deprecated messages.

Yes. For one you are running all the tests concurrently which means that you will be penalizing the tests that start later because they will be competing for CPU against the test that are already executing. Execute each test and wait for it to finish before you start the next test. You also seem to have massive memory leaks which probably means that some of the test have an unfair advantage because they don't consume time releasing their resources. If you are using thread pools (I'm not sure that your are (if not, you should be)) then you should ensure that the thread pool has been spun up before you start the test. Otherwise you will penalize the first threads with the startup overhead. Instead of just looking at the time from start to end and then guessing about why it is fast/slow/whatever, profile your code so you can see exactly where the bottlenecks are. Do this for each individual algorithm in turn. Apart from that, for something as simple as this, you don't need locking and you definitely don't need to use the Windows message queue as a work queue. Use a simple lock-free fifo queue instead. You could even use a fixed size lock-free ring buffer (just an array of records with two integer values as in/out indices). The fixed size buffer and the records would eliminate the allocation overhead of the queue itself. You should probably also try to eliminate the use of string and replace it with fixed size buffer if possible.

@alank2 What you describe implies that either 1) TMultipartFormData is trying to free an invalid FStream object, or 2) you are trying to free an invalid TMultipartFormData object. Unfortunately, there is not enough detail provided to help you. You will have to debug the code for yourself, and double check the user of the pointers involved.

Look at the crash details to get hints as to what is going on. Note you didn't post any and "crash" is very little to go on. Guessing it is the CALL that crashes due to the object reference being no longer valid. Perhaps owned objects are getting freed automatically or earlier than before. Not sure which code is yours (if any) so hard to tell.

For starters, I recommend reading two FMX-related books: "Delphi GUI Programming with FireMonkey" by Andrea Magni, and "Fearless cross-platform development with Delphi" by David Cornelius. Together, they cover the most important parts of how FMX framework functions, and they both write about similarities and differences between VCL. I suggest you also play around and discover the RAD Studio Multi Device Samples, since they contain good chunks of code and UI components to see how to interact with FMX. If you have multiple devices with different platforms (Android, iOS, macOS), make sure you try the apps on all of them, to see how the deployment and functionality works across different platforms. As you start using FMX, I strongly recommend working with skia4delphi in every project. It is already integrated into FMX, but make sure to enable it in every project as it increases performance and provides you a ton of features that are missing in the stock FMX (such being Svg/Lottie support and right-to-left text). Good luck!

It was not humorous, that what Embarcadero did communicate about the platforms and the way they do releases. The same was with the 64-bit IDE. For years it was a side project that they were testing. Then when some databases stopped shipping 32-bit client libraries they have decided it is time to ship a half-baked solution....

The Windows-on-ARM emulation layer is used to run Delphi applications on a Surface Pro with Snapdragon. This emulation makes it possible to run x86/x64 programs on ARM processors, albeit with potential performance losses.

From your humorous response, I gather that Embarcadero has no timetable for supporting Delphi Windows apps on ARM CPUs and that you don't consider Embarcadero to be a serious company.