RonaldK

You can get a good impression of how good the x86/x64 compiler is or how bad the ARM64 compiler.

Oh wait, you can: Try native ARM64 application on macOS <-> x86/x64 application on Windows 11 ARM, on the same Mac machine with Apple-CPU.

I don't think the codegen has improved and so a Delphi x86/x64 program runs faster on a Windows ARM with emulation (Prism) than the same Delphi program with the ARM compiler. So what's the benefit?

Is this already fixed? https://quality.embarcadero.com/browse/RSP-17724

Intel-based applications already run on Windows ARM. I fear that Delphi ARM64 applications are much slower than x64 applications, even though they run in the emulator. What is the advantage for native ARM64 applications? Code gen of LLVM: https://quality.embarcadero.com/browse/RSP-17724

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

Yes. I'm using it with Chrome remote desktop. (https://remotedesktop.google.com/access/) You can't operate the login screen with it, but everything else can.

All these points: 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.

It's probably more about the Embarcadero development team. Isn't the Idera development model made up of freelance developers? Aren't they mostly based in Ukraine and Russia? Perhaps this development model currently has serious problems.

This "playing dead" is now finding more friends. DevExpress no longer publishes a Delphi roadmap for 2022 either. Is this a good sign too? https://supportcenter.devexpress.com/ticket/details/t1072425/vcl-roadmap-2022

https://blogs.embarcadero.com/de/rad-studio-roadmap-november-2020/ This ends with Delphi 10.5. The silence can be understood in one way or another.

What new functions are planned for Delphi anyway? Is there still a roadmap for Delphi? I haven't found any more. For example, what about continued support for the iOS Simulator? That was on the old roadmaps for a long time, but has it all been lost now? What about the better code generation of the "nextgen" compilers? Delphi has some other work to do at the base. More compilers/platforms are not helpful here.

Since a few weeks the Delphi 11.0 IDE crashes suddenly. Neither an error message nor does this happen when entering or operating the IDE. The eventlog show this: Name der fehlerhaften Anwendung: bds.exe, Version: 28.0.42600.6491, Zeitstempel: 0x612d6e01 Name des fehlerhaften Moduls: clr.dll, Version: 4.7.3910.0, Zeitstempel: 0x61b3f594 Ausnahmecode: 0xc00000fd Fehleroffset: 0x004559ad ID des fehlerhaften Prozesses: 0x24c0 Startzeit der fehlerhaften Anwendung: 0x01d8377b789f2180 Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\bds.exe Pfad des fehlerhaften Moduls: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll Berichtskennung: f70b0408-0121-4d54-bc26-9c8fbc6e3ad2 Vollständiger Name des fehlerhaften Pakets: Anwendungs-ID, die relativ zum fehlerhaften Paket ist: It seems that the root of this is the .NET clr.dll. Is this a known problem here?

I don't think he will help me. I know the answer: Windows 2019 is not supported Unfortunately I didn't have a good experience with the Embarcadero support.

All .NET updates are installed but the problem persists with the new .NET version (4.7 -> 4.8) Name der fehlerhaften Anwendung: bds.exe, Version: 28.0.44500.8973, Zeitstempel: 0x6227d05c Name des fehlerhaften Moduls: clr.dll, Version: 4.8.4470.0, Zeitstempel: 0x61b731cd Ausnahmecode: 0xc00000fd Fehleroffset: 0x004d556a ID des fehlerhaften Prozesses: 0x1140 Startzeit der fehlerhaften Anwendung: 0x01d848c22be05e31 Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\bds.exe Pfad des fehlerhaften Moduls: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll

It doesn't help. The Refactoring menu is gone, but the IDE still dies anyway. Some .NET libs are still loaded by the IDE: Borland.Build.Tasks.Common.dll Borland.Studio.Vcl.Design.Refactoring.dll and many more.

Yes. The Event Log log the first occurrence at 18.Feb. 2022. Delphi 11 previously ran without this problem. Maybe a .NET update brought this problem.

I'm working on Windows Server for many years. So far there have been no problems. This new .NET issue has been popping up for the past few weeks. I think it has more to do with .NET than with Delphi. Maybe Remy's suggestion will help.

I'm not using refactoring. Is there a way to disable/remove the refactoring from Delphi?

Same situation with the latest Delphi 11.1 Name der fehlerhaften Anwendung: bds.exe, Version: 28.0.44500.8973, Zeitstempel: 0x6227d05c Name des fehlerhaften Moduls: clr.dll, Version: 4.7.3910.0, Zeitstempel: 0x61b3f594 Ausnahmecode: 0xc00000fd Fehleroffset: 0x004559ad ID des fehlerhaften Prozesses: 0x57c Startzeit der fehlerhaften Anwendung: 0x01d83e9a646f0d6d Pfad der fehlerhaften Anwendung: C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\bds.exe Pfad des fehlerhaften Moduls: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll For what functionality does Delphi use the .NET framework? Anything that I can switch off?

Delphi need and use it. If you look to the Delphi .NET libs. They need 4.x: // C:\Program Files (x86)\Embarcadero\Studio\22.0\bin\Borland.Build.Tasks.Common.dll // Borland.Build.Tasks.Common, Version=28.0.0.0, Culture=neutral, PublicKeyToken=91d62ebb5b0d1b1b // Global type: <Module> // Architecture: AnyCPU (64-bit preferred) // Runtime: v4.0.30319 // This assembly is signed with a strong name key. // Hash algorithm: SHA1 Since this crash also happens when not working in the IDE, I suspect it might have something to do with .NET's garbage collector.

Windows Server 2019

You need 10.4.1 + Patch https://blogs.embarcadero.com/apple-platforms-patch-for-rad-studio-10-4-1/ or the newest 10.4.2

Running a Delphi 10.4.1 (latest patch) FMX 64bit application on: Catalina : runs fine. High Sierra: on startup an EObjectiveC raises "ObjectiveC-class UNUserNotificationCenter not found" Does anyone have any idea where to look? Here the call stack: :000000010001C000 @DbgExcNotify :000000010001C03E System::NotifyReRaise(System::TObject*, void*) :000000010001C0DA System::_RaiseAtExcept(System::TObject*, void*) :000000010001C1F5 System::_RaiseExcept(System::TObject*) :00000001007117F5 Macapi::Objectivec::TOCGenericImport__2<System::DelphiInterface<Macapi::Usernotifications::UNUserNotificationCenterClass>, System::DelphiInterface<Macapi::Usernotifications::UNUserNotificationCenter> >::GetOCClass() :0000000100713D88 System::Mac::Notification::UserNotificationCenter() :0000000100712472 System::Mac::Notification::TNotificationCenterCocoa::TNotificationCenterCocoa() :0000000100715087 System::Mac::Notification::TNotificationCenterCocoa::GetNotificationCenter() :0000000100711B6E System::Mac::Notification::TPlatformNotificationCenter::GetInstance() :00000001007173F8 System::Notification::TBaseNotificationCenter::InternalGetInstance() :0000000100716AEC System::Notification::TCustomNotificationCenter::TCustomNotificationCenter(System::Classes::TComponent*) :0000000100111B7B System::Classes::TReader::ReadComponent(System::Classes::TComponent*)::CreateComponent(void*) :00000001000DE01D System::Classes::TReader::ReadComponent(System::Classes::TComponent*) :0000000100112008 System::Classes::TReader::ReadDataInner(System::Classes::TComponent*) :0000000100111EEF System::Classes::TReader::ReadData(System::Classes::TComponent*) :00000001000E8ACF System::Classes::TComponent::ReadState(System::Classes::TReader*) :00000001000DEC07 System::Classes::TReader::ReadRootComponent(System::Classes::TComponent*) :00000001000D8F8F System::Classes::TStream::ReadComponent(System::Classes::TComponent*) :0000000100104900 System::Classes::InternalReadComponentRes(System::UnicodeString, NativeUInt, System::Classes::TComponent*&) :000000010010C237 System::Classes::InitInheritedComponent(System::Classes::TComponent*, System::TMetaClass*)::InitComponent(void*, System::TMetaClass*) :000000010010C2DD System::Classes::InitInheritedComponent(System::Classes::TComponent*, System::TMetaClass*) :000000010058E52D Fmx::Forms::TCommonCustomForm::TCommonCustomForm(System::Classes::TComponent*) :00000001005963E7 Fmx::Forms::TCustomForm::TCustomForm(System::Classes::TComponent*) :00000001005898B8 Fmx::Forms::TApplication::CreateForm(System::Classes::TComponentClass, void*) :0000000100589799 Fmx::Forms::TApplication::RealCreateForms() :0000000100522D3E Fmx::Platform::Mac::TPlatformCocoa::Run() :000000010058A195 Fmx::Forms::TApplication::Run() main(1,0x00007ffeefbffa38,0x00007ffeefbffa48,0x00007ffeefbffaf0) :00007FFF78D07015 start :00007FFF78D07015 start

To reproduce this: - create simple FMX app with target macOS - place a TNotificationCenter to the main TForm - run on Catalina -> run fine. - run on High Sierra -> Exception on startup The TNotificationCenter online help says to platform support: OSX 10.8+