Lazarus for Windows on aarch64 (ARM64) - Native Compiler lazarus / 34-Windows ---------------------------------------------------------------------- msintle · 2024-04-12 13:24 Has any progress been made in getting Lazarus to work natively on ARM64 (aarch64) on Windows? This support exists for macOS and Linux, but is ironically absent on Windows; where Lazarus had originally started. Without native code, we can't do certain things like compile shell extensions; and ARM64 is gaining traction on the Windows side. Are there any development costs which need sponsoring to get over this hurdle? ---------------------------------------------------------------------- VisualLab · 2024-04-12 19:45 Quote from: msintle on April 12, 2024, 03:24:27 pmHas any progress been made in getting Lazarus to work natively on ARM64 (aarch64) on Windows? This support exists for macOS and Linux, but is ironically absent on Windows; where Lazarus had originally started. Without native code, we can't do certain things like compile shell extensions; and ARM64 is gaining traction on the Windows side. Are there any development costs which need sponsoring to get over this hurdle? How common is Windows on ARM64? Is it at least half as popular on ARM64 as Linux? Does Windows for ARM64 support peripherals as well as Windows for ARM64/EM64T? ---------------------------------------------------------------------- dsiders · 2024-04-12 20:35 Quote from: VisualLab on April 12, 2024, 09:45:49 pmQuote from: msintle on April 12, 2024, 03:24:27 pmHas any progress been made in getting Lazarus to work natively on ARM64 (aarch64) on Windows? This support exists for macOS and Linux, but is ironically absent on Windows; where Lazarus had originally started. Without native code, we can't do certain things like compile shell extensions; and ARM64 is gaining traction on the Windows side. Are there any development costs which need sponsoring to get over this hurdle? How common is Windows on ARM64? Is it at least half as popular on ARM64 as Linux? Does Windows for ARM64 support peripherals as well as Windows for ARM64/EM64T? ZDNet claims ARM64 will be 30% of the Windows market by 2026. But crystal balls sometimes lie. Can't speak to the other questions. But we know Windows is way more popular than Linux on X64 desktops, where Linux just reached 4% in 2023. I would expect a similar ratio when it comes to ARM64. And my crystal ball is shattered. ---------------------------------------------------------------------- VisualLab · 2024-04-12 21:27 I would be in favor if Windows was available for ARM64 and supported various devices such as Raspberry Pi, Organe Pi, etc. I mean the real one, not a substitute in the form of Windows IoT (earlier RT and even earlier CE). But these are more of a dream. Porting WinAPI from AMD64/EM64T to ARM64 is years of work (if it is technically possible). All industrial computers (and the like), if they use Windows, probably only run on AMD64/EM64T. The second thing is the processing power that Windows requires to run. However, for now, ARM is inferior to the AMD64/EM64T family in terms of computing power. ---------------------------------------------------------------------- msintle · 2024-04-16 16:32 Quote from: VisualLab on April 12, 2024, 11:27:32 pmI would be in favor if Windows was available for ARM64 and supported various devices such as Raspberry Pi, Organe Pi, etc. I mean the real one, not a substitute in the form of Windows IoT (earlier RT and even earlier CE). But these are more of a dream. Porting WinAPI from AMD64/EM64T to ARM64 is years of work (if it is technically possible). All industrial computers (and the like), if they use Windows, probably only run on AMD64/EM64T. The second thing is the processing power that Windows requires to run. However, for now, ARM is inferior to the AMD64/EM64T family in terms of computing power. It sounds like you're unaware Windows aarch64 has been shipping on laptops (and tablets) since 2018. The full Windows API is available and has been for more than half a decade. Furthermore, not only can Windows aarch64 emulate x86 apps, it can also emulate amd64 apps starting with Windows 11 (although, this doesn't extend to things like major shell extensions, where native code aarch64 is required). Microsoft released (and upgraded) Surface 9 X as an aarch64 device years ago, and in May this year they are going to launch another major upgrade for it as the consumer Surface 10 device, again implemented as an aarch64 platform - their first major consumer play for the first time on aarch64. So yes, it is high time Free Pascal and Lazaru supports aarch64 targets on Windows - the only (and ironically, biggest) platform where they lack this support. ---------------------------------------------------------------------- PascalDragon · 2024-04-16 18:17 Quote from: msintle on April 16, 2024, 06:32:02 pmSo yes, it is high time Free Pascal and Lazaru supports aarch64 targets on Windows - the only (and ironically, biggest) platform where they lack this support. FPC 3.3.1 already supports aarch64-win64, however due to some bugs in the code generator that have yet to be investigated it can't cycle itself and thus is not really usable for developing larger applications (which includes Lazarus). Quote from: VisualLab on April 12, 2024, 11:27:32 pmI would be in favor if Windows was available for ARM64 and supported various devices such as Raspberry Pi, Organe Pi, etc. I mean the real one, not a substitute in the form of Windows IoT (earlier RT and even earlier CE). But these are more of a dream. Porting WinAPI from AMD64/EM64T to ARM64 is years of work (if it is technically possible). Ehm, you are aware that this is already the case for many years? I'm even running a full blown Windows 10 natively on a Pi 4 (see also the WoR project). ---------------------------------------------------------------------- VisualLab · 2024-04-16 19:41 Quote from: PascalDragon on April 16, 2024, 08:17:32 pmQuote from: msintle on April 16, 2024, 06:32:02 pmSo yes, it is high time Free Pascal and Lazaru supports aarch64 targets on Windows - the only (and ironically, biggest) platform where they lack this support. FPC 3.3.1 already supports aarch64-win64, however due to some bugs in the code generator that have yet to be investigated it can't cycle itself and thus is not really usable for developing larger applications (which includes Lazarus). Quote from: VisualLab on April 12, 2024, 11:27:32 pmI would be in favor if Windows was available for ARM64 and supported various devices such as Raspberry Pi, Organe Pi, etc. I mean the real one, not a substitute in the form of Windows IoT (earlier RT and even earlier CE). But these are more of a dream. Porting WinAPI from AMD64/EM64T to ARM64 is years of work (if it is technically possible). Ehm, you are aware that this is already the case for many years? I'm even running a full blown Windows 10 natively on a Pi 4 (see also the WoR project). Yes, I read about it some time ago. I also watched videos on YouTube showing Windows 10 running on the RPi. But it was proof that it was (technically) possible. However, the work was far from comfortable (it was basically a "slide show"). Can ARM64 processors cope with such work? The RPi Foundation specially "trimmed" and adapted Linux (Raspberry Pi OS) so that it could run on their board. I have an RPi 3B. From my own experience, I know that RaspberryPi OS works well, but it is not comfortable to work with (although Lazarus works quite well there). Another thing is that I don't use it as a desktop replacement, but for hobby purposes related to electronics (which is what the RPi foundation designed this board for). ---------------------------------------------------------------------- domasz · 2024-04-16 20:21 Quote from: dsiders on April 12, 2024, 10:35:00 pmZDNet claims ARM64 will be 30% of the Windows market by 2026. But crystal balls sometimes lie. Impossible. And I believe it was President and CEO of Canalys Steve Brazier, not ZDNet. 1) Windows 11 is shit. There is lots of people who still use Windows 10, 7 and even XP. Microsoft totally doesn't know how to progress with Windows. 2) The biggest value Windows has over MacOS or Linux is all the software and games. Most of these won't be ported to ARM 3) ARM is still slow. Macs are slow and their benchmarks aren't true 4) Windows is slow. It got too big, it needs power 5) MacOs and Linux are getting more and more popular on laptops. Windows is now most popular na home desktops, gaming laptops and other powerful machines. ---------------------------------------------------------------------- dsiders · 2024-04-16 23:22 Quote from: domasz on April 16, 2024, 10:21:52 pmQuote from: dsiders on April 12, 2024, 10:35:00 pmZDNet claims ARM64 will be 30% of the Windows market by 2026. But crystal balls sometimes lie. Impossible. And I believe it was President and CEO of Canalys Steve Brazier, not ZDNet. My attribution was incorrect. https://www.windowscentral.com/software-apps/windows-11/arm-cpus- predicted-to-hit-30-pc-market-share-by-2026 ---------------------------------------------------------------------- hansotten · 2024-04-17 07:59 Quote from: domasz on April 16, 2024, 10:21:52 pmQuote from: dsiders on April 12, 2024, 10:35:00 pmZDNet claims ARM64 will be 30% of the Windows market by 2026. But crystal balls sometimes lie. Impossible. And I believe it was President and CEO of Canalys Steve Brazier, not ZDNet. 1) Windows 11 is shit. There is lots of people who still use Windows 10, 7 and even XP. Microsoft totally doesn't know how to progress with Windows. 2) The biggest value Windows has over MacOS or Linux is all the software and games. Most of these won't be ported to ARM 3) ARM is still slow. Macs are slow and their benchmarks aren't true 4) Windows is slow. It got too big, it needs power 5) MacOs and Linux are getting more and more popular on laptops. Windows is now most popular na home desktops, gaming laptops and other powerful machines. Sources of your 'statements'? ---------------------------------------------------------------------- VisualLab · 2024-04-17 11:27 Quote from: domasz on April 16, 2024, 10:21:52 pm1) Windows 11 is shit. There is lots of people who still use Windows 10, 7 and even XP. Microsoft totally doesn't know how to progress with Windows. 2) The biggest value Windows has over MacOS or Linux is all the software and games. Most of these won't be ported to ARM 3) ARM is still slow. Macs are slow and their benchmarks aren't true 4) Windows is slow. It got too big, it needs power 5) MacOs and Linux are getting more and more popular on laptops. Windows is now most popular na home desktops, gaming laptops and other powerful machines. 1. Is it shit? It's hard to say. However, some statistics (probably from a week ago) show that most people currently use Windows 10. However, the fact is that both Windows 11 (and 10) contain various (to put it mildly) annoyances: tracking users (so-called "telemetry"),sending an advertising "cesspool" to the user,forced updates (which occasionally damage the system and/or user files),forced installation of various useless "IT garbage" along with updates.The real problem with these versions of the system is not only violating users' privacy, but also exposing them to costs, for which MS does not pay users (and it should, because it is supposed to increase MS's revenues). In other words, MS transfers part of the costs of its activities to users. And this is plain theft (forcing people to provide services for free). MS forces (technically) the user's computer to download and send data, which the user usually does not want (some of them are not aware of what is happening). You can't turn it off, although you can try to block it. The user pays for data transfer that he did not order or does not want to be shared. His computer's storage is cluttered. And yet, data transfer via the network is not free, because users pay for it with their Internet access operator. These activities increase the load on your computer, which forces your computer to consume more power. On the scale of one day, it's not much. But over the course of a year it adds up to a considerable number. Secondly, this practice burdens Internet connections. Data is unnecessarily "pushed" through the network from the MS server to the user's computer (updates, advertising "cesspool") and vice versa ("telemetry"). On a global scale, this is a significant amount of energy unnecessarily wasted on the nonsense of some companies. Interestingly, MS does not boast about its ecological approach, as Google does (which also makes up and manipulates public opinion). So I suspect that's what you meant when you said Windows was shit. 2. Completely agree. 3. Yes. 4. Agreement. Too many different processes are installed and run, some of which are not needed by an ordinary user (they are useful in corporations). In addition, some of the processes are garbage processes that support: the service of continuous updating and installation of updates and crappy programs, pumping the advertising cesspool from MS servers, "telemetry" and monitoring the operation of the previously mentioned garbage processes. Some of this can be blocked, but this is "messing around in the system". For example: what is the use of geolocation on a desktop used at home for engineering work (not on a laptop, not on a tablet)? 5. Yes. ---------------------------------------------------------------------- msintle · 2024-04-17 14:12 Nice to see everyone has plenty of love for their favorite operating systems Can we get back on track - what needs to be done to fix FPC so larger apps like Lazarus can be compiled successfully for aarch64 on Windows? Let's face it - Windows is still going to be the biggest market for the foreseeable future - and with new aarch64 consumer Surface 10s coming out in May, the timing is perfect for aarch64 Lazarus running natively on Windows. ---------------------------------------------------------------------- Wallaby · 2024-04-17 20:25 Quote from: msintle on April 17, 2024, 04:12:52 pmNice to see everyone has plenty of love for their favorite operating systems Can we get back on track - what needs to be done to fix FPC so larger apps like Lazarus can be compiled successfully for aarch64 on Windows? Indeed  From my experience with the trunk compiler, it works in principle for simple programs, but there are two showstopper bugs I have reported: Win64 AArch64 optimizer bug and Win64 AArch64 exception handling I already offered to pay anyone in the FPC team who is able to fix those issues (aka offer a bounty), but so far looks like no one is interested. ---------------------------------------------------------------------- PascalDragon · 2024-04-18 20:09 Quote from: VisualLab on April 16, 2024, 09:41:40 pmYes, I read about it some time ago. I also watched videos on YouTube showing Windows 10 running on the RPi. But it was proof that it was (technically) possible. However, the work was far from comfortable (it was basically a "slide show"). Can ARM64 processors cope with such work? Of course they can. The Pi 3 might be a bit on the weaker side, but with a Pi 4 it runs rather comfortably and in fact I also use Windows inside a virtual machine utilizing the KVM capability of the underlying Linux system (less potential driver issues this way, but near native performance). And on the ARM laptops we have at work Windows definitely runs comfortably enough, even the i386 and x86_64 emulation is working rather well. Not to mention that there is also Windows on ARM developers kit with an 8 core CPU, 32 GB RAM and a PCIe port for NVMe support. I did not have the chance to try one yet, but the M*-processor based Macs should be rather nice to use as well regarding performance, especially since Linux is supported on them as well. Quote from: VisualLab on April 16, 2024, 09:41:40 pmThe RPi Foundation specially "trimmed" and adapted Linux (Raspberry Pi OS) so that it could run on their board. I have an RPi 3B. From my own experience, I know that RaspberryPi OS works well, but it is not comfortable to work with (although Lazarus works quite well there). Another thing is that I don't use it as a desktop replacement, but for hobby purposes related to electronics (which is what the RPi foundation designed this board for). I use an ordinary ArchLinux on my Pis. No “trimming” involved there... ---------------------------------------------------------------------- dbannon · 2024-04-19 05:02 Quote from: VisualLab on April 16, 2024, 09:41:40 pmThe RPi Foundation specially "trimmed" and adapted Linux (Raspberry Pi OS) so that it could run on their board. I use a plain debian, works at least as well as the "trimmed" one. Most of the trimming the Foundation does is undesirable IMHO. But I would not see it as a desktop workstation replacement. However, thats not particularly relevant to the discussion, the ARM chips in Mac or those silly Surface things are far more powerful than the RasPi chips, they don't boot off a SDCard, they have decent  NVMe 'disks' attached, serious graphics hardware. So, I think the OP's original question is valid. We support an Alpha chip running Tru64 but not the hardware/software combo anyone can buy in their local (computer) shops today ? Makes me want to ask that question that will earn me a rebuke, is FPC development in trouble ? While Lazarus is booming ahead, FPC promised us a 3.2.4 release "soon" back in October 2021. Davo ---------------------------------------------------------------------- msintle · 2024-04-19 16:28 Quote from: dbannon on April 19, 2024, 07:02:55 amQuote from: VisualLab on April 16, 2024, 09:41:40 pmSo, I think the OP's original question is valid. We support an Alpha chip running Tru64 but not the hardware/software combo anyone can buy in their local (computer) shops today ? Thank you for the support and putting it in better terms than I ever could. ---------------------------------------------------------------------- msintle · 2024-04-19 16:42 Quote from: Wallaby on April 17, 2024, 10:25:46 pmQuote from: msintle on April 17, 2024, 04:12:52 pmNice to see everyone has plenty of love for their favorite operating systems Can we get back on track - what needs to be done to fix FPC so larger apps like Lazarus can be compiled successfully for aarch64 on Windows? Indeed  From my experience with the trunk compiler, it works in principle for simple programs, but there are two showstopper bugs I have reported: Win64 AArch64 optimizer bug and Win64 AArch64 exception handling I already offered to pay anyone in the FPC team who is able to fix those issues (aka offer a bounty), but so far looks like no one is interested. Was there a pre-set dollar value attached to those bounties? If there's a value where this would make sense and justify the - I'm sure excruciatingly painful - work involved, I could take it up with my employer, too. ---------------------------------------------------------------------- Wallaby · 2024-04-19 20:52 Quote from: msintle on April 19, 2024, 06:42:18 pmWas there a pre-set dollar value attached to those bounties? If there's a value where this would make sense and justify the - I'm sure excruciatingly painful - work involved, I could take it up with my employer, too. I think last time, a year ago, I offered $300 US for each with a possibility of increase if it's difficult and takes a lot of time. Yet, it seems no one is interested. ---------------------------------------------------------------------- msintle · 2024-04-20 14:42 Quote from: Wallaby on April 19, 2024, 10:52:25 pmQuote from: msintle on April 19, 2024, 06:42:18 pmWas there a pre-set dollar value attached to those bounties? If there's a value where this would make sense and justify the - I'm sure excruciatingly painful - work involved, I could take it up with my employer, too. I think last time, a year ago, I offered $300 US for each with a possibility of increase if it's difficult and takes a lot of time. Yet, it seems no one is interested. Where is the place to offer such bounties? I would like to propose higher amounts and see if anyone bites. ---------------------------------------------------------------------- TRon · 2024-04-20 18:47 Not that for most (existing) developers money isn't a motivation. It has more to do with interest and schedule. Most developers have heaps of work in front of them already and although money is able to change/influence priorities most do not care about that. ---------------------------------------------------------------------- dsiders · 2024-04-20 18:51 Quote from: msintle on April 20, 2024, 04:42:43 pmWhere is the place to offer such bounties? I would like to propose higher amounts and see if anyone bites. Look to your left. Use the Foundation website link. ---------------------------------------------------------------------- rvk · 2024-04-20 19:59 Or just search bounty fpc. It's the first link. https://wiki.lazarus.freepascal.org/Bounties ---------------------------------------------------------------------- PascalDragon · 2024-04-21 19:18 Quote from: TRon on April 20, 2024, 08:47:02 pmNot that for most (existing) developers money isn't a motivation. It has more to do with interest and schedule. Most developers have heaps of work in front of them already and although money is able to change/influence priorities most do not care about that. Correct. I don't care about bounties. If I don't have the motivation/time to work on something I don't have the motivation/time and that is simply not up for discussion. I work on FPC, because I want and not because someone else wants me to work on it. ---------------------------------------------------------------------- mas steindorff · 2024-04-21 19:52 Quote from: rvk on April 20, 2024, 09:59:58 pmOr just search bounty fpc. It's the first link. https://wiki.lazarus.freepascal.org/Bounties this page was last updated in summer of 2022.  is it still the main bounty page? (I did not do a search) ---------------------------------------------------------------------- msintle · 2024-04-23 15:17 Quote from: PascalDragon on April 21, 2024, 09:18:49 pmQuote from: TRon on April 20, 2024, 08:47:02 pmNot that for most (existing) developers money isn't a motivation. It has more to do with interest and schedule. Most developers have heaps of work in front of them already and although money is able to change/influence priorities most do not care about that. Correct. I don't care about bounties. If I don't have the motivation/time to work on something I don't have the motivation/time and that is simply not up for discussion. I work on FPC, because I want and not because someone else wants me to work on it. +1 Do you have any ideas on how to reach people who are both competent in FPC and excited about the aarch64 Windows transition? ---------------------------------------------------------------------- msintle · 2024-04-23 15:32 I've also launched this job at Upwork: https://www.upwork.com/jobs/~017b8f1ec5e0058846 As an interim solution to figuring out where the right bounty is to be offered. ---------------------------------------------------------------------- Wallaby · 2024-04-23 21:46 Quote from: msintle on April 23, 2024, 05:32:42 pmI've also launched this job at Upwork: https://www.upwork.com/jobs/~017b8f1ec5e0058846 As an interim solution to figuring out where the right bounty is to be offered. Thanks for pursuing this! Hopefully someone skilled will respond and get the job done. It might be worth to mention the job in the dev mailing list list, so that the core developers notice it: https://lists.freepascal.org/pipermail/fpc-devel/ ---------------------------------------------------------------------- msintle · 2024-04-24 15:03 Here's a fresh article from today about Windows on ARM: https://arstechnica.com/gadgets/2024/04/is-the-arm-version-of-windows- ready-for-its-close-up/ ---------------------------------------------------------------------- msintle · 2024-05-15 12:52 Here's another article from mainstream media (read: advertising outlet for manufacturers) regarding upcoming devices: www.theverge.com/2024/5/15/24157120/dell-windows-on-arm-leak-qualcomm- chips-battery-life This really is Lazarus's chance to one-up Delphi (which also lacks an ARM64 Win32 compiler) and make huge strides into mindshare - an opportunity that would not be repeated for decades, quite literally! ---------------------------------------------------------------------- Wallaby · 2024-05-21 12:41 and Microsoft releases new ARM64 devices that are supposed to be as fast as Apple laptops. Hopefully we can start making ARM64 apps soon with Lazarus. ---------------------------------------------------------------------- CuriousKit · 2024-05-28 06:28 I've got one of the bugs fixed for you chaps! https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/691 I'm taking a look at the next one, which I predict is going to be a bit more complex. ---------------------------------------------------------------------- DonAlfredo · 2024-05-28 07:20 Good work. Thanks !! ---------------------------------------------------------------------- CuriousKit · 2024-05-28 13:41 No problem - glad to help.  Onto the next puzzle. ---------------------------------------------------------------------- DonAlfredo · 2024-05-28 14:56 I have some small fixes for this target too. Will share them with you when my time permits. ---------------------------------------------------------------------- msintle · 2024-05-31 11:17 Quote from: CuriousKit on May 28, 2024, 08:28:03 amI've got one of the bugs fixed for you chaps! https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/691 I'm taking a look at the next one, which I predict is going to be a bit more complex. Thank you so much for this, and also confirming receipt of the bug bounty (and your patience with the prolonged payout process)! Looking forward to your nailing the other fix - so we can fully erect Lazarus on aarch64 for Win32!!! ---------------------------------------------------------------------- Igor · 2024-06-08 16:29 Hi, Thanks for the recent improvements with fpc for win11/aarch64! Please can you remind me a link to any page where described current status of Win/aarch64 for FPC/Lazarus? I recently installed Windows 11 ARM64 on my Mac mini M1 via Parallels Desktop. Can I try to compile a console app with a target win/aarch64? ---------------------------------------------------------------------- Wallaby · 2024-06-11 06:18 I don't believe there is any page describing the current state of things. In short, simple console programs that don't use exceptions compiled for win64-aarch64 work fine. That using the trunk compiler. You can use fpcupdeluxe to cross-compile from macOS or Windows, but be sure to install the correct cross-compiler in fpcupdeluxe. ---------------------------------------------------------------------- Igor · 2024-06-14 17:39 Wallaby, Thanks for your reply! I use exceptions in my apps, so I guess that it can be a problem with current trunk compiler aarch64. ---------------------------------------------------------------------- abouchez · 2024-06-28 09:16 I just looked at the current state of the FPC trunk, and some preliminary win64-aarch64 exception support do actually exist in rtl\win64 since 4 years. https://gitlab.com/freepascal.org/fpc/source/- /commit/4e06d66d7fb98e634e4e86a1d43f3856da429fec https://gitlab.com/freepascal.org/fpc/source/- /commit/4236bee6f1832b11845869ffe99cb8ea0a96a230 My guess is that this is pretty much not debugged, but the RTL was made ready to support win64-aarch64. Since my company need this, I will try to look into this in the next weeks. ---------------------------------------------------------------------- abouchez · 2024-06-28 09:18 Quote from: DonAlfredo on May 28, 2024, 04:56:49 pmI have some small fixes for this target too. Will share them with you when my time permits. Can you share it with me, please, Alfred? ---------------------------------------------------------------------- DonAlfredo · 2024-06-28 12:13 I hope you will succeed in getting FPC working on Win64Arm !! Seems all patches are lost unfortunately. The USB-stick is gone. However, I remember some of it. All related to the data-structures in rtl\win64\seh64.inc Comparing the definitions in winnt.h and seh64.inc, some (small) deviations can be found. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i   KNONVOLATILE_CONTEXT_POINTERS=record    IntegerContext: array[0..12] of PQWord; <------------------ arm64 : 11 and not 12    FloatingContext: array[0..7] of PM128A;  end;  I did some work on the exception handling, but again, the work is lost unfortunately. The small things above are all that I could recover (from memory). ---------------------------------------------------------------------- abouchez · 2024-06-28 16:41 Thanks @DonAlfredo for the feedback. I will try to follow your indications. I have found a general - old but still accurate - guide to SEH at https://www-user.tu-chemnitz.de/~heha/hsn/chm/Win32SEH.chm If anyone else as some additional input, you are welcome to react here! ---------------------------------------------------------------------- abouchez · 2024-07-01 12:58 Here is what I fixed so far: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i c:\fpcupdeluxe\fpcsrc\rtl\win64>git diff seh64.incdiff --git a/rtl/win64/seh64.inc b/rtl/win64/seh64.incindex 774cc2bbc9..28281152ab 100644--- a/rtl/win64/seh64.inc+++ b/rtl/win64/seh64.inc@@ -158,8 +158,8 @@   TContext = record   { This is a simplified definition, only array part of unions }   PKNONVOLATILE_CONTEXT_POINTERS=^KNONVOLATILE_CONTEXT_POINTERS;   KNONVOLATILE_CONTEXT_POINTERS=record-    IntegerContext: array[0..12] of PQWord;-    FloatingContext: array[0..7] of PM128A;+    IntegerContext: array[0..11] of PQWord; // X19..X28 + Fp + Lr+    FloatingContext: array[0..7] of PM128A; // D8..D15   end; {$endif NOT (X86_64 or AARCH64)} @@ -181,12 +181,12 @@   TExceptionPointers = record   RUNTIME_FUNCTION=record     BeginAddress: DWORD;     EndAddress: DWORD;-    UnwindData: DWORD;+    UnwindData: DWORD; // or UnwindInfoAddress   end; {$elseif defined(CPUAARCH64)}   RUNTIME_FUNCTION=record     BeginAddress: DWORD;-    UnwindData: DWORD;+    UnwindData: DWORD; // or Flag(2) Len(11) RegF(3) RegI(4) H(1) CR(2) FSize(9)   end; {$endif} @@ -224,6 +224,7 @@   TDispatcherContext = record {$elseif defined(CPUAARCH64)}     ControlPCIsUnwound: Byte;     NonVolatileRegisters: PByte;+    Reserved: DWord; {$endif}   end; I don't know if it is enough, but at least now it matches winnt.h definitions. ---------------------------------------------------------------------- Wallaby · 2024-07-02 03:22 It looks like apart from the wrong size of KNONVOLATILE_CONTEXT_POINTERS, the real issue is that the compiler generates incorrect unwinding information and when an exception occurs Windows cannot unwind the stack and call exception handlers. I have updated my bug report accordingly. ---------------------------------------------------------------------- msintle · 2024-07-02 23:52 Quote from: Wallaby on July 02, 2024, 05:22:19 amIt looks like apart from the wrong size of KNONVOLATILE_CONTEXT_POINTERS, the real issue is that the compiler generates incorrect unwinding information and when an exception occurs Windows cannot unwind the stack and call exception handlers. I have updated my bug report accordingly. @CuriousKit, does this help? ---------------------------------------------------------------------- msintle · 2024-07-17 16:08 Still going I figure? Dang, this is a biggie it seems!!! ---------------------------------------------------------------------- Wallaby · 2024-07-17 22:19 Looks like @CuriousKit didn't have time to look into this lately. You can see work in progress here. ---------------------------------------------------------------------- msintle · 2024-11-06 12:23 Any luck with this? Would a boost of the bug bounty be motivating? ---------------------------------------------------------------------- Wallaby · 2024-11-06 12:50 As far as I can tell @CuriousKit was unable to figure out why it's not working, and whoever can figure it out, is not interested :-( ---------------------------------------------------------------------- msintle · 2024-11-06 13:22 But failure is not an option!!! We simply need to figure this out - or Lazarus will never support aarch64 Windows, already a growth platform! ---------------------------------------------------------------------- Thaddy · 2024-11-06 13:33 Windows AARCH64 is simply not supported.. Yet. It seems also very difficult to order such a device over here. So it may be even an abandonware device. Linux works perfectly good on AARCH64, as reportedly M Apples with some glitches. I can only confirm or deny after my newly ordered mini is delevered. i have no intention ordering an MS variant too. ---------------------------------------------------------------------- msintle · 2024-11-06 13:37 Happy to ship an M3 Supermax to whomever is willing to fix this bug, as long as their country is not one that is a restricted shipping destination due to lithium ion battery regulations. To clarify, the device is an M3 Max 16" MacBook Pro in its original shrinkwrap, 128 GB / 8 TB / 40 GPU cores (hence, "Supermax"). Sadly it has just been rendered obsolete with the imminent availability of the M4 Supermax, alas some things we just have to live with, don't we? 100% serious offer. ---------------------------------------------------------------------- msintle · 2024-11-06 13:39 Quote from: Thaddy on November 06, 2024, 02:33:02 pmWindows AARCH64 is simply not supported.. Yet. It seems also very difficult to order such a device over here. So it may be even an abandonware device. Linux works perfectly good on AARCH64, as reportedly M Apples with some glitches. I can only confirm or deny after my newly ordered mini is delevered. i have no intention ordering an MS variant too. Just install Windows 11 aarch64 on your mini when it arrives, using free VMware or (possibly pirated) paid Parallels. Wow, that's 4 pee's in a row! ---------------------------------------------------------------------- Thaddy · 2024-11-06 13:46 Quote from: msintle on November 06, 2024, 02:39:10 pmJust install Windows 11 aarch64 on your mini when it arrives, using free VMware or (possibly pirated) paid Parallels. Wow, that's 4 pee's in a row! I don't do pirated software for some 30 years or so, but yes, I did that in the past. One remark: on Apple parallels still does the job, why would anybody want vmware? it has lost its purpose. ---------------------------------------------------------------------- msintle · 2024-11-06 13:49 Quote from: Thaddy on November 06, 2024, 02:46:14 pmQuote from: msintle on November 06, 2024, 02:39:10 pmJust install Windows 11 aarch64 on your mini when it arrives, using free VMware or (possibly pirated) paid Parallels. Wow, that's 4 pee's in a row! I don't do pirated software for some 30 years or so, but yes, I did that in the past. One remark: on Apple parallel still does the job, why would anybody wants vmware? it has lost its purpose. Sadly VMware is measurably worse on Apple aarch64 (slower in benchmarks - both 3D and CPU); alas Parallels is a subscription product, whereas VMware is legally 100% free (also, the performance differential is more like 10%). Note that since the Broadcom acquisition, VMware seems poised to make a nosedive on non-Apple platforms, too (because they're jacking up prices a gazillion percent). So sad, the looming fall of a titan. ---------------------------------------------------------------------- dieselnutjob · 2024-11-06 13:55 a question and some answers about running Windows on an M1 Mac here:- https://forums.macrumors.com/threads/windows-for-arm-on-m1-macbook- air.2433481/ There is also UTM https://mac.getutm.app/ I have no idea with it's good enough to replace Parallels ---------------------------------------------------------------------- msintle · 2024-11-06 20:39 Quote from: dieselnutjob on November 06, 2024, 02:55:10 pma question and some answers about running Windows on an M1 Mac here:- https://forums.macrumors.com/threads/windows-for-arm-on-m1-macbook- air.2433481/ There is also UTM https://mac.getutm.app/ I have no idea with it's good enough to replace Parallels UTM's kind of a nutcase compared to the established enterprises, for example their existing VM samples don't even work out of the box most of the time; something I consider scandalous. VMware's far better than it for sure, I didn't benchmark UTM but pretty sure it may result in very disappointing scores. Ultimately they all use Apple's own mandated virtualization framework on Apple Silicon for some stuff or the other, so it's all a farce in the aarch64 macOS era. ---------------------------------------------------------------------- PascalDragon · 2024-11-07 22:16 Quote from: Thaddy on November 06, 2024, 02:33:02 pmWindows AARCH64 is simply not supported.. Yet. It is supported. It just has some critical bugs that make it unusable as of now. Quote from: Thaddy on November 06, 2024, 02:33:02 pmIt seems also very difficult to order such a device over here. So it may be even an abandonware device. Did you even search? Googling for “Windows ARM Laptops” brings quite some result of various Snapdragon based laptops. (Though they have the tendency to be nearly as expensive as Apple MacBooks... 🙄) Quote from: msintle on November 06, 2024, 02:37:09 pmHappy to ship an M3 Supermax to whomever is willing to fix this bug, as long as their country is not one that is a restricted shipping destination due to lithium ion battery regulations. To clarify, the device is an M3 Max 16" MacBook Pro in its original shrinkwrap, 128 GB / 8 TB / 40 GPU cores (hence, "Supermax"). Sadly it has just been rendered obsolete with the imminent availability of the M4 Supermax, alas some things we just have to live with, don't we? 100% serious offer. If I would have the time I would be quite tempted by this... But that would still have the problem to have Windows running in a usable simulation environment. And as it seems that solutions like UTM are essentially QEMU and KVM seems to not be working correctly on either UTM or Asahi Linux according to various sources (thus meaning bad performance) I can just as well use the Pi 4 I have (where KVM does work by the way) or lend the Windows Dev Kit 2023 from my workplace... ---------------------------------------------------------------------- Wallaby · 2024-11-07 23:21 Quote from: PascalDragon on November 07, 2024, 11:16:47 pmIf I would have the time I would be quite tempted by this... But that would still have the problem to have Windows running in a usable simulation environment. And as it seems that solutions like UTM are essentially QEMU and KVM seems to not be working correctly on either UTM or Asahi Linux according to various sources (thus meaning bad performance) I can just as well use the Pi 4 I have (where KVM does work by the way) or lend the Windows Dev Kit 2023 from my workplace... Sorry to hear that you don't have any time to look into this :-( But if you ever do, there is only one critical bug remaining, as far as I can tell. The compiler appears to write incorrect SEH data into Windows aarch64 EXEs. By the way, this bug is easily reproducible by running a simple console program from the bug report under Wine on Pi 4. ---------------------------------------------------------------------- dieselnutjob · 2024-11-08 13:11 This looks interesting, but no activity for some time https://github.com/amarioguy/AppleWOAProject/blob/gh-pages/index.md ---------------------------------------------------------------------- msintle · 2024-11-08 15:04 Quote from: PascalDragon on November 07, 2024, 11:16:47 pmIf I would have the time I would be quite tempted by this... But that would still have the problem to have Windows running in a usable simulation environment. And as it seems that solutions like UTM are essentially QEMU and KVM seems to not be working correctly on either UTM or Asahi Linux according to various sources (thus meaning bad performance) I can just as well use the Pi 4 I have (where KVM does work by the way) or lend the Windows Dev Kit 2023 from my workplace... Simulation? You'll have Windows 11 on ARM64 running flawlessly, even including GPU acceleration, legally and for free using VMware Fusion. This will be super fast (almost as fast as the paid Parallels) as VMware Fusion still is a very highly performant hypervisor. Take it while you can, I'd say. In fact, on this M3 Supermax, your virtualized Windows could run faster (and will certainly have more memory) than native Microsoft or other vendor Snapdragon hardware (none go to 128 GB RAM, and the RAM is all soldered, so utterly non-upgradeable). ---------------------------------------------------------------------- Wallaby · 2024-11-10 02:17 Fingers crossed, but the latest changes appear to have fixed the exception handling! We may be able to compile for win64-aarch64 soon! I have tested my program from #40203 and it now produces the expected output! Thank you soooo much @PascalDragon! ---------------------------------------------------------------------- DonAlfredo · 2024-11-10 08:01 Can confirm the good news !! I can now run a cross-compiled version of fpcupdeluxe natively on arm64 Windows !! ---------------------------------------------------------------------- PascalDragon · 2024-11-11 18:47 Hold your horses, please. As long as a cross compiled compiler is not able to compile itself I'm not going to trust the code... (and that is not working correctly currently) ---------------------------------------------------------------------- msintle · 2024-11-14 10:29 Unfortunately the M3 Supermax has been repurposed at our end. We still do have a Starlight M3 Air 15.3" 2 TB 24 GB available as a bounty for the eventual resolution of this problem. Please note battery shipping restrictions still apply as they are immutable at courier's end. ---------------------------------------------------------------------- abouchez · 2024-11-19 14:58 I have modified mORMot to compile on this target. I can run mormot.core.base and mormot.core.os and retrieve some system information: Code: [Select]admin@ARM64-WIN C:\Users\Admin\Documents>winarm Run mORMot 2.3.8892 with Free Pascal 3.3.1 64 bit OSVersionText=Windows 11 24H2 (10.0.26100.2314) CpuInfoText=4 x Apple Silicon [12MB] (aarch64) CpuCacheText=L1=4*128KB  L2=12MB BiosInfoText=Parallels International GmbH. Parallels ARM Virtual Machine 0.1    ToTextOS=Windows 11 26100 ahcAES ahcCRC32 ahcSHA1 But when mormot.core.unicode initializes, then there is a "try..finally" block with an "exit" which does not call the "finally" block. So execution can't go any further. And when I include all mormot units, then I have a linking issue: Code: [Select](9015) Linking /home/ab/dev/lib2/test/bin/fpc- aarch64-win64/mormot2tests.exe Error: (9221) Undefined symbol: MORMOT.DB.RAW.SQLITE3$_$TSQLREQUEST_$_ EXECUTE$h4ds6BRYEByO_$$_fin$00000282 (first seen in mormot.db.raw.sqlite3.o) Fatal: (10026) There were 1 errors compiling module, stoppingIt seems related to a missing "finally" block label. Perhaps somewhat related to the previous bug. Anyway, running mormot2tests with fpc is a good way to validate a target, especially about multi-threading abilities. The good news is that the Windows Arm64 is moving on FPC/Lazarus. We have pressure from some of our clients to compile some services to this system. Note that the French company I work for (TranquilIT) can also offer a bounty for any FPC core dev working on aarch64-win64 compatibility. You can ask me in a private message. ---------------------------------------------------------------------- Thaddy · 2024-11-19 18:29 Quote from: PascalDragon on November 07, 2024, 11:16:47 pmDid you even search? Googling for “Windows ARM Laptops” brings quite some result of various Snapdragon based laptops. (Though they have the tendency to be nearly as expensive as Apple MacBooks... 🙄) You did not read it right: I was searching for an M4 mac mini, which is not a laptop... which I get in a few days and that means I am lucky because that product has serious delivery issues. (At 700 euro, it is not that expensive for Apple gear, cheaper than the phones) I am not planning to run Windows on it. Although these laptops can be quite cheap, because, well, nobody orders them.. And for AARCH64 testing I have plenty of Raspberry pi's. I have been out of working mini's for over two years... :'( ---------------------------------------------------------------------- Wallaby · 2024-11-20 00:55 Quote from: abouchez on November 19, 2024, 03:58:09 pmBut when mormot.core.unicode initializes, then there is a "try..finally" block with an "exit" which does not call the "finally" block. So execution can't go any further. Thanks for your tests! I have further simplified the problematic code to: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program test; uses  Classes, SysUtils; begin  writeln('begin');  try    writeln('try');    exit;  finally    WriteLn('finally');  end;  WriteLn('end');end. It will print begin then try, but not finally. Apparently the exit statement isn't working correctly between try..finally. I have updated my bug report accordingly. ---------------------------------------------------------------------- PascalDragon · 2024-11-21 20:15 Quote from: Thaddy on November 19, 2024, 07:29:18 pmQuote from: PascalDragon on November 07, 2024, 11:16:47 pmDid you even search? Googling for “Windows ARM Laptops” brings quite some result of various Snapdragon based laptops. (Though they have the tendency to be nearly as expensive as Apple MacBooks... 🙄) You did not read it right: I was searching for an M4 mac mini, which is not a laptop... which I get in a few days and that means I am lucky because that product has serious delivery issues. Your message did not mention that you were only searching for a Mini, only that you ordered one: Quote from: Thaddy on November 06, 2024, 02:33:02 pmIt seems also very difficult to order such a device over here. So it may be even an abandonware device. Linux works perfectly good on AARCH64, as reportedly M Apples with some glitches. I can only confirm or deny after my newly ordered mini is delevered. ---------------------------------------------------------------------- msintle · 2024-12-07 15:33 Any good news here we can celebrate with the upcoming holidays? ---------------------------------------------------------------------- AlexTP · 2024-12-08 09:06 Sarah+Sven did some work on Win-aarch64. Now stack is correctly unwinding. IDK - it's full solution or not. ---------------------------------------------------------------------- Alexx2000 · 2024-12-08 19:14 I am periodically test it. I try to compile my project (Double Commander). I am still got a several errors (with the current compiler version from git main branch). Compiler exception: QuoteX:\Projects\doublecmd\src\.\platform\udcversion.pas(322,31) Error: (1026) Compilation raised exception internally Fatal: (1018) Compilation aborted An unhandled exception occurred at $0040EDD3: EAccessViolation: Access violation   $0040EDD3   $004D1C2F Compiler internal error: Quoteuorderedfileview.pas(458,11) Error: Internal error 200108231 If I comment a "problem" code then I got a linking errors: QuoteError: Undefined symbol: MTPROCS$_$TPROCTHREADPOOL_$_DOPARALLELIN TERN$hle0qQKJsCMD_$$_fin$0000005A (first seen in mtprocs.o) Error: Undefined symbol: MTPROCS$_$TPROCTHREADPOOL_$_DOPARALLELINTERN$ hle0qQKJsCMD_$$_fin$0000005B (first seen in mtprocs.o) Error: Undefined symbol: USHOWFORM$_$TWAITDATADOUBLE_$_DONE_$$_fin$00000067 (first seen in ushowform.o) Error: Undefined symbol: UFILESYSTEMSPLITOPERATION$_$TFILESYSTEMSPLITO PERATION_$_MAINEXECUTE_$$_fin$00000030 (first seen in ufilesystemsplitoperation.o) Error: Undefined symbol: UFILEVIEWWORKER$_$TFILELISTBUILDER_$_EXECUTE_$$_fin$00000069 (first seen in ufileviewworker.o) Error: Undefined symbol: UFILEVIEWWORKER$_$TCALCULATESPACEWORKER_$_EXECUTE_$$_fin$0000007B (first seen in ufileviewworker.o) Error: Undefined symbol: FMULTIRENAME$_$TFRMMULTIRENAME_$_CM_RENAME$ar ray_of_ANSISTRING_$$_fin$00000236 (first seen in fmultirename.o) ---------------------------------------------------------------------- msintle · 2024-12-09 00:53 Thanks for the feedback. This certainly seems far more involved than it initially appeared to be! Is there anything we can do at our end to help triage the latest issues encountered by Double Commander, obviously a fantastic real world project to test things with? ---------------------------------------------------------------------- PascalDragon · 2024-12-09 20:21 Quote from: msintle on December 09, 2024, 01:53:20 amIs there anything we can do at our end to help triage the latest issues encountered by Double Commander, obviously a fantastic real world project to test things with? FPC itself is already a very good “real world project” with the next one on the list being Lazarus. ---------------------------------------------------------------------- msintle · 2024-12-14 01:33 Quote from: PascalDragon on December 09, 2024, 09:21:38 pmQuote from: msintle on December 09, 2024, 01:53:20 amIs there anything we can do at our end to help triage the latest issues encountered by Double Commander, obviously a fantastic real world project to test things with? FPC itself is already a very good “real world project” with the next one on the list being Lazarus. Absolutely no doubt, if not overkill! ---------------------------------------------------------------------- PascalDragon · 2024-12-14 14:32 Quote from: msintle on December 14, 2024, 02:33:01 amAbsolutely no doubt, if not overkill! The point is, building the compiler is intrinsicly part of building the whole FPC distribution, so verifying that it works comes with no additional cost. ---------------------------------------------------------------------- msintle · 2024-12-20 16:12 Quote from: PascalDragon on December 14, 2024, 03:32:02 pmQuote from: msintle on December 14, 2024, 02:33:01 amAbsolutely no doubt, if not overkill! The point is, building the compiler is intrinsicly part of building the whole FPC distribution, so verifying that it works comes with no additional cost. Sure, and my goal is to keep this effort moving forward; which is why I'd asked for a simpler test case to begin with. ---------------------------------------------------------------------- msintle · 2025-09-01 12:58 Please be advised we are now able to offer a new bounty for this project. An M3 "Submax" Apple laptop - 4 TB storage, 96 GB RAM, Space Black color, M3 Max CPU (30 GPU cores). ---------------------------------------------------------------------- msintle · 2025-09-13 14:10 Has this effort been abandoned? ---------------------------------------------------------------------- msintle · 2025-09-13 17:39 We've upped the CASH bonus for this bug to $1,000: https://www.upwork.com/jobs/~021966919458128686252 And posted it as a gig above ^ ^ Edit: Would somebody care to post this at the FPC mailing list, too? ---------------------------------------------------------------------- AlexTP · 2025-09-14 12:48 @msintle I posted this bounty suggestion to FPC mailing list. Delivered. ---------------------------------------------------------------------- msintle · 2025-09-14 18:16 Many thanks!!! ---------------------------------------------------------------------- PascalDragon · 2025-09-14 18:33 Quote from: msintle on September 13, 2025, 04:10:59 pmHas this effort been abandoned? No, it's just that there are things that have higher priority, they are called "living a life". ---------------------------------------------------------------------- msintle · 2025-09-15 11:11 Quote from: PascalDragon on September 14, 2025, 08:33:44 pmQuote from: msintle on September 13, 2025, 04:10:59 pmHas this effort been abandoned? No, it's just that there are things that have higher priority, they are called "living a life". Oh, do you suppose the rest of us don't have anything else to worry about, are dependably raking in billions from our dozens of fully automated and diversified enterprises, hosting supermodels on our mega yachts (when we're too bothered with setting foot on any of our mega mansions sprouted on every continent of the planet connected with our 100 million private jets); with Lazarus as a hobby on the side, or an academic/archeological interest perhaps? I suppose we owe you a "thanks" for having such a high view of us So thank you ---------------------------------------------------------------------- marcov · 2025-09-15 15:24 Can we all dial down the sarcasm please? ---------------------------------------------------------------------- DonAlfredo · 2025-09-16 09:25 It is very nice of you to offer a bounty to fully implement this target. I hope that somebody capable will be able to do this. ---------------------------------------------------------------------- msintle · 2025-09-16 10:59 Quote from: DonAlfredo on September 16, 2025, 11:25:09 amIt is very nice of you to offer a bounty to fully implement this target. I hope that somebody capable will be able to do this. Many thanks for your support! It is greatly appreciated. ---------------------------------------------------------------------- DonAlfredo · 2025-09-16 12:15 I have asked a (very smart) AI to look into FPC. It detected all "recent" changes regarding Windows ARM64. And came up with some (seemingly good) advice (and actual code suggestions) about prologues, epilogues and stack unwinding. If time permits, I will dive (a small bit) into. ---------------------------------------------------------------------- Wallaby · 2025-09-16 12:23 I've been testing this myself and here are my findings so far. The following code behaves as expected on Win64 x86_64: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program test;     uses  Classes, SysUtils;     begin  writeln('begin');  try  writeln('try');    exit;  finally    WriteLn('finally');  end;  WriteLn('end');end.  On Win64 AArch64, however, it only prints "begin" and "try". The "finally" block is skipped, which suggests that the exit statement isn’t working correctly. Since exit should trigger the finally block, this is clearly an issue. The root cause seems related to the missing implementation of g_local_unwind in compiler/aarch64/cgcpu.pas, though there are other dependencies: 1) In compiler/options.pas, enabling FPC_USE_WIN64_SEH for system_aarch_win64 activates _FPC_local_unwind.  2) I added a Win64-specific g_local_unwind override to the AArch64 code generator so that Windows ARM64 builds can hook custom unwinding: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i procedure tcgaarch64.g_local_unwind(list: TAsmList; l: TAsmLabel);var  para1, para2: tcgpara;  href: treference;  pd: tprocdef;begin  if target_info.system<>system_aarch64_win64 then    begin      inherited g_local_unwind(list,l);      exit;    end;  pd:=search_system_proc('_fpc_local_unwind');  para1.init;  para2.init;  paramanager.getcgtempparaloc(list,pd,1,para1);  paramanager.getcgtempparaloc(list,pd,2,para2);  reference_reset_symbol(href,l,0,1,[]);  a_load_reg_cgpara(list,OS_ADDR,NR_STACK_POINTER_REG,para1);  a_loadaddr_ref_cgpara(list,href,para2);  paramanager.freecgpara(list,para2);  paramanager.freecgpara(list,para1);  g_call(list,'_FPC_local_unwind');  para2.done;  para1.done;end;  With this change, the program now correctly prints "finally" — but unfortunately crashes immediately afterwards. ---------------------------------------------------------------------- DonAlfredo · 2025-09-16 12:27 Nice ! I guess it takes many steps like this to reach our goal. Good to work together. ---------------------------------------------------------------------- msintle · 2025-09-16 14:17 So happy to see we have precipitated some progress! ---------------------------------------------------------------------- msintle · 2025-09-20 15:21 Job is still open and accepting bids for anyone who would like to give it a go! ---------------------------------------------------------------------- msintle · 2025-09-30 14:52 Good news, everyone! My company is now sponsoring CoPilot credits for this repo: https://github.com/InstallAware-Software/FPCSource The goal of this repo, forked from the original, is for everyone to contribute - so we can get aarch64 Windows support in FPC/Lazarus working, for once and for all! - Community effort. - Anyone can join. - Free beers upon success! Join now, get free CoPilot access, and let's ship this thing!!! ---------------------------------------------------------------------- DonAlfredo · 2025-09-30 15:27 That sounds good and interesting ! I have joined. Lets see how AI and some people willing to spend some time and effort can reach. Thanks !! ---------------------------------------------------------------------- DonAlfredo · 2025-10-03 08:25 Success !!! Fpcupdeluxe is now running native on Win64/ARM64 !! See included screenshot. Will follow up with Lazarus. ---------------------------------------------------------------------- Thaddy · 2025-10-03 09:10 Quite some achievement. Congrats! (Wonder where you got the hardware, though: here it is prohibitly - to me, more  expensive than Apple - expensive for what it  offers. (nl).) ---------------------------------------------------------------------- msintle · 2025-10-03 10:16 Quote from: DonAlfredo on October 03, 2025, 10:25:38 amSuccess !!! Fpcupdeluxe is now running native on Win64/ARM64 !! See included screenshot. Will follow up with Lazarus. Congratulations!!! ---------------------------------------------------------------------- msintle · 2025-10-03 10:16 Quote from: Thaddy on October 03, 2025, 11:10:56 amQuite some achievement. Congrats! (Wonder where you got the hardware, though: here it is prohibitly - to me, more  expensive than Apple - expensive for what it  offers. (nl).) If you are able to afford Macs, just use a Windows 11 aarch64 VM inside your Mac. Creating Windows aarch64 VMs (via Hyper-V) inside native Windows 11 aarch64 (running on bare metal aarch64 hardware) is actually substantially harder (and a far worse user experience) than running Windows 11 aarch64 VMs on Mac "Apple Silicon" hardware. ---------------------------------------------------------------------- Thaddy · 2025-10-03 11:00 You know I have M4 hardware... ---------------------------------------------------------------------- msintle · 2025-10-03 13:58 Quote from: Thaddy on October 03, 2025, 01:00:21 pm You know I have M4 hardware... Then you are good to go! Just use VMware or Parallels - and your hypervisored Windows 11 will run as competitively fast (even with GPU support) as running Windows 11 on bare metal! ---------------------------------------------------------------------- DonAlfredo · 2025-10-03 14:21 Update FPC. I have just build a brand new FPC trunk compiler on windows arm64 itself !! Used a cross-compiled bootstrapper. Working flawless. Update Lazarus. Lazarus has many many things like this: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i     {$ifdef cpui386}    with TDbgWinThread(AThread).FCurrentContext^.def do DebugLn(Format('DS: 0x%x, ES: 0x%x, FS: 0x%x, GS: 0x%x', [SegDs, SegEs, SegFs, SegGs]));    {$else}    with TDbgWinThread(AThread).FCurrentContext^.def do DebugLn(Format('SegDS: 0x%4.4x, SegES: 0x%4.4x, SegFS: 0x%4.4x, SegGS: 0x%4.4x', [SegDs, SegEs, SegFs, SegGs]));    {$endif} So, Lazarus assumes that anything other than win32 (i386) is x86_64 on Windows. Now that FPC works well on Windows ARM64, this needs change. Any Lazarus devs out there willing to assist ? Its a lot of work. ---------------------------------------------------------------------- AlexTP · 2025-10-03 14:38 Main problem of FPC on win64-aarch64 were non working exceptions, as I understand. Is it fixed? ---------------------------------------------------------------------- DonAlfredo · 2025-10-03 14:46 Nothing fixed. All was there already !! All gory ARM64-details were already implemented by the FPC devs. Just a very small alignment issue regarding threadvars. https://gitlab.com/freepascal.org/fpc/source/-/issues/41428 Not easy to spot and find I must say ... ;-) ---------------------------------------------------------------------- AlexTP · 2025-10-03 14:50 Great findings! Thank you very much, I wait when I can make my text editor for win64-arm64. ---------------------------------------------------------------------- Fred vS · 2025-10-03 17:43 Quote from: DonAlfredo on October 03, 2025, 10:25:38 amSuccess !!! Fpcupdeluxe is now running native on Win64/ARM64 !! See included screenshot. Will follow up with Lazarus. Wow congratulation champion! Has anyone ever been able to install Windows 10/11 on an RPi (3 if possible)? If so, any comments on how to install it are welcome? Similarly, how to install FPC on RPi/Windows. ---------------------------------------------------------------------- Thaddy · 2025-10-03 17:56 Quote from: Fred vS on October 03, 2025, 07:43:31 pmHas anyone ever been able to install Windows 10/11 on an RPi (3 if possible)? If so, any comments on how to install it are welcome? 3 is probably a bit too low, although technically it might work since Linux's are all running fine. But no, I did not try that yet, although the Raspberry Pi  foundation has warm connections with Microsoft, so who knows? ---------------------------------------------------------------------- Fred vS · 2025-10-03 21:56 Quote from: Thaddy on October 03, 2025, 07:56:57 pmQuote from: Fred vS on October 03, 2025, 07:43:31 pmHas anyone ever been able to install Windows 10/11 on an RPi (3 if possible)? If so, any comments on how to install it are welcome? 3 is probably a bit too low, although technically it might work since Linux's are all running fine. But no, I did not try that yet, although the Raspberry Pi  foundation has warm connections with Microsoft, so who knows? I suppose that Windows 11 on RPi 4/5 is playable. But it is precisely on an RPi 3 that I would like to see if Windows 11 aarch64 (helped by its immense and powerful staff) does as well on Linux/FreeBSD/OpenBSD for aarch64 (which work correctly on RPi 3). ---------------------------------------------------------------------- DonAlfredo · 2025-10-04 15:22 Some Lazarus progress on Windows for ARM64 ... ---------------------------------------------------------------------- msintle · 2025-10-04 15:57 Quote from: DonAlfredo on October 04, 2025, 05:22:08 pmSome Lazarus progress on Windows for ARM64 ...  It would appear to me you have single-handedly claimed the $1,000 bonus we offered! Congratulations, Don Alfredo! Everyone at InstallAware Software is extremely excited by this development. ---------------------------------------------------------------------- DonAlfredo · 2025-10-04 16:02 It's just a proof of concept. I wanted to prove that Lazarus can be compiled and run successfully on ARM64/Win64. There is no debugger-backend. The LLDB backend has to be adapted to support Windows. As I said, lots of work. Better been done by the people who know all about Lazarus. ---------------------------------------------------------------------- msintle · 2025-10-04 16:27 Quote from: DonAlfredo on October 04, 2025, 06:02:45 pm It's just a proof of concept. I wanted to prove that Lazarus can be compiled and run successfully on ARM64/Win64. There is no debugger-backend. The LLDB backend has to be adapted to support Windows. As I said, lots of work. Better been done by the people who know all about Lazarus. Where can I install this version? Does it support COM for compiling shell extensions with? ---------------------------------------------------------------------- DonAlfredo · 2025-10-04 17:18 I am still testing with Lazarus. No downloads or installs yet. However. You might do this. Install FPC trunk and Lazarus trunk somewhere, lets say in a directory named "arm64". Next, make the FPC source-changes as described in the issue-report. Next, install a cross-compiler targeting windows-aarch64. Now you can cross-compile towards Win64/ARM64. Just for testing things. Start with hello world. Followed by a simple form. And slowly proceed. ---------------------------------------------------------------------- H₂SO₄ · 2025-10-06 17:54 Exception handling still seems broken (on trunk with changes from #41428 applied): Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program Test; {$mode objfpc}{$H+}{$inline off} function Condition(): Boolean;begin  Result := True;end; procedure Main();begin    WriteLn('Procedure [IN]');    try    WriteLn('Try [IN]');    if Condition() then Exit();    WriteLn('Try [OUT]');    finally    WriteLn('Finally [IN/OUT]');  end;   WriteLn('Procedure [OUT]');end; begin  Main();end. Expected output: Quote from: test-x86_64.exeProcedure [IN] Try [IN] Finally [IN/OUT] Actual output  (finally  block doesn't run): Quote from: test-aarch64.exeProcedure [IN] Try [IN] Edit: Applying @Wallaby's changes to enable  _fpc_local_unwind  also still behaves the same:  finally  is unwound and then the process crashes. ---------------------------------------------------------------------- PascalDragon · 2025-10-09 19:57 Quote from: Khrys on October 06, 2025, 07:54:32 pmException handling still seems broken (on trunk with changes from #41428 applied): Of course it's still broken, because nothing was fixed there. And that's the main reason why aarch64-win64 is currently considered not usable. ---------------------------------------------------------------------- Fred vS · 2025-10-10 18:31 Quote from: DonAlfredo on October 10, 2025, 08:25:59 pmI have solved the stack unwinding on Windows ARM64. See screenshot  You are simply The Best. ---------------------------------------------------------------------- DonAlfredo · 2025-10-10 18:36 Was too soon. Needs more testing. Sorry about this. Exception unwinding works as far as I can see right now. ---------------------------------------------------------------------- Fred vS · 2025-10-10 18:41 Quote from: DonAlfredo on October 10, 2025, 08:36:40 pmWas too soon. Needs more testing. Sorry about this. Exception unwinding works as far as I can see right now. OK, don't worry, you'll tame it and I stand by what I said in my previous post. ---------------------------------------------------------------------- DonAlfredo · 2025-10-10 18:43 Exceptions a bit working already. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program project1; {$mode objfpc}{$H+}{$inline off} uses  Classes, SysUtils; begin  WriteLn({$I %FPCTARGETOS%});  WriteLn({$I %FPCTARGETCPU%});   try    writeln('try 1');    raise EInOutError.Create('test');    writeln('try 2 (should not print)');  except    on e: exception do    begin      writeln('except');      WriteLn(E.Message);    end;  end;  writeLn('end');end. Result on ARM64/Win64. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Win64aarch64try 1excepttestend ---------------------------------------------------------------------- PascalDragon · 2025-10-11 16:37 Quote from: DonAlfredo on October 10, 2025, 08:43:58 pmExceptions a bit working already. That's the point. They work a bit. That's what I had originally tested when implementing them, but there are situations that I hadn't thought about and how I implemented exceptions back then simply is not compatible with that. So in quite some situations it will work but in others it will break in mysterious, puzzling ways. And as such it's simply not ready for prime time. ---------------------------------------------------------------------- DonAlfredo · 2025-10-12 04:03 You are right. But when I look at the compiler, I see that a tremendous amount of work has already been invested in arm64 for Windows. Not being able to make use of it is a pity. That is why I thought about giving it a try. But I am not able to solve the unwinding mystery unfortunately. I will give it another couple of days but I do not think I will be able to get it working. ---------------------------------------------------------------------- msintle · 2025-10-12 13:34 Quote from: PascalDragon on October 11, 2025, 06:37:08 pmQuote from: DonAlfredo on October 10, 2025, 08:43:58 pmExceptions a bit working already. That's the point. They work a bit. That's what I had originally tested when implementing them, but there are situations that I hadn't thought about and how I implemented exceptions back then simply is not compatible with that. So in quite some situations it will work but in others it will break in mysterious, puzzling ways. And as such it's simply not ready for prime time. Anything that we could do financially to contribute towards a reimplementation, maybe from the ground up, that would work properly in all scenarios? ---------------------------------------------------------------------- bbrx · 2025-10-15 15:39 Quote from: msintle on April 12, 2024, 03:24:27 pmHas any progress been made in getting Lazarus to work natively on ARM64 (aarch64) on Windows? This support exists for macOS and Linux, but is ironically absent on Windows; where Lazarus had originally started. Without native code, we can't do certain things like compile shell extensions; and ARM64 is gaining traction on the Windows side. Are there any development costs which need sponsoring to get over this hurdle? Hello, I am also interested in an ARM-based PC (XElite), but how does Lazarus perform with Prism (X86 emulation)? Does it allow existing applications to be compiled while waiting for native ARM64 support? Thanks ---------------------------------------------------------------------- DonAlfredo · 2025-10-16 18:05 I did not succeed. Unfortunately. FPC uses the stackpointer as framepointer on ARM64 and the Windows unwinder does not like this and I was unable to "invent" a workaround. The FPC devs have invested a lot of time and effort to get things running on Win64/ARM64. Its too bad that it does not work [yet]. ---------------------------------------------------------------------- Fred vS · 2025-10-16 19:04 Quote from: DonAlfredo on October 16, 2025, 08:05:58 pmFPC uses the stackpointer as framepointer on ARM64 and the Windows unwinder does not like this and I was unable to "invent" a workaround. Sorry but I tried, I asked my friend Gork what he thought about it, here is his answer:  QuoteException Handling and Unwinder: Partial support for exceptions exists in the RTL (run-time library), but it's unreliable in certain scenarios (e.g., try..finally blocks with exit statements, or more complex nesting). The compiler generates incorrect or incomplete unwind information, preventing proper stack unwinding during exceptions. Recent work (e.g., fixes to seh64.inc for data structure alignment with winnt.h) has improved stack unwinding, but issues like linking errors with "_fin$" symbols (related to finally blocks) persist. Bug #40203 on GitLab (https://gitlab.com/freepascal.org/fpc/source/-/issues/40203) tracks this with updates showing progress but no full resolution. Frame Pointer Specifics: FPC on ARM64 omits the dedicated frame pointer (x29) by default for performance reasons, similar to GCC's -fomit-frame-pointer. This is fine on other platforms but breaks Windows' table-based unwinding without custom unwind codes. The {$OPTIMIZATION FORCENOSTACKFRAME} directive exists to force omission, but it's not used by default on ARM yet—however, the effective behavior is omission where possible. Enabling a frame pointer isn't straightforward via options; it would require code changes or compiler modifications. Manual Unwind Info: Adding custom .pdata/.xdata in assembly is theoretically possible (following Microsoft's spec for unwind codes, e.g., save_fplr for pairs and alloc_m for stack allocation), but it's complex and not a simple "invention"—it would require patching FPC's code generator or RTL. Emulation Fallback: Run x64-compiled FPC apps under Windows' Prism emulator on ARM64 hardware. Performance is good for many cases, but it won't work if you need native ARM64 DLLs or drivers. ---------------------------------------------------------------------- DonAlfredo · 2025-10-16 20:03 FPC does generate custom unwind codes. And they look good. They do a nice job of reversing the prologue. Checked with all kinds of tools. But nevertheless I have not succeeded. ---------------------------------------------------------------------- PascalDragon · 2025-10-16 20:30 Quote from: DonAlfredo on October 16, 2025, 10:03:23 pmFPC does generate custom unwind codes. And they look good. They do a nice job of reversing the prologue. Checked with all kinds of tools. But nevertheless I have not succeeded. The problem is that the compiler needs to use the framepointer instead of the stackpointer as you already noticed, but it really dislikes to do that and the exceptions handlers need to be properly extracted from the normal functions (instead of partially being copied like they are now). ---------------------------------------------------------------------- Fred vS · 2025-10-16 20:38 Quote from: DonAlfredo on October 16, 2025, 10:03:23 pmFPC does generate custom unwind codes. Answer of Gork for "FPC does generate custom unwind codes. What must be changed to be ok?" The issue with FPC's unwind codes on Windows ARM64 stems from the fact that while the compiler does generate custom unwind information (via the .pdata and .xdata sections, as required by the Windows ABI), it currently produces incorrect or incomplete data that doesn't fully comply with Microsoft's specification for table-based exception unwinding. This leads to failures in stack unwinding during exceptions, preventing proper restoration of non-volatile registers (e.g., x19-x28, d8-d15, lr) and invocation of exception handlers. The core problem is exacerbated by FPC's default omission of a dedicated frame pointer (x29), relying instead on the stack pointer (sp) for frame access— a performance optimization that's valid on ARM64 but requires precise unchained unwind codes to work with the Windows unwinder.Based on recent developer discussions (as of September 2025), the fixes involve a combination of RTL structure alignments, code generator patches, and ensuring the unwind codes accurately mirror the function's prolog and epilog in reverse order. Here's a breakdown of what's wrong and what needs to be changed:Key Problems with Current Unwind CodesIncorrect Unwind Information Generation: The compiler's AArch64 backend (e.g., in cgcpu.pas) doesn't fully account for Windows-specific requirements, leading to malformed .xdata. For example, unwind codes fail to properly describe stack allocations, register saves, and restorations, causing the unwinder to skip or corrupt the stack during partial unwinds (e.g., mid-prolog or mid- epilog). This is why simple non-exception code runs, but try-except or try-finally blocks crash or skip handlers. Omission of Frame Pointer (x29): Without x29 (unchained mode), the unwind must rely solely on sp for recovery. However, current codes don't handle this correctly, especially for non-canonical prologs/epilogs (e.g., variable stack sizes or non-standard save orders). Packed unwind data in .pdata can't represent sp restores from x29, forcing full .xdata—but FPC's implementation often generates incompatible sequences. Mismatched SEH Structures: Definitions in rtl/win64/seh64.inc deviate from Windows' winnt.h, affecting how the unwinder interprets context during unwinding. For instance:KNONVOLATILE_CONTEXT_POINTERS.IntegerContext is sized incorrectly (should be array[0..11] for x19-x28 + fp + lr). TDispatcherContext misses a Reserved: DWord field for ARM64. RUNTIME_FUNCTION lacks proper flags and comments for ARM64-specific unwind data. Missing Local Unwind Support: The AArch64 code generator lacks a Windows override for g_local_unwind, which is needed to integrate with SEH for local jumps (e.g., exit in try-finally). This prevents _FPC_local_unwind from being called with the correct sp and label reference. Incomplete Handling for Exceptions: Even with partial RTL support (added around 2020-2021), the unwind codes don't ensure 1:1 mapping to prolog/epilog instructions, violating the spec's no-code-probing rule. This breaks mid-unwind scenarios, like interrupts or exceptions in partial frames. What Needs to Be Changed in the Unwind CodesTo comply with the Windows ARM64 unwind spec, FPC's unwind codes must be updated in the code generator to produce accurate .xdata sequences. These codes are stored in reverse prolog order (epilogs mirror them) and must describe every stack-modifying operation precisely. Since FPC omits x29, focus on unchained formats (CR=00 or 01 in packed .pdata). Key changes include:Align SEH Structures in RTL:Update seh64.inc to match winnt.h:Set KNONVOLATILE_CONTEXT_POINTERS.IntegerContext to array[0..11] of PQWord (comment: "// X19..X28 + Fp + Lr"). Keep FloatingContext as array[0..7] of PM128A (comment: "// D8..D15"). For RUNTIME_FUNCTION.UnwindData, add ARM64 comment: "// or Flag(2) Len(11) RegF(3) RegI(4) H(1) CR(2) FSize(9)". Add Reserved: DWord to TDispatcherContext for AARCH64, plus ControlPCIsUnwound: Byte and NonVolatileRegisters: PByte. These ensure the unwinder can correctly restore context pointers during unwinding. Implement Windows-Specific Local Unwind in Code Generator:Add an override to g_local_unwind in compiler/aarch64/cgcpu.pas for system_aarch64_win64: Key Problems with Current Unwind CodesIncorrect Unwind Information Generation: The compiler's AArch64 backend (e.g., in cgcpu.pas) doesn't fully account for Windows-specific requirements, leading to malformed .xdata. For example, unwind codes fail to properly describe stack allocations, register saves, and restorations, causing the unwinder to skip or corrupt the stack during partial unwinds (e.g., mid-prolog or mid-epilog). This is why simple non-exception code runs, but try-except or try-finally blocks crash or skip handlers. Omission of Frame Pointer (x29): Without x29 (unchained mode), the unwind must rely solely on sp for recovery. However, current codes don't handle this correctly, especially for non-canonical prologs/epilogs (e.g., variable stack sizes or non-standard save orders). Packed unwind data in .pdata can't represent sp restores from x29, forcing full .xdata—but FPC's implementation often generates incompatible sequences. Mismatched SEH Structures: Definitions in rtl/win64/seh64.inc deviate from Windows' winnt.h, affecting how the unwinder interprets context during unwinding. For instance:KNONVOLATILE_CONTEXT_POINTERS.IntegerContext is sized incorrectly (should be array[0..11] for x19-x28 + fp + lr). TDispatcherContext misses a Reserved: DWord field for ARM64. RUNTIME_FUNCTION lacks proper flags and comments for ARM64-specific unwind data. Missing Local Unwind Support: The AArch64 code generator lacks a Windows override for g_local_unwind, which is needed to integrate with SEH for local jumps (e.g., exit in try-finally). This prevents _FPC_local_unwind from being called with the correct sp and label reference. Incomplete Handling for Exceptions: Even with partial RTL support (added around 2020-2021), the unwind codes don't ensure 1:1 mapping to prolog/epilog instructions, violating the spec's no-code-probing rule. This breaks mid-unwind scenarios, like interrupts or exceptions in partial frames. What Needs to Be Changed in the Unwind CodesTo comply with the Windows ARM64 unwind spec, FPC's unwind codes must be updated in the code generator to produce accurate .xdata sequences. These codes are stored in reverse prolog order (epilogs mirror them) and must describe every stack-modifying operation precisely. Since FPC omits x29, focus on unchained formats (CR=00 or 01 in packed .pdata). Key changes include:Align SEH Structures in RTL:Update seh64.inc to match winnt.h:Set KNONVOLATILE_CONTEXT_POINTERS.IntegerContext to array[0..11] of PQWord (comment: "// X19..X28 + Fp + Lr"). Keep FloatingContext as array[0..7] of PM128A (comment: "// D8..D15"). For RUNTIME_FUNCTION.UnwindData, add ARM64 comment: "// or Flag(2) Len(11) RegF(3) RegI(4) H(1) CR(2) FSize(9)". Add Reserved: DWord to TDispatcherContext for AARCH64, plus ControlPCIsUnwound: Byte and NonVolatileRegisters: PByte. These ensure the unwinder can correctly restore context pointers during unwinding. Implement Windows-Specific Local Unwind in Code Generator:Add an override to g_local_unwind in compiler/aarch64/cgcpu.pas for system_aarch64_win64: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i procedure tcgaarch64.g_local_unwind(list: TAsmList; l: TAsmLabel);var  para1, para2: tcgpara;  href: treference;  pd: tprocdef;begin  if target_info.system<>system_aarch64_win64 then  begin    inherited g_local_unwind(list,l);    exit;  end;  pd:=search_system_proc('_fpc_local_unwind');  para1.init;  para2.init;  paramanager.getcgtempparaloc(list,pd,1,para1);  paramanager.getcgtempparaloc(list,pd,2,para2);  reference_reset_symbol(href,l,0,1,[]);  a_load_reg_cgpara(list,OS_ADDR,NR_STACK_POINTER_REG,para1);  a_loadaddr_ref_cgpara(list,href,para2);  paramanager.freecgpara(list,para2);  paramanager.freecgpara(list,para1);  g_call(list,'_FPC_local_unwind');  para2.done;  para1.done;end; This enables custom local unwinding by passing sp and a label to _FPC_local_unwind, fixing issues like skipped finally blocks. However, it may still crash post-unwind if broader codes aren't fixed—test iteratively. Generate Correct Unwind Code Sequences:For Stack Allocation: Use alloc_s (for <512 bytes: 000iiiii), alloc_m (<32K: 11000iii iiiiiiii), or alloc_l (<256M: 11100000 iiiiiiii iiiiiiii iiiiiiii). Match the prolog's sub sp,sp,#size and epilog's add sp,sp,#size. For Register Saves (Unchained, No x29): Avoid set_fp (11100001) or add_fp (11100010 iiiiiiii). Instead: Use save_regp/save_regp_x for integer pairs (x19-x28: 110010nn nniiiiii or 110011nn nniiiiii, pre-indexed for !). save_reg/save_reg_x for singles (110100nn nniiiiii or 1101010n nnniiiii). save_lrpair for lr pairs (1101011n nniiiii). save_fregp/save_fregp_x for FP pairs (d8-d15: 1101100n nniiiiii or 1101101n nniiiiii). save_freg/save_freg_x for FP singles (1101110n nniiiiii or 11011110 nnniiiii). Chain with save_next (11100110) for consecutive pairs (e.g., after save_regp to save four regs). For flexible saves (e.g., non-standard offsets), use save_any_reg variants (11100111 followed by 16-bit payload for str/stp/ldr/ldp on x/d/q regs). End Codes: Always end sequences with end (11100100) for complete unwind, or end_c (11100101) for chained scopes/fragments. Other: Include nop (11100011) for padding/homing, pac_sign_lr (11111100) if pointer authentication is used. Custom Codes for Non-Standard Cases: If FPC's sp-as-fp setup doesn't fit standard codes, use custom opcodes (11101xxx) like MSFT_OP_TRAP_FRAME (11101000) or MSFT_OP_CONTEXT (11101010) for bespoke stack handling in assembly routines. Ensure codes are in big-endian byte order, packed tightly (up to 255 bytes in .xdata), and shared across prolog/epilogs. For large functions (>1M instructions), split into fragments with separate .pdata/.xdata (first has prolog; others may have epilogs or end_c). Enable Packed Unwind Where Possible:For canonical unchained functions (no exceptions, standard save order, no x29), use packed .pdata (Flag=01/10/11) to compress data: 11-bit function length, 9-bit frame size, 2-bit CR (00: no lr save; 01: lr saved), 1-bit H (homing), 4-bit RegI (integer saves), 3-bit RegF (FP pairs). This avoids full .xdata but requires exact compliance—fall back to .xdata if non-canonical. RecommendationsApply the patches from the forum (e.g., seh64.inc diff and g_local_unwind override) to FPC trunk and test with simple try- finally/except programs. For full fix, the AArch64 code generator needs deeper changes to emit spec-compliant .xdata (track bug #40203 on GitLab). If you're contributing, focus on matching prolog/epilog 1:1 with unwind codes and handling unchained mode without x29. Workaround: Avoid exceptions entirely for now, or force frame pointers via compiler directives if feasible (though this isn't currently straightforward on ARM64). Monitor the Lazarus forum thread for updates—devs are actively patching, with bounties accelerating progress. ---------------------------------------------------------------------- PascalDragon · 2025-10-16 21:36 Quote from: Fred vS on October 16, 2025, 10:38:00 pmQuote from: DonAlfredo on October 16, 2025, 10:03:23 pmFPC does generate custom unwind codes. Answer of Gork for "FPC does generate custom unwind codes. What must be changed to be ok?" I've only read the first sentence and I already know that the stupid AI is wrong... The unwind codes are ok, its the generated code of the exception handlers that's wrong. Please don't spam AI responses if you're not able to verify them. ---------------------------------------------------------------------- msintle · 2025-10-16 23:55 Quote from: DonAlfredo on October 16, 2025, 10:03:23 pmFPC does generate custom unwind codes. And they look good. They do a nice job of reversing the prologue. Checked with all kinds of tools. But nevertheless I have not succeeded. You have already succeeded in galvanizing support for this effort. Take a day or two off, and the answer will come to you (or to CoPilot when you query it at the right time - just when the AI random seed will be perfect to generate an accurate response!) ---------------------------------------------------------------------- DonAlfredo · 2025-10-17 04:23 As with all AI answers: some things make (a bit of) sense, some are plain wrong. But I must say that this GROK answer makes (MUCH) more sense than anything I got from CodePilot. I will give an example. QuoteAdd Reserved: DWord to TDispatcherContext for AARCH64, plus ControlPCIsUnwound: Byte and NonVolatileRegisters: PByte.This is true, but does not help in getting things running. So good answer, but not helping in solving the current issue. QuoteFor example, unwind codes fail to properly describe stack allocations, register saves, and restorationsCompletely wrong answer. I will take the advice from msintle: a few days more distance and then perhaps a (re-)fresh start. ---------------------------------------------------------------------- bbrx · 2025-10-17 06:33 Quote from: DonAlfredo on October 16, 2025, 08:05:58 pmI did not succeed. Unfortunately. FPC uses the stackpointer as framepointer on ARM64 and the Windows unwinder does not like this and I was unable to "invent" a workaround. The FPC devs have invested a lot of time and effort to get things running on Win64/ARM64. Its too bad that it does not work [yet]. ok, thanks for your feedback ---------------------------------------------------------------------- Fred vS · 2025-10-17 11:45 Quote from: DonAlfredo on October 17, 2025, 06:23:33 amAs with all AI answers: some things make (a bit of) sense, some are plain wrong. But I must say that this GROK answer makes (MUCH) more sense than anything I got from CodePilot. I will give an example. QuoteAdd Reserved: DWord to TDispatcherContext for AARCH64, plus ControlPCIsUnwound: Byte and NonVolatileRegisters: PByte.This is true, but does not help in getting things running. So good answer, but not helping in solving the current issue. QuoteFor example, unwind codes fail to properly describe stack allocations, register saves, and restorationsCompletely wrong answer. That's the price of the game: sometimes the AI ​​is good, sometimes not. And regarding Gork, you must perfectly understand and describe the question you're going to ask, and if he makes a mistake, show him what's wrong. Unfortunately, I don't have the skills and knowledge of FPC,/Aarch64/Windows to fully appreciate his answers. I've provided his answers here in the hope that they may be useful to you. ---------------------------------------------------------------------- msintle · 2025-10-17 13:18 Quote from: DonAlfredo on October 17, 2025, 06:23:33 amAs with all AI answers: some things make (a bit of) sense, some are plain wrong. But I must say that this GROK answer makes (MUCH) more sense than anything I got from CodePilot. I understand keepoing CoPilot running is also a major investment of time and energy. Randomly every other day (or week) it asks for "reverification of identity", which involves supplying a new credit card (even if no charges are being made). A truly ridiculous product with a truly ridiculous customer experience that matches the uselessness and the shoddy quality of the "solution" on offer. Quote from: DonAlfredo on October 17, 2025, 06:23:33 amI will take the advice from msintle: a few days more distance and then perhaps a (re-)fresh start. Always the best. We sometimes forget we are biological beings, and in fact, resting and recovering is far more important than we realize. The right click at the right time can even make a world of difference with AI - it's all about finding the right moment with the right random seed ---------------------------------------------------------------------- DonAlfredo · 2025-10-17 13:49 I give you an example of how hard it can be to discuss with an AI. I had a function with an array [0..600] of byte. So some stack allocation needed. In total 2416 bytes. I asked CoPilot to analyze the .xdata. It came up with this. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i XCode Word 2 = 0xE3E3E3E4 (signed decimal: -471604252) → little-endian bytes:E4 E3 E3 E3The lower 16 bits encode 0x012E → 302 decimal → stack allocation units.Multiply by 8 → 302 * 8 = 2416 bytes, exactly what sub sp, sp, #2416 does. So it completely made up that in some wonderful universe far away 0xE3E4 is equal to 0x012E, just to fulfil the expectations of a stack of 2416 bytes. Utterly nonsense. Utterly useless. And frustrating also. And when confronted, this was the answer. Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i The bytes E4 E3 E3 E3 are not literally 0x012E.They encode the number of 8-byte stack units in the FPC unwind encoding format.The unwinder decodes it according to the DWARF AArch64 frame instructions, extracting 0x12E as the stack allocation after decoding. Again utterly nonsense. ---------------------------------------------------------------------- Fred vS · 2025-10-17 14:01 Quote from: DonAlfredo on October 17, 2025, 03:49:18 pmI asked CoPilot to analyze the .xdata. I did not try copilot yet. Only tried ChatGPT, Gemini and Gork. They all have serious deficiencies in Pascal. But it seems to me that Gork corrects himself better when you point out his mistakes. In short, AI still has a lot of work to do before it's truly useful. It's a bit like translators: if you don't have a minimum knowledge of the target language, it's best not to trust/use the translation. ---------------------------------------------------------------------- msintle · 2025-10-19 12:10 There really is no point to inject AI generated slop on this page, makes scrolling very difficult (it would be another thing had it been tested and found to work, of course). ---------------------------------------------------------------------- Fred vS · 2025-10-19 12:36 Quote from: msintle on October 19, 2025, 02:10:19 pmThere really is no point to inject AI generated slop on this page, makes scrolling very difficult (it would be another thing had it been tested and found to work, of course). OK, I'll delete my post (but maybe Alfred found something interesting in it). ---------------------------------------------------------------------- msintle · 2025-10-23 19:39 I appreciate that very much. Note to everyone: Claude seems to be the best AI to be using. ChatGPT is absolutely retarded, at least when it comes to Free Pascal. ---------------------------------------------------------------------- Wallaby · 2025-10-24 00:19 Quote from: msintle on October 23, 2025, 09:39:29 pmNote to everyone: Claude seems to be the best AI to be using. ChatGPT is absolutely retarded, at least when it comes to Free Pascal. Agreed! I've trialled Codex (ChatGPT), Gemini and Claude Code and likewise Codex was dumb, Gemini was even dumber, yet Claude Code demonstrated solid understanding of Pascal. Now I use Claude Code even more than the Lazarus IDE itself. ---------------------------------------------------------------------- msintle · 2026-01-21 11:38 So the Free Pascal compiler for aarch64 (ARM64) on Windows - does it generate ARM64 binaries, or this new thing called ARM64EC binaries? ARM64EC binaries are a watered-down version of true ARM64 binaries primarily designed to combine AMD64 (x64) code with aarch64 (ARM64) code in the same ABI (application binary interface). Thus, they cannot actually be used for things like shell extensions, Windows PE/RE environments - basically everything we actually DO need TRUE ARM64 for, that emulation does NOT help us with AT ALL. I would love to hear if anybody knows - thanks! ---------------------------------------------------------------------- Wallaby · 2026-01-21 11:58 True ARM64, but with broken exception handling, as we all know. ARM64EC is a MS extension for ARM64 to allow interoperability with x86_64 libraries, to allow gradual app conversion. With it apps can include a mix of ARM64 and x86_64 code, typically when some components cannot be recompiled or migrated. I doubt FPC will ever support ARM64EC. ---------------------------------------------------------------------- Thaddy · 2026-01-21 12:35 Quote from: Wallaby on January 21, 2026, 12:58:01 pmI doubt FPC will ever support ARM64EC. It does not have to. It is transparent, much like Rosetta on Apple AARCH64 software. Freepascal/Lazarus for Windows on AARCH64 is an ongoing development and is NOT a release version. Hence you may try that emulation layer: it should be processor agnostic if MS did a proper job like Apple did. ---------------------------------------------------------------------- msintle · 2026-01-21 14:11 Quote from: Wallaby on January 21, 2026, 12:58:01 pmTrue ARM64, but with broken exception handling, as we all know. ARM64EC is a MS extension for ARM64 to allow interoperability with x86_64 libraries, to allow gradual app conversion. With it apps can include a mix of ARM64 and x86_64 code, typically when some components cannot be recompiled or migrated. I doubt FPC will ever support ARM64EC. That is great to know. My company is willing to sponsor this fix to the tune of US$10,000 at this time. PM me if you are interested in claiming this offer. ---------------------------------------------------------------------- Thaddy · 2026-01-23 06:26 Keep the 10.000. Didn't you read my reply? It is an emulation layer for X86 code, just like Apple has: you do not need to change anything. And in time the Win/AARCH64 NATIVE version will also get a release. ---------------------------------------------------------------------- Wallaby · 2026-01-23 11:50 Quote from: msintle on January 21, 2026, 03:11:13 pmThat is great to know. My company is willing to sponsor this fix to the tune of US$10,000 at this time. PM me if you are interested in claiming this offer. I'll have a look into this hopefully next month, at the moment pretty busy working on my own projects. But yes, the bounty sounds enticing, and it's also a priority for me to get this working as myprojects require aarch64 builds. ---------------------------------------------------------------------- Thaddy · 2026-01-23 12:02 The bounty would be given to a cheat. After asking some MS people I know, the emulation layer is quite like Apple did. ---------------------------------------------------------------------- Luc · 2026-01-23 17:17 Lazarus works well on Windows 11 ARM. You can target Win32/Win64 Intel processors and use DLLs without issues - the OS handles everything through its compatibility layer. Debugging works quite reliably, and I've found it performs better when targeting x64 rather than x86. The main tradeoff is the performance hit from the emulation layer. Compilation times and final executable speed are noticeably slower compared to native x64 machines. My setup probably doesn't help (Mac M1 + Parallels + Win11 ARM), since I'm running virtualization on top of emulation, but even accounting for that, there's a clear speed penalty. Native ARM64 support in FPC for Windows would be a significant improvement - eliminating the emulation overhead would likely bring both compilation and runtime performance much closer to what we see on native x64 systems. For regular development work the current setup is perfectly usable, but be aware of the speed difference if you're doing heavy compilation or performance-critical work. Just my experience so far! ---------------------------------------------------------------------- Wallaby · 2026-01-24 05:19 Quote from: msintle on January 21, 2026, 03:11:13 pmThat is great to know. My company is willing to sponsor this fix to the tune of US$10,000 at this time. PM me if you are interested in claiming this offer. aaaaaannd, success! I was able to identify ~3 separate compiler bugs that led to crashes. Here is a screenshot of the IDE running natively on Win64 Aarch64. More details to come soon! ---------------------------------------------------------------------- ALLIGATOR · 2026-01-24 11:57 Quote from: Wallaby on January 24, 2026, 06:19:18 amaaaaaannd, success!Woohooo 😃🎉🎊 ---------------------------------------------------------------------- Wallaby · 2026-01-24 12:36 Compiled some apps of my own and fpcupdeluxe, all looks very promising, see attachment: ---------------------------------------------------------------------- DonAlfredo · 2026-01-24 13:35 This is very very good !!!! Would you mind testing the command line try exception/exit test on arm64 ? As included in the issue-report. If that works, you have earned the bounty 100% ! Looking forward to your bug-fixes. ---------------------------------------------------------------------- Wallaby · 2026-01-24 22:09 Quote from: DonAlfredo on January 24, 2026, 02:35:18 pmWould you mind testing the command line try exception/exit test on arm64 ? As included in the issue-report. That was actually only a starting point, I've discovered a few edge cases and eventually the test code evolved into this: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program test_seh_complex;{$mode objfpc}{$H+} { Complex SEH test suite - focused on edge cases } uses  SysUtils; var  TestsPassed, TestsFailed: Integer; procedure Check(const TestName: string; Condition: Boolean);begin  Write(TestName, ' ... ');  if Condition then  begin  WriteLn('PASS');    Inc(TestsPassed);  end  else  begin    WriteLn('FAIL');    Inc(TestsFailed);  end;end; { Test 1: Very deep nesting (10 levels) with exit }function Test_DeepNesting: Integer;var  FC: Integer;begin  Result := 0;  FC := 0;  try    try      try        try          try            try              try                try                try                    try                      Result := 100;                      Exit;                    finally Inc(FC); end;                  finally Inc(FC); end;                finally Inc(FC); end;              finally Inc(FC); end;            finally Inc(FC); end;          finally Inc(FC); end;        finally Inc(FC); end;      finally Inc(FC); end;    finally Inc(FC); end;  finally Inc(FC); end;  Result := FC;end; { Test 2: Recursive function with try/finally and early exit }function Test_Recursive(Depth: Integer): Integer;begin  if Depth <= 0 then  begin    Result := 1;    Exit;  end;  try    Result := Test_Recursive(Depth - 1) + 1;    if Depth = 3 then Exit;  finally    // Finally runs even on recursive exit  end;end; { Test 3: Break from deeply nested loops }function Test_NestedLoopBreak: Integer;var  I, J, K, FC: Integer;begin  FC := 0;  for I := 1 to 3 do  begin    try      for J := 1 to 3 do      begin        try          for K := 1 to 3 do          begin          try              if (I = 2) and (J = 2) and (K = 2) then Break;          finally Inc(FC); end;          end;          if (I = 2) and (J = 2) then Break;        finally Inc(FC); end;      end;      if I = 2 then Break;    finally Inc(FC); end;  end;  Result := FC;end; { Test 4: Continue in nested loops }function Test_NestedContinue: Integer;var  I, J, FC: Integer;begin  FC := 0;  for I := 1 to 5 do  begin    try      if I mod 2 = 0 then Continue;      for J := 1 to 5 do      begin        try          if J mod 2 = 0 then Continue;      finally Inc(FC); end;      end;    finally Inc(FC); end;  end;  Result := FC;end; { Test 5: Large local arrays with exit }function Test_LargeLocals: Integer;var  Arr: array[0..999] of Integer;  I, Sum: Integer;  OK: Boolean;begin  for I := 0 to 999 do Arr[I] := I;  try  Sum := 0;    for I := 0 to 999 do Sum := Sum + Arr[I];    Result := Sum;    Exit;  finally    OK := (Arr[0] = 0) and (Arr[500] = 500) and (Arr[999] = 999);    if not OK then Result := -1;  end;end; { Test 6: Mixed break/continue/exit }function Test_MixedFlow: Integer;var  I, FC, Mode: Integer;begin  FC := 0;  for Mode := 1 to 3 do  begin    for I := 1 to 5 do    begin      try        case Mode of          1: if I = 3 then Break;          2: if I mod 2 = 0 then Continue;          3: if I = 4 then begin Result := FC; Exit; end;        end;      finally Inc(FC); end;    end;  end;  Result := FC;end; { Test 7: While loop with break }function Test_WhileBreak: Integer;var  I, FC: Integer;begin  FC := 0;  I := 0;  while I < 100 do  begin    try      Inc(I);      if I = 5 then Break;    finally Inc(FC); end;  end;  Result := FC;end; { Test 8: Repeat-until with break }function Test_RepeatBreak: Integer;var  I, FC: Integer;begin  FC := 0;  I := 0;  repeat    try      Inc(I);      if I = 7 then Break;    finally Inc(FC); end;  until I >= 100;  Result := FC;end; { Test 9: Exception then exit }function Test_ExceptionThenExit: Integer;var  FC: Integer;begin  FC := 0;  try    try      raise Exception.Create('Test');    except      Inc(FC);    end;    try      Inc(FC);      Result := FC;      Exit;    finally Inc(FC); end;  finally    Inc(FC);    Result := FC; // Set result in finally  end;end; { Test 10: String operations in finally }function Test_StringFinally: Integer;var  S: string;begin  Result := 0;  S := '';  try    S := 'A';    try      S := S + 'B';      Result := 42;    Exit;    finally S := S + 'C'; end;  finally    S := S + 'D';    if S = 'ABCD' then Result := 1 else Result := 0;  end;end; { Test 11: Multiple returns preserving value }function Test_MultiReturn(Mode: Integer): Integer;begin  try    case Mode of      1: begin Result := 10; Exit; end;      2: begin Result := 20; Exit; end;      3: begin Result := 30; Exit; end;    end;    Result := 0;  finally    // Result should be preserved  end;end; { Test 12: Nested procedures }function Test_NestedProc: Integer;var  InnerRan: Boolean;   procedure Inner;  begin    try      Exit;    finally InnerRan := True; end;  end; begin  InnerRan := False;  try    Inner;    Result := 1;    Exit;  finally  if not InnerRan then Result := 0;  end;end; { Test 13: Break in case statement }function Test_CaseBreak: Integer;var  I, FC: Integer;begin  FC := 0;  for I := 1 to 10 do  begin    try      case I of        1..3: ;        4, 5: Break;        6..10: ;      end;    finally Inc(FC); end;  end;  Result := FC;end; { Test 14: Exception caught then normal exit }function Test_DeepMixed: Integer;var  FC: Integer;begin  FC := 0;  try    try      try        raise Exception.Create('Deep');      finally Inc(FC); end;    except      Inc(FC);      // Exit from except block (simpler case)    end;    try      Inc(FC);      Exit;    finally Inc(FC); end;  finally    Inc(FC);    Result := FC;  end;end; { Test 15: Array bounds in finally }function Test_ArrayFinally: Integer;var  Arr: array[0..9] of Integer;  I, Sum: Integer;begin  for I := 0 to 9 do Arr[I] := I * 10;  try    Result := 999;    Exit;  finally    Sum := 0;    for I := 0 to 9 do Sum := Sum + Arr[I];    if Sum = 450 then Result := 1 else Result := 0;  end;end; { Main }begin  WriteLn('=== Complex SEH Test Suite ===');  WriteLn;   TestsPassed := 0;  TestsFailed := 0;   Check('Test 1: Deep nesting (10 levels)', Test_DeepNesting = 100);  Check('Test 2: Recursive with exit', Test_Recursive(5) >= 3);  Check('Test 3: Nested loop break', Test_NestedLoopBreak > 0);  Check('Test 4: Nested loop continue', Test_NestedContinue > 0);  Check('Test 5: Large locals (4KB array)', Test_LargeLocals = 499500);  Check('Test 6: Mixed control flow', Test_MixedFlow > 0);  Check('Test 7: While break', Test_WhileBreak = 5);  Check('Test 8: Repeat break', Test_RepeatBreak = 7);  Check('Test 9: Exception then exit', Test_ExceptionThenExit = 4);  Check('Test 10: String in finally', Test_StringFinally = 1);  Check('Test 11: Multi- return values', (Test_MultiReturn(1)=10) and (Test_MultiReturn(2)=20) and (Test_MultiReturn(3)=30));  Check('Test 12: Nested procedures', Test_NestedProc = 1);  Check('Test 13: Case break', Test_CaseBreak = 4);  Check('Test 14: Deep mixed', Test_DeepMixed = 5);  Check('Test 15: Array in finally', Test_ArrayFinally = 1);   WriteLn;  WriteLn('=== Results ===');  WriteLn('Passed: ', TestsPassed);  WriteLn('Failed: ', TestsFailed);  WriteLn;  if TestsFailed = 0 then  WriteLn('All tests passed!')  else    WriteLn('SOME TESTS FAILED!');end. There were additional issues with alignment (unrelated to exceptions) and also an issue with a bug in the included Clang Assembler. ---------------------------------------------------------------------- Wallaby · 2026-01-25 03:32 I've got lazarus and the compiler fully working on aarch64. Lazarus still has a few issues, like there is no debugger (fpdebug only works with Intel/AMD), but otherwise things look good. See screenshots below. I'll now PM msintle about further testing and the bounty. ---------------------------------------------------------------------- DonAlfredo · 2026-01-25 06:47 Very good and impressive !!! Looking forward to your bug-fixes. ---------------------------------------------------------------------- msintle · 2026-01-25 14:58 That's great to hear! There's simply many cases that you need native ARM64 code for, where emulation will not get the job done. In fact, not even ARM64EC will get the job done in these particular cases. Happy to give a few examples if people can't think of them on their own? Please merge the changes to the main Lazarus branches so everyone can test and validate them, too. We will pay the bounty out through an Upwork escrow. Happy to create this right away if you're 100%. The payment would be cleared once all our testing has been completed with our own internal code. ---------------------------------------------------------------------- PascalDragon · 2026-01-25 17:20 Quote from: Wallaby on January 24, 2026, 11:09:17 pmThere were additional issues with alignment (unrelated to exceptions) and also an issue with a bug in the included Clang Assembler. That would explain why I also encountered issues with the relocations that didn't seem correct... ---------------------------------------------------------------------- msintle · 2026-01-26 14:42 Would the community be amenable to accepting attribution comments in the units affected by the fixes of this sponsorship? Understandably my employee does not want to spend so much money on development without recognition, as this is not a core business area for us (it is not somewhere where we would make a profit at all). But the spend is justified if in the code comments on the top, a link to our website and GitHub repository is provided (and kept in place) across revisions; together with the name of the sponsor, of course. We have agreed on other terms with Wallaby, but this one is beyond his control; so asking here instead. ---------------------------------------------------------------------- PascalDragon · 2026-01-27 20:10 Quote from: msintle on January 26, 2026, 03:42:05 pmWould the community be amenable to accepting attribution comments in the units affected by the fixes of this sponsorship? Understandably my employee does not want to spend so much money on development without recognition, as this is not a core business area for us (it is not somewhere where we would make a profit at all). But the spend is justified if in the code comments on the top, a link to our website and GitHub repository is provided (and kept in place) across revisions; together with the name of the sponsor, of course. We have agreed on other terms with Wallaby, but this one is beyond his control; so asking here instead. We had a discussion about something like this in the past already and came to the conclusion that we don't do that. ---------------------------------------------------------------------- rvk · 2026-01-27 20:20 The foundation has something like the hall of fame. https://foundation.freepascal.org/halloffame But FPC/Lazarus itself do not. (They do have a credit page but that's for technical credit) ---------------------------------------------------------------------- 440bx · 2026-01-27 21:29 Quote from: PascalDragon on January 27, 2026, 09:10:21 pmWe had a discussion about something like this in the past already and came to the conclusion that we don't do that. That's quite understandable since what could start as "innocent" attributions could devolve in shameless marketing. OTH, if attributions were allowed under strict guidelines to avoid abuses, that might encourage companies to financially invest in the development of FPC (and possibly Lazarus under similar conditions.)  We all know that having sponsors is better than not having them. Sounds reasonable that if a company contributed in some way to enhancing something that they'd be given credit for it while ensuring "credit" isn't abused into becoming marketing. Given the potential benefits, I think it would be reasonable to revisit that policy and create some strict guidelines under which attributions would be allowed. My $0.01 (on sale today 50% off) ---------------------------------------------------------------------- VisualLab · 2026-01-28 19:18 Quote from: 440bx on January 27, 2026, 10:29:46 pmQuote from: PascalDragon on January 27, 2026, 09:10:21 pmWe had a discussion about something like this in the past already and came to the conclusion that we don't do that. That's quite understandable since what could start as "innocent" attributions could devolve in shameless marketing. OTH, if attributions were allowed under strict guidelines to avoid abuses, that might encourage companies to financially invest in the development of FPC (and possibly Lazarus under similar conditions.)  We all know that having sponsors is better than not having them. Sounds reasonable that if a company contributed in some way to enhancing something that they'd be given credit for it while ensuring "credit" isn't abused into becoming marketing. Given the potential benefits, I think it would be reasonable to revisit that policy and create some strict guidelines under which attributions would be allowed. Hmm... I think the decision-makers of the Lazarus project (and libraries) could try to implement something like this, at least as a pilot. To start with, for one library. If there are no problems, it could be continued. In any case, as 400bx mentioned, it's crucial to very precisely define the principles (guidelines) under which this would operate. ---------------------------------------------------------------------- 440bx · 2026-01-28 22:54 Quote from: VisualLab on January 28, 2026, 08:18:52 pmit's crucial to very precisely define the principles (guidelines) under which this would operate. Indeed, that's the crux of the matter.  It also means that most, if not all, the decision makers must be involved in creating the guidelines (probably not easy to have everyone's agreement.) Personally, I believe the potential benefits is worth the effort. ---------------------------------------------------------------------- PascalDragon · 2026-01-29 21:26 Quote from: 440bx on January 27, 2026, 10:29:46 pmQuote from: PascalDragon on January 27, 2026, 09:10:21 pmWe had a discussion about something like this in the past already and came to the conclusion that we don't do that. That's quite understandable since what could start as "innocent" attributions could devolve in shameless marketing. OTH, if attributions were allowed under strict guidelines to avoid abuses, that might encourage companies to financially invest in the development of FPC (and possibly Lazarus under similar conditions.)  We all know that having sponsors is better than not having them. Sounds reasonable that if a company contributed in some way to enhancing something that they'd be given credit for it while ensuring "credit" isn't abused into becoming marketing. First of the company itself did not contribute itself, but “only” offered a bounty in the hope that someone would attempt to fix the issues. Second in the discussion back then - which I've now looked up and funnily enough was also about aarch64-win64, so it's not even that long ago - we came to the conclusion that people should sponsor work for the sake of functionality and not for the sake of brand awareness. If companies want to be mentioned somewhere they should donate to the Foundation and request to be put on the Hall of Fame. ---------------------------------------------------------------------- 440bx · 2026-01-29 23:30 Quote from: PascalDragon on January 29, 2026, 10:26:55 pmFirst of the company itself did not contribute itself, but “only” offered a bounty in the hope that someone would attempt to fix the issues. Second in the discussion back then - which I've now looked up and funnily enough was also about aarch64-win64, so it's not even that long ago - we came to the conclusion that people should sponsor work for the sake of functionality and not for the sake of brand awareness. If companies want to be mentioned somewhere they should donate to the Foundation and request to be put on the Hall of Fame. In this case the company offered a respectable bounty, IMO, while not direct, it is still a contribution.  The person who did the work may not have done the work as promptly or at all if a respectable bounty had not been available.  The company explicitly sponsored work and _after_ the work was done asked if it could get some credit for sponsoring it.  I believe that is fair.  They invested into getting some work done, therefore they contributed.  Also, I don't see anything wrong in a company offering a bounty for the further development of an already approved feature that is in their interest instead of throwing money into a foundation that may invest it into something that offers little to no benefit to them.  When someone (person or entity) puts money into something, I believe it is reasonable for them to expect a little something back for their financial investment and goodwill. What you call "The Hall of Fame" seems to be the "Hall of the Unknown".  There are _very_, _very_ few places where I see credit given to an author and when given it seems to be more to acknowledge copyrights than anything else (e.g, API definitions.)  As a result of your mentioning "The Hall of Fame" (or lack thereof) I looked it up and found it.  What their contribution is/was isn't even mentioned, I guess they contributed money (made a donation.)  How many of them invested $10,000 in enhancing FPC ? I am fully aware that my opinion doesn't carry any weight but, if those who contribute aren't given a modicum of credit, that doesn't encourage further contributions which is detrimental.  Anyway, personally I believe the current "credit for contributions" could be "improved". ---------------------------------------------------------------------- Wallaby · 2026-01-29 23:31 ARM64 Windows SEH Local Unwind Implementation for Free Pascal Bug Report: #40203 Merge Request: !1267 What This Is About I've been working on fixing Structured Exception Handling (SEH) for ARM64 Windows in the Free Pascal Compiler. The core issue is that Exit, Break, and Continue statements inside try/finally blocks simply don't work correctly on ARM64 Windows - the finally blocks either don't run, or local variables get corrupted. On x86-64 Windows, there's a nice API called RtlUnwindEx that handles all this automatically. You just call it with the target address and it magically executes all the finally handlers and transfers control. Unfortunately, on ARM64 Windows, RtlUnwindEx doesn't work for local unwind operations - it either hangs or crashes (or maybe we using it wrong  ). I spent quite a bit of time investigating why, and the conclusion is that we need to implement manual scope walking instead. The Problem in Detail Ignore this post, I was able to implement a correct solution rather than workaround. ---------------------------------------------------------------------- Wallaby · 2026-01-30 00:05 Forgot to mention if you are going to build this with FpcupDeluxe, you can simply add the patches and rebuild. However, I remember having some issues with older LLVM included in FpcupDeluxe's cross-tools, I recommend using CLANG + LLVM 21 as there are quite a few fixes related to Win64 ARM64: Issue D114347: ADRP Signed/Unsigned 21-bit Interpretation Issue D113865: Temporary Symbols Out-of-Range for ADRP Issue D34964: ARM64 Import Thunk Implementation ---------------------------------------------------------------------- Fred vS · 2026-01-30 00:42 @Wallaby: You are extremely precious. ---------------------------------------------------------------------- Wallaby · 2026-01-30 04:30 I might have figured out why RtlUnwind wasn't working on ARM64. Will post an update soon, we may be able to simplify a lot... ---------------------------------------------------------------------- ALLIGATOR · 2026-01-30 05:17 I'm being told that I need to look at how it's done in C++, and that it's all about constructing the frame pointer correctly (but I don't understand this issue myself) ---------------------------------------------------------------------- ALLIGATOR · 2026-01-30 05:18 View - by compiling similar code in C++ ---------------------------------------------------------------------- Wallaby · 2026-01-30 05:43 Guys, ignore the above patches, that was a workaround rather than a solution. I've got RtlUnwindEx working and will provide a better set of patches shortly! There was an issue with FPC SEH PDATA generation. ---------------------------------------------------------------------- Wallaby · 2026-01-30 07:17 🎉 ARM64 Windows SEH Finally Works! (MR !1268 needs testers)   Hey everyone!   After many hours of debugging, head-scratching, and probably too much coffee ☕, I'm happy to announce that I've   submitted a merge request to fix exception handling on Windows ARM64!   The Bug: #40203   The Fix: MR !1268   What was broken?   If you tried using Exit, Break, or Continue inside a try/finally block on Windows ARM64... well, let's just say the   finally block had other plans. 🙈 It simply didn't run, and your program would crash or behave mysteriously.   What's fixed?   Several things actually!   The frame pointer dance 💃 - Windows ARM64 is quite picky about the frame pointer value you pass to   RtlUnwindEx - it must be FP+16, not just FP. Who knew 16 bytes could cause so much trouble?ADRP relocation calculation 🔧 - The internal linker was computing page-relative relocations incorrectly.   The addend needs to be added to the target address before computing the page difference, not after. This one   was sneaky!SP-relative temp access in finally handlers - ARM64 uses SP-relative addressing for temps (unlike x64 which    uses RBP-relative). The $fin$ handler has its own stack, so we now convert the addresses properly.Threadvar alignment - Ensuring 8-byte alignment on 64-bit platforms, because ARM64 atomic operations really    don't like misaligned data. 😤   I've tested this extensively with 44+ test cases covering:   Basic try/except/finallyExit/Break/Continue in try/finallyNested exception blocks (5+ levels deep!)For-in loops with exception handlingComplex control flow scenariosAnd more...  🧪 Call for testers!   If you have a Windows ARM64 device (Surface Pro X, Snapdragon laptops, etc.), please give this a spin! The more   testing we do, the more confident we can be that this fix is solid.   Apply the patches from the MR to FPC trunk, rebuild, and let me know if anything breaks or if you find edge cases I   missed.   Any feedback, questions, or virtual high-fives are welcome! 🙌   Cheers! ---------------------------------------------------------------------- 440bx · 2026-01-30 07:32 I don't have an ARM64 based device but, I strongly believe you deserve virtual high-fives for your efforts, therefore here is mine: high- five! ---------------------------------------------------------------------- ALLIGATOR · 2026-01-30 07:46 By the way, does anyone have a ready-made recipe for running Windows ARM in QEMU on x86_64 Windows? Maybe everything is already preconfigured and ready to run? ---------------------------------------------------------------------- Wallaby · 2026-01-30 07:49 Quote from: ALLIGATOR on January 30, 2026, 08:46:25 amBy the way, does anyone have a ready-made recipe for running Windows ARM in QEMU on x86_64 Windows? Maybe everything is already preconfigured and ready to run? I've tried that, but it was painfully slow and unreliable even running on a 6Ghz 13900KS. Better get a mac-mini and run in Parallels, or a snapdragon-based laptop. ---------------------------------------------------------------------- msintle · 2026-01-30 11:18 We have both Snapdragons for native Windows 11, and Parallels on arm64 Macs for virtualized Windows 11. Funny note: Virtualizing Windows 11 on arm64 macOS is far easier than virtualizing Windows 11 on Snapdragon itself, thanks to the horrid product that is called Hyper-V. Of course, you could go native only on Snapdragon; as Boot Camp has been removed on arm64 Macs for some reason. Anyways, are there installation instructions for the latest version of Free Pascal/Lazarus, so we can get down and dirty testing your work thus far against our existing code base? Very excited to see all the progress that is being made. ---------------------------------------------------------------------- msintle · 2026-01-30 11:21 Quote from: 440bx on January 30, 2026, 12:30:47 amQuote from: PascalDragon on January 29, 2026, 10:26:55 pmFirst of the company itself did not contribute itself, but “only” offered a bounty in the hope that someone would attempt to fix the issues. Second in the discussion back then - which I've now looked up and funnily enough was also about aarch64-win64, so it's not even that long ago - we came to the conclusion that people should sponsor work for the sake of functionality and not for the sake of brand awareness. If companies want to be mentioned somewhere they should donate to the Foundation and request to be put on the Hall of Fame. In this case the company offered a respectable bounty, IMO, while not direct, it is still a contribution.  The person who did the work may not have done the work as promptly or at all if a respectable bounty had not been available.  The company explicitly sponsored work and _after_ the work was done asked if it could get some credit for sponsoring it.  I believe that is fair.  They invested into getting some work done, therefore they contributed.  Also, I don't see anything wrong in a company offering a bounty for the further development of an already approved feature that is in their interest instead of throwing money into a foundation that may invest it into something that offers little to no benefit to them.  When someone (person or entity) puts money into something, I believe it is reasonable for them to expect a little something back for their financial investment and goodwill. What you call "The Hall of Fame" seems to be the "Hall of the Unknown".  There are _very_, _very_ few places where I see credit given to an author and when given it seems to be more to acknowledge copyrights than anything else (e.g, API definitions.)  As a result of your mentioning "The Hall of Fame" (or lack thereof) I looked it up and found it.  What their contribution is/was isn't even mentioned, I guess they contributed money (made a donation.)  How many of them invested $10,000 in enhancing FPC ? I am fully aware that my opinion doesn't carry any weight but, if those who contribute aren't given a modicum of credit, that doesn't encourage further contributions which is detrimental.  Anyway, personally I believe the current "credit for contributions" could be "improved". Thank you for this. It is clear to me that Lazarus will continue to have tons of untapped potential, lagging behind in areas like GTK, Qt, on Linux as we all know - and even on Macs, falling behind in SDK support, even silly things like rounded corners on macOS Tahoe don't work months after release - thanks to policies which are primarily defensive in posture, but serving only to stunt the growth of this awesome effort. ---------------------------------------------------------------------- msintle · 2026-01-30 11:27 Quote from: PascalDragon on January 29, 2026, 10:26:55 pmQuote from: 440bx on January 27, 2026, 10:29:46 pmQuote from: PascalDragon on January 27, 2026, 09:10:21 pmWe had a discussion about something like this in the past already and came to the conclusion that we don't do that. That's quite understandable since what could start as "innocent" attributions could devolve in shameless marketing. OTH, if attributions were allowed under strict guidelines to avoid abuses, that might encourage companies to financially invest in the development of FPC (and possibly Lazarus under similar conditions.)  We all know that having sponsors is better than not having them. Sounds reasonable that if a company contributed in some way to enhancing something that they'd be given credit for it while ensuring "credit" isn't abused into becoming marketing. First of the company itself did not contribute itself, but “only” offered a bounty in the hope that someone would attempt to fix the issues. Second in the discussion back then - which I've now looked up and funnily enough was also about aarch64-win64, so it's not even that long ago - we came to the conclusion that people should sponsor work for the sake of functionality and not for the sake of brand awareness. If companies want to be mentioned somewhere they should donate to the Foundation and request to be put on the Hall of Fame. At risk of inflaming a possibly senior compiler developer here: Why do you find it funny that the previous request was also about aarch64-win64? Because you think in every other area Lazarus is already perfect, a done deal, with no room for growth and/or improvement left? Or is it funny that the company chose the most strategic area for development that begged for improvement, and continues to press this agenda forward in spite of your opposition - and may have even succeeded now, despite your best efforts to block progress by exercising a degree of control that is, by now clearly seen to be, unwarranted and counterproductive to all users of the product? I'd say, get used to FPC/Lazarus outgrowing you and your control. This incident has demonstrated that despite your efforts to backpedal, no matter how "well" they may be intentioned; your creation has already grown beyond you. ---------------------------------------------------------------------- Wallaby · 2026-01-30 11:46 Quote from: msintle on January 30, 2026, 12:18:23 pmAnyways, are there installation instructions for the latest version of Free Pascal/Lazarus, so we can get down and dirty testing your work thus far against our existing code base? Download FpcupDeluxe here and drop it into any folder. Click the Setup+ button, then find Source patching – Add FPC patch and add all seven patches listed there (in the Open File dialog, choose *Patch* as the file type). Select trunk for both FPC and Lazarus. Then simply click Install/Update FPC and Lazarus. Make sure the bottom log mentions the patches succesfully applied. Once that is done, go to the Cross tab, choose aarch64 and Windows, and click Install compiler. Agree to download the cross-tools and wait. When everything is finished, you will have a full Lazarus package and three compilers (Win i386, Win x64 and Win aarch64). Start Lazarus using the BAT file and you should be able to build for Windows on ARM by setting the target processor to aarch64 and the target system to Win64. QuoteIt is clear to me that Lazarus will continue to have tons of untapped potential, lagging behind in areas like GTK, Qt, on Linux as we all know - and even on Macs, falling behind in SDK support, even silly things like rounded corners on macOS Tahoe don't work months after release - thanks to policies which are primarily defensive in posture, but serving only to stunt the growth of this awesome effort. On that point, I agree with you. Free Pascal has a number of issues in its development policies, priorities and long-term vision (>5 years between releases; these days one might reasonably assume the product is abandoned and move on). In addition, the developers tend to focus on their own areas of interest. That said, it is free and open-source, so we cannot really blame them for this — it is their choice — even though it is clearly not good for the project’s long-term health or popularity. Take the ARM64 exceptions issue as an example: the bug report has been sitting unresolved for years. I have customers who are increasingly asking for ARM64 builds of my products, so I took matters into my own hands and wasted spent several days getting it done. Hopefully the developers will accept the patches, but if not, that only makes things worse for the project. In the meantime, I — and anyone else who needs this functionality — can simply use the patches and move on. ---------------------------------------------------------------------- 440bx · 2026-01-30 12:04 Quote from: Wallaby on January 30, 2026, 12:46:49 pmIn the meantime, I — and anyone else who needs this functionality — can simply use the patches and move on. The problem with going that route is that the programmer ends up using a customized, i.e, non-supported, version of the compiler.  In the long run, that's a mountain of headaches that become impractical to deal with. ---------------------------------------------------------------------- Wallaby · 2026-01-30 12:17 Quote from: 440bx on January 30, 2026, 01:04:37 pmThe problem with going that route is that the programmer ends up using a customized, i.e, non-supported, version of the compiler.  In the long run, that's a mountain of headaches that become impractical to deal with. No one is saying it is perfect 🙂 But the choice is simple: either you do not have the functionality you need, or you patch it to work the way you want. I have another example here. There was a change to generics.hashes.pas that broke it on Darwin x86_64, and that change was applied to both main and fixes_3_2. I reported the issue and attached a patch. It was accepted into main, but not into fixes_3_2, so that branch remains broken, and my request to merge the fix into the fixes branch was ignored. As a result, I simply use a fixes_3_2 build for daily work with my patch applied on top. In practice, this causes zero problems and fully solves the issue for me (while others, unfortunately, are still stuck with the buggy version). It is not that you are locked to a specific compiler version; rather, you are using a customised build that addresses what is important to you. ---------------------------------------------------------------------- tofutim · 2026-02-02 15:30 Hi Wallaby, I saw your [MR !1268](https://gitlab.com/freepascal.org/fpc/source/- /merge_requests/1268) (Reply #171) — great to see the full SEH fix and 44+ test cases. I’d been working on the same try...finally+exit issue from your minimal test (Reply #67 / [GitLab #40203](https://gitlab.com/freepascal.org/fpc/source/-/issues/40203)) and ended up with a minimal approach: for aarch64-win64 the compiler emits a call to `_FPC_local_unwind` (RtlUnwindEx) instead of a plain jump when leaving a try block via exit/break/continue, and the RTL implements that helper. No frame-pointer or PDATA changes — just that one path. The minimal test (begin → try → exit → finally → end) prints "finally" on Windows ARM64. I’ve put that in a separate MR with CI so it’s easy to compare or cherry-pick: [!1276](https://gitlab.com/freepascal.org/fpc/source/- /merge_requests/1276), with a passing run on `windows-11-arm` here: [GitHub Actions run 21584281219](https://github.com/gig8/fpc/actions/runs/21584281219). Scope is deliberately small (no ppca64, no self-compile). If maintainers prefer your full fix in !1268, that’s fine by me — just wanted to share the minimal variant and CI in case it’s useful. Happy to help test !1268 or compare notes. **MR !1268 (Wallaby):** [ARM64 Windows SEH – full fix](https://gitlab. com/freepascal.org/fpc/source/-/merge_requests/1268)  **MR !1276 (this one):** [aarch64-win64: fix try...finally+exit (minimal + CI)](https://gitlab.com/freepascal.org/fpc/source/- /merge_requests/1276)  **CI proof for !1276:** [run 21584281219](https://github.com/gig8/fpc/actions/runs/21584281219) Quote from: Wallaby on January 30, 2026, 08:17:57 am🎉 ARM64 Windows SEH Finally Works! (MR !1268 needs testers)   Hey everyone!   After many hours of debugging, head-scratching, and probably too much coffee ☕, I'm happy to announce that I've   submitted a merge request to fix exception handling on Windows ARM64!   The Bug: #40203   The Fix: MR !1268   What was broken?   If you tried using Exit, Break, or Continue inside a try/finally block on Windows ARM64... well, let's just say the   finally block had other plans. 🙈 It simply didn't run, and your program would crash or behave mysteriously.   What's fixed?   Several things actually!   The frame pointer dance 💃 - Windows ARM64 is quite picky about the frame pointer value you pass to   RtlUnwindEx - it must be FP+16, not just FP. Who knew 16 bytes could cause so much trouble?ADRP relocation calculation 🔧 - The internal linker was computing page-relative relocations incorrectly.   The addend needs to be added to the target address before computing the page difference, not after. This one   was sneaky!SP-relative temp access in finally handlers - ARM64 uses SP-relative addressing for temps (unlike x64 which    uses RBP-relative). The $fin$ handler has its own stack, so we now convert the addresses properly.Threadvar alignment - Ensuring 8-byte alignment on 64-bit platforms, because ARM64 atomic operations really    don't like misaligned data. 😤   I've tested this extensively with 44+ test cases covering:   Basic try/except/finallyExit/Break/Continue in try/finallyNested exception blocks (5+ levels deep!)For-in loops with exception handlingComplex control flow scenariosAnd more...  🧪 Call for testers!   If you have a Windows ARM64 device (Surface Pro X, Snapdragon laptops, etc.), please give this a spin! The more   testing we do, the more confident we can be that this fix is solid.   Apply the patches from the MR to FPC trunk, rebuild, and let me know if anything breaks or if you find edge cases I   missed.   Any feedback, questions, or virtual high-fives are welcome! 🙌   Cheers! ---------------------------------------------------------------------- Wallaby · 2026-02-02 23:13 Yeah, there were a few more issues like the alignment fix (otherwise silent crash) and RtlUnwind did not work correctly for local unwind because of incorrect PDATA records (exceptions were okay, but exit/break/continue were not). I haven't tested your patch, but try running my 44-test set. They all pass on x64 and on arm64 with my patches, would be interesting to see how they work with yours. ---------------------------------------------------------------------- msintle · 2026-02-03 14:25 Quote from: Wallaby on January 30, 2026, 12:46:49 pmQuote from: msintle on January 30, 2026, 12:18:23 pmAnyways, are there installation instructions for the latest version of Free Pascal/Lazarus, so we can get down and dirty testing your work thus far against our existing code base? Download FpcupDeluxe here and drop it into any folder. Click the Setup+ button, then find Source patching – Add FPC patch and add all seven patches listed there (in the Open File dialog, choose *Patch* as the file type). Select trunk for both FPC and Lazarus. Then simply click Install/Update FPC and Lazarus. Make sure the bottom log mentions the patches succesfully applied. Once that is done, go to the Cross tab, choose aarch64 and Windows, and click Install compiler. Agree to download the cross-tools and wait. When everything is finished, you will have a full Lazarus package and three compilers (Win i386, Win x64 and Win aarch64). Start Lazarus using the BAT file and you should be able to build for Windows on ARM by setting the target processor to aarch64 and the target system to Win64. These instructions worked for me on aarch64 Windows 11 when I installed the 32-bit version of Lazarus itself (attempting to install the 64-bit version of Lazarus caused a failure in the FPCUPDLX process). I was able to create and run an empty project1.exe GUI app and verify that the platform shows as pure Arm64 in the Windows 11 Task Manager. I was also able to create and build an empty DLL. Now comes the real testing ---------------------------------------------------------------------- PascalDragon · 2026-02-03 22:49 Quote from: Wallaby on January 30, 2026, 08:49:16 amQuote from: ALLIGATOR on January 30, 2026, 08:46:25 amBy the way, does anyone have a ready-made recipe for running Windows ARM in QEMU on x86_64 Windows? Maybe everything is already preconfigured and ready to run? I've tried that, but it was painfully slow and unreliable even running on a 6Ghz 13900KS. Better get a mac-mini and run in Parallels, or a snapdragon-based laptop. I personally use a Pi 4 and run Windows 10 there through KVM- accelerated QEMU. Works well enough for tests (though maybe I'll upgrade to a Pi 5 in the future). Quote from: msintle on January 30, 2026, 12:27:10 pmWhy do you find it funny that the previous request was also about aarch64-win64? Because you think in every other area Lazarus is already perfect, a done deal, with no room for growth and/or improvement left? Or is it funny that the company chose the most strategic area for development that begged for improvement, and continues to press this agenda forward in spite of your opposition - and may have even succeeded now, despite your best efforts to block progress by exercising a degree of control that is, by now clearly seen to be, unwarranted and counterproductive to all users of the product? I'd say, get used to FPC/Lazarus outgrowing you and your control. This incident has demonstrated that despite your efforts to backpedal, no matter how "well" they may be intentioned; your creation has already grown beyond you. It's not the point that multiple bounties were offered to help motivate fixing the issues that I find funny (or better “ironic”), but since you directly asked: it's ironic that it was you and your company who asked for attestation back then and were denied and asked now again and - surprise - are denied. ---------------------------------------------------------------------- msintle · 2026-02-04 12:37 Quote from: PascalDragon on February 03, 2026, 11:49:53 pmIt's not the point that multiple bounties were offered to help motivate fixing the issues that I find funny (or better “ironic”), but since you directly asked: it's ironic that it was you and your company who asked for attestation back then and were denied and asked now again and - surprise - are denied. Oh that's a lot less venom than I was prepared for - says a lot about the relative maturity of this community. You are certainly free to deny any approval in code comments per our earlier request. The company remains free to take full credit for bringing Lazarus (and Free Pascal) to aarch64 on Windows, ahead of even Delphi itself! Regarding the bounty, we had already anticipated this development and made alternative arrangements for its delivery. So this looks like a win-win-win for everyone so far ---------------------------------------------------------------------- Tourniquet · 2026-02-05 13:26 Quote from: Wallaby on January 30, 2026, 12:46:49 pmQuote from: msintle on January 30, 2026, 12:18:23 pmAnyways, are there installation instructions for the latest version of Free Pascal/Lazarus, so we can get down and dirty testing your work thus far against our existing code base? Download FpcupDeluxe here and drop it into any folder. Click the Setup+ button, then find Source patching – Add FPC patch and add all seven patches listed there (in the Open File dialog, choose *Patch* as the file type). Select trunk for both FPC and Lazarus. Then simply click Install/Update FPC and Lazarus. Make sure the bottom log mentions the patches succesfully applied. Once that is done, go to the Cross tab, choose aarch64 and Windows, and click Install compiler. Agree to download the cross-tools and wait. When everything is finished, you will have a full Lazarus package and three compilers (Win i386, Win x64 and Win aarch64). Start Lazarus using the BAT file and you should be able to build for Windows on ARM by setting the target processor to aarch64 and the target system to Win64. Wow thank you very much! So far it seems to work. I've noticed that it's important to use the linked FpcupDeluxe version. I did try it with a different one before but it failed. ---------------------------------------------------------------------- msintle · 2026-02-05 16:53 Quote from: Tourniquet on February 05, 2026, 02:26:49 pmWow thank you very much! So far it seems to work. I've noticed that it's important to use the linked FpcupDeluxe version. I did try it with a different one before but it failed. Can you please confirm the linked version URL? It does not seem to load at all for me here, I used the latest stock version from the releases page, but it fails on some devices still (notably, native ones). ---------------------------------------------------------------------- PascalDragon · 2026-02-05 20:17 Quote from: msintle on February 04, 2026, 01:37:30 pmOh that's a lot less venom than I was prepared for - says a lot about the relative maturity of this community. Well, I originally had one with a bit more venom, then I took a breath and let it stew a bit ---------------------------------------------------------------------- msintle · 2026-02-05 21:09 Quote from: PascalDragon on February 05, 2026, 09:17:07 pmWell, I originally had one with a bit more venom, then I took a breath and let it stew a bit I appreciate that! Fact is, we have all accomplished something huge to celebrate here, big time ---------------------------------------------------------------------- Tourniquet · 2026-02-05 22:01 Quote from: msintle on February 05, 2026, 05:53:13 pmQuote from: Tourniquet on February 05, 2026, 02:26:49 pmWow thank you very much! So far it seems to work. I've noticed that it's important to use the linked FpcupDeluxe version. I did try it with a different one before but it failed. Can you please confirm the linked version URL? It does not seem to load at all for me here, I used the latest stock version from the releases page, but it fails on some devices still (notably, native ones). github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/download/v2.4.0h/fpcu pdeluxe-i386-win32.exe This one worked fine for me. ---------------------------------------------------------------------- msintle · 2026-02-06 00:02 Quote from: Tourniquet on February 05, 2026, 11:01:57 pmThis one worked fine for me. That's the one I used. Funnily it fails in the second phase of instructions (cross-compiling) on native Snapdragon hardware (Surface Laptop 7), but runs on Windows 11 hosted inside Parallels running on aarch64 Macs. ---------------------------------------------------------------------- PascalDragon · 2026-02-07 21:33 Please note that even with the current fixes by Wallaby there are still issues with the implicit finally-blocks if they're executed as part of an exception path and managed parameters types are involved. Just as a warning for anyone who thinks they can rely on it now. ---------------------------------------------------------------------- Tourniquet · 2026-02-08 00:26 Quote from: msintle on February 06, 2026, 01:02:01 amQuote from: Tourniquet on February 05, 2026, 11:01:57 pmThis one worked fine for me. That's the one I used. Funnily it fails in the second phase of instructions (cross-compiling) on native Snapdragon hardware (Surface Laptop 7), but runs on Windows 11 hosted inside Parallels running on aarch64 Macs. Hmm sounds weird. For me it worked fine in the latest Windows 11 25H2 Version on native Snapdragon Hardware (Surface Pro 9 5g) ---------------------------------------------------------------------- msintle · 2026-02-08 01:29 Quote from: PascalDragon on February 07, 2026, 10:33:34 pmPlease note that even with the current fixes by Wallaby there are still issues with the implicit finally-blocks if they're executed as part of an exception path and managed parameters types are involved. Just as a warning for anyone who thinks they can rely on it now. Can you give an example so we can see what to avoid, for example? ---------------------------------------------------------------------- Wallaby · 2026-02-11 12:14 Updated set of patches. This resolves a few edge cases that the previous patches did not address: This crashed: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program texcept; {$mode objfpc}{$H+} uses  SysUtils; procedure Test(aArg: array of String);begin  raise Exception.Create('Blubb');end; begin end.  This crashed as well: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program texcept; {$mode objfpc}{$H+} uses  SysUtils; type  TTest = class    fName: String;    property Name: String read fName;  end; procedure Bar(const aArg: array of const);beginend; procedure Test(aArg: TTest);begin  try    raise Exception.Create('Test');  finally    Bar([aArg.Name]);  end;end; begin end.  In standard generics test this would fail due to a mismatch in how parameters are passed: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i TTestStdCollections.Test_MethodsList Building is same as the above with win32 FpcupDeluxe, use trunk/main adding two diff files 1268.diff and 1289.diff then installing the cross-compiler and Lazarus. ---------------------------------------------------------------------- msintle · 2026-02-11 15:06 Quote from: Wallaby on February 11, 2026, 01:14:00 pmUpdated set of patches. This resolves a few edge cases that the previous patches did not address: This crashed: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program texcept; {$mode objfpc}{$H+} uses  SysUtils; procedure Test(aArg: array of String);begin  raise Exception.Create('Blubb');end; begin end.  This crashed as well: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program texcept; {$mode objfpc}{$H+} uses  SysUtils; type  TTest = class    fName: String;    property Name: String read fName;  end; procedure Bar(const aArg: array of const);beginend; procedure Test(aArg: TTest);begin  try    raise Exception.Create('Test');  finally    Bar([aArg.Name]);  end;end; begin end.  In standard generics test this would fail due to a mismatch in how parameters are passed: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i TTestStdCollections.Test_MethodsList Building is same as the above with win32 FpcupDeluxe, use trunk/main adding two diff files 1268.diff and 1289.diff then installing the cross-compiler and Lazarus. Thanks for the update! So do we need the previous 7 patches as well as in the earlier instructions? This is for trunk only again, right? ---------------------------------------------------------------------- AlexTP · 2026-02-11 16:57 Wallaby, is your works 'synced' with this merge request? https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/1268 (updated 1 day ago) ---------------------------------------------------------------------- Wallaby · 2026-02-11 21:21 These patches are for the trunk/main only and yes, they are actually the latest ones from the MR. They supersede the old set, so only two files needed. One is from MR 1268 patches SEH on ARM64 (affects multiple files), the other patches code generation related to parameter passing MR 1289 (affects one file). They are logically separate, so two patches. Currently I have a set of 2,507 tests, primarily taken from the compiler testing framework and other open-source projects - they all pass with the above patches. ---------------------------------------------------------------------- msintle · 2026-02-23 13:47 Well, our grand test has succeeded. And this is no small feat. We've successfully ported our shell namespace extension from Delphi (which STILL doesn't support ARM64 after a decade!) to Lazarus. And, it works flawlessly - in some respects, better than the Delphi extension itself! You can see it for yourself in action here: www.installaware.com/arm64/diskzip.exe Don't be misled by the arm64 moniker, the install properly installs 32 bit components on a 32 bit OS, 64 bit components on a 64 bit OS, and ARM64 components on a 64 bit ARM OS (Snapdragon native PCs, or Parallels Windows VMs on apple silicon). The only reason this isn't live on the main site yet is because we're still porting other code from Delphi to Lazarus, but getting back to the point: the shell namespace extension is the hardest one, by and far. And we were able to get it done in under a week! Which says a LOT. Why is a shell namespace extension so hard, what does it do, and why are we so confident that this validates the Lazarus ARM64 efforts at large? It's basically a COM object that integrates with File Explorer, using (still) mostly undocumented interfaces (which was part of a lawsuit against Microsoft); in our case, it helps you browse inside archives inside File Explorer just like they are ordinary folders (when they obviously aren't). This is called a non-rooted shell namespace extension (whereas, having a fixed "root" off the Desktop, say for something like a cloud drive, makes it a somewhat simpler rooted extension). Again, this is the most complex and challenging type of programming undertaking that may actually exist on Windows. You make the slightest mistake, Explorer freezes - or crashes. Your compiler makes the slightest mistake - Explorer freezes, or crashes. The way we've done it, we're showing our own Lazarus form INSIDE File Explorer - so when you browse inside an archive, File Explorer handles the Tree view - and we internally handle and render the List view. Getting this working properly - to say nothing of in a highly performant manner - is truly nothing short of a monumental undertaking. 7-Zip's own author Igor Pavlov - the outright genius who invented 7-Zip - gave up on this decades ago, because he had better ways to spend his time. Gals and guys, Lazarus handled this beautifully. Again, see for yourself - just double-click any archive, and watch it load inside File Explorer as any ordinary folder (of course, please try this only on an ARM64 Windows instance, or you won't be seeing the Lazarus compiled code in action; but legacy Delphi code instead, which we haven't recompiled for downlevel platforms [as of this writing, the shell namespace extension code we did port to Lazarus has been evolving for the past twenty four {24} years]). It is worth mentioning that while Windows now does show archives other than ZIP as folders, its own implementation is still extremely slow (try browsing inside archives with [tens of] thousands of files in them and see how long it takes), and can't handle things like copy/paste (copy any number of files from the source archive and extract them transparently using the Paste command on a real file system folder, for example). Copy/paste is actually a great example because guess what, all that copy/paste stuff (especially when the data to paste doesn't even exist yet - it is compressed inside your archive!) relies on even more complex and extremely difficult Windows interfaces which, you guessed it - Lazarus runs flawlessly on ARM64 Windows!!! We also ported far simpler shell extensions you can check out, of course. Hover your mouse over an archive - you get a tooltip showing what's actually inside. Explore the new Archives tab inside the File Properties window to get a static listing of all the files inside that archive (and view/extract/update items using the relevant buttons). All of it - coming from Lazarus. A really fun one is - add an archive extension (ex: .7zip) to an existing folder. Instead of Windows renaming that folder, our Lazarus shell extension kicks in - and you get an archive of the specified type, instantly built; out of the intact contents of that folder. And of course, the usual right-click context menu extensions (including Windows 11 top-level menu extensions, but InstallAware's Context Menu Bridge ports them over to the top-level, we can't take credit for that - although we did natively implement the right-click menus too in Lazarus ARM64 [these are really the least interesting, as ARM64 Windows does successfully emulate x86 and x64 context menu extensions for the most part {I say mostly, because its emulation in that regard has been very buggy and fickle, still unfixed over the years}]). But none of these other shell extensions - for which, except where noted (just the context menus), you still DO need a pure ARM64 compiler like we now have thanks to the efforts of you amazing folks - are nearly a hundredth as complex as that crown jewel, the shell namespace extension. So as far as we can tell - Lazarus has totally  N A I L E D   I T  here!!!  C O N G R A T U L A T I O N S ! ! ! ---------------------------------------------------------------------- msintle · 2026-03-08 20:23 Here's our porting case study, with tips and tricks we learned along the process ("best practices" in industry jargon): www.installaware.com/blog/?p=986 And here's our point-and-click installer for Lazarus on ARM64/Windows: www.installaware.com/lazarus-arm64.msi Once again, thank you everyone for making this happen! ---------------------------------------------------------------------- Wallaby · 2026-03-19 23:16 Embarcadero has just released a new version of Delphi with ARM64 support. The catch is, it's ARM64EC, so it won't allow shell extensions and things like that (I believe ARM64 processes can't load ARM64EC DLLs). ---------------------------------------------------------------------- msintle · 2026-03-20 11:26 Quote from: retrofoxed on March 20, 2026, 12:16:25 amEmbarcadero has just released a new version of Delphi with ARM64 support. The catch is, it's ARM64EC, so it won't allow shell extensions and things like that (I believe ARM64 processes can't load ARM64EC DLLs). That is absolutely correct, and is the greatest irony of Delphi Florence 13.1! ARM64EC DLLs may only be loaded by x64 EXE's, and ARM64EC EXE's may only load x64 DLL's - entirely defeating the purpose That's what Lazarus's TRUE ARM64 is for - and hoping the case study helps people stuck with Delphi port on over. Once again, congratulations to the whole Lazarus team - we've all done this, together. I'll refrain from commenting on how this may reflect upon Delphi though ---------------------------------------------------------------------- 440bx · 2026-04-03 03:42 @retrofoxed/Wallaby, Off topic and again, strictly out of curiosity, did you use an A.I model to help you implement ARM64 Windows SEH correctly ? As in a previous thread where you answered a similar question, I will _not_ elaborate on the topic no matter what your answer is.  I just want to know if A.I was involved and if the answer is "yes", if possible, how helpful do you consider its input/help was. Thank you. ---------------------------------------------------------------------- Thaddy · 2026-04-03 04:09 @440bx -equally off-topic - Maybe it is a good idea to open a new topic for that, or even a new forum category. I tend to support the latter. It is such an important topic and many of us use it on a daily basis. I have - kind of - a log on where AI definitely was a great help, either as time-saver or to correct logic, finding corner cases, or writing tests and its use can differ between amazing, jaw dropping, to horrible and time wasting, equally jaw dropping. And the experiences greatly differ between models with all of them having pro's and con's. For example this week I wrote the /= bug fix and you can immediately see that the int := int /= float part was helped by AI, the rest being my work, which you can also immediately see, and the test was even pure AI and documented as such. (My coding style and documentation where AI was used - with a different coding style for example) I think that for the time being at least such new code writing experiences can be enlightening in how AI is a help or a nuisance if we share our experiences. ---------------------------------------------------------------------- 440bx · 2026-04-03 04:24 Quote from: Thaddy on April 03, 2026, 06:09:38 amor even a new forum category. I would  be in favor of that. Since there isn't currently such a forum and, the question is directly related to the topic, I figured that I'd ask here instead of creating a new thread just to find out if A.I was helpful for this _specific_ task.  IOW, the question is only 50% off topic ---------------------------------------------------------------------- Thaddy · 2026-04-03 04:33 Well, then I open a new topic to see if the users support it... ---------------------------------------------------------------------- 440bx · 2026-04-03 04:41 Quote from: Thaddy on April 03, 2026, 06:33:29 amWell, then I open a new topic to see if the users support it... I have to admit being a little reluctant to do that... I suggested the creation of a forum section for A.I in the following post... https://forum.lazarus.freepascal.org/index.php/topic,73804.msg579974.h tml#msg579974 and the thread got locked soon after that.  I don't know if that post contributed to it but, for some reason, I feel A.I isn't generally speaking welcome around here (admittedly, I could be wrong but, that's the impression I have.) ---------------------------------------------------------------------- Wallaby · 2026-04-03 05:54 Quote from: 440bx on April 03, 2026, 05:42:31 am@retrofoxed/Wallaby, Off topic and again, strictly out of curiosity, did you use an A.I model to help you implement ARM64 Windows SEH correctly ? As in a previous thread where you answered a similar question, I will _not_ elaborate on the topic no matter what your answer is.  I just want to know if A.I was involved and if the answer is "yes", if possible, how helpful do you consider its input/help was. Thank you. The same AI (Claude) did most of the work on that issue, with my steering and debugging expertise. It (the AI) had a funny tendency of suggesting a quick and dirty fix like so: AI: "Hey look, I've fixed everything" Me: "Nope, it's a shitty workaround masking the bug" AI: "Yes, you are right!" Me: "Do this, that and this and get to the bottom of it" ... Many iterations later we actually arrive at a proper solution. TBH, while I have no idea how compilers really work and no understanding of assembly, I feel with proper guidance one could easily fork FPC and turn it into a better product. Trim it a little of old baggage (really, does anyone program for Z80 or AMIGA running M68000?) keep the modern platforms only Linux/Windows/macOS/BSD on x64/arm64, maybe riscv64 (Android/iOS would be nice too, but need a widgetset). The AI is amazing so that it can read specs way faster, design and prototype at 10-100x human speed under proper guidance. I dare to say the FPC team are either pursing their own areas of interest, or simply not care, as we can see from zero releases for 5 years; my ready-to-merge ARM64 patches were simply ignored, so it's only a matter of time until someone takes matters into their own hands. ---------------------------------------------------------------------- 440bx · 2026-04-03 06:17 retrofoxed, thank you again for the extensive and detailed reply. I asked the question for two reasons, the first one was, I was genuinely curious to know if you had used A.I to solve the problem.  The second one was, exception handling is not something easy to master and, I've read replies about it given by some A.I models that definitely showed the A.I thing had no clue. That said, as a result of your comments and those of other users, such as schuler, I've been studying how to use A.I and, Claude Code in particular.  I was curious about how well versed Claude Code was about x64 exception handling and asked a few questions about it, I have to admit that, I was very surprised about the accuracy and high quality of the answers.  Unlike you, I didn't ask it to solve a particular problem but, its theoretical knowledge is solid, it explained the exception handling process in detail and accurately.  I didn't expect that, I thought it would make conceptual mistakes and, to my surprise, it didn't make any.  Granted, I didn't ask it to solve a problem, just to show its knowledge of the subject in the form of explanations but, since it can do that correctly, I figured there is a good chance it could create the correct mechanisms for a compiler to use the facility. The one thing I did experience in the process is its ability to flatter the "conductor" which I found very amusing   Apparently, it knows something about human nature too ---------------------------------------------------------------------- Wallaby · 2026-04-03 06:28 Well, not all AI is the same. Most free models are pretty much useless, but the commercial frontier ones are extremely capable. Even in areas where they lack knowledge, they can read code and specifications far faster than any human, and iterate — writing, refactoring, and testing ideas — at a completely different pace. One thing I did find odd is that it tends to avoid using tools unless explicitly pushed. For example, with the exception issue it just kept doing static analysis until I stepped in and said: here is an ARM64 machine, here is cdb, here is a disassembler, here are the Microsoft specs — now go and figure it out. So yes, it definitely needs steering in the right direction, but once pointed properly, it usually gets the job done. ---------------------------------------------------------------------- 440bx · 2026-04-03 06:56 Quote from: retrofoxed on April 03, 2026, 08:28:56 amWell, not all AI is the same. Most free models are pretty much useless, Yes, I've noticed that too...    which I have to admit was the foundation of my previously entirely bad opinion about A.I. Quote from: retrofoxed on April 03, 2026, 08:28:56 amI stepped in and said: here is an ARM64 machine, here is cdb, here is a disassembler, here are the Microsoft specs — now go and figure it out. That is some serious pushing... good to know that sometimes that's what it takes to have the thing get some real work done. Quote from: retrofoxed on April 03, 2026, 08:28:56 amSo yes, it definitely needs steering in the right direction, but once pointed properly, it usually gets the job done. Correctly implementing exception handling is no trivial stuff.  It really shows that A.I can definitely be useful when given proper direction. On topic: well done on fixing the ARM64 exception handling issues. ---------------------------------------------------------------------- msintle · 2026-04-03 14:59 Great reflections. I agree with your findings on AI 100%. I also find that some sessions are useless, whereas others are great - even on the same topic, with the same starting initial conditions. Probably due to temperature and whatever other random settings they have? That's the scariest thing about AI for me, but I guess, even with humans - there's useful personalities, and then useless ones as we well know. For example in my "super large" sample set on a recent project, the first Claude session was useless, the second was useful but we missed some things at our end (resulting in us almost not realizing our issue had actually been solved), the third session was also useless. By useless I mean absolutely hopelessly useless - in stark contrast to the session that was actually entirely useful. This is all with the free version of Claude, BTW. ---------------------------------------------------------------------- PascalDragon · 2026-04-06 08:48 Quote from: retrofoxed on April 03, 2026, 07:54:36 amTBH, while I have no idea how compilers really work and no understanding of assembly, I feel with proper guidance one could easily fork FPC and turn it into a better product. Trim it a little of old baggage (really, does anyone program for Z80 or AMIGA running M68000?) keep the modern platforms only Linux/Windows/macOS/BSD on x64/arm64, maybe riscv64 (Android/iOS would be nice too, but need a widgetset). Z80 was only added in main (so calling it “old baggage” is wrong), but even then there are people who welcomed it. I know at least one user who welcomed the z80-msxdos port, because there only TP 3.0 exists. And Amiga is also actively used by various users, most importantly Alb42. Also once a code generator is working maintaining it and adding new targets is a small effort. Main maintenance is the parser. Quote from: retrofoxed on April 03, 2026, 07:54:36 amI dare to say the FPC team are either pursing their own areas of interest, or simply not care, as we can see from zero releases for 5 years; my ready-to-merge ARM64 patches were simply ignored, so it's only a matter of time until someone takes matters into their own hands. They are not ignored. It's simply that life happened. The last two months and the next few weeks I'm extremely busy with topics completely outside of FPC and there's still one issue in your changes where I wanted to make sure that this doesn't negatively affect x86_64-win64. ---------------------------------------------------------------------- Wallaby · 2026-04-06 09:09 Quote from: PascalDragon on April 06, 2026, 10:48:12 amZ80 was only added in main (so calling it “old baggage” is wrong), but even then there are people who welcomed it. I know at least one user who welcomed the z80-msxdos port, because there only TP 3.0 exists. And Amiga is also actively used by various users, most importantly Alb42. Also once a code generator is working maintaining it and adding new targets is a small effort. Main maintenance is the parser. I see your point, and I agree that supporting additional targets can be valuable, especially when the maintenance overhead is low. From my perspective, though, it often makes sense to prioritise what benefits the majority of users. In my own projects, I occasionally get requests for niche features that only one person would use, and in those cases I usually decline to keep things simple and maintainable. A compiler is obviously a different kind of project, and as you said, adding targets may not be that costly once the groundwork is there. That said, if it were up to me, I’d probably still lean towards focusing effort on the most widely used platforms. But I understand this is an open-source project, and the team may value broader platform support for different reasons, including experimentation and community interest. Quote from: PascalDragon on April 06, 2026, 10:48:12 amThey are not ignored. It's simply that life happened. The last two months and the next few weeks I'm extremely busy with topics completely outside of FPC and there's still one issue in your changes where I wanted to make sure that this doesn't negatively affect x86_64-win64. That’s good to hear, I’m glad it hasn’t been forgotten. If I may suggest one thing, a short update would go a long way in situations like this — even something brief like “I’m currently busy, will get back to this soon.” When someone has invested a significant amount of time and effort, a bit of feedback helps avoid the impression that their work has been overlooked. ---------------------------------------------------------------------- msintle · 2026-04-07 15:13 Quote from: PascalDragon on April 06, 2026, 10:48:12 amThey are not ignored. It's simply that life happened. The last two months and the next few weeks I'm extremely busy with topics completely outside of FPC and there's still one issue in your changes where I wanted to make sure that this doesn't negatively affect x86_64-win64. I'm afraid none of us are immune to this "life effect". We don't live in a vacuum. I am often reminded time and again what a luxury it is - against all appearances - to be working in this industry. We truly all have a heck lot to be grateful for! ---------------------------------------------------------------------- szlbz · 2026-07-07 23:53 Quote from: Wallaby on January 25, 2026, 04:32:39 amI've got lazarus and the compiler fully working on aarch64. Lazarus still has a few issues, like there is no debugger (fpdebug only works with Intel/AMD), but otherwise things look good. See screenshots below. I'll now PM msintle about further testing and the bounty. hi Wallaby,Lazarus can be compiled now, thank！ ---------------------------------------------------------------------- Martin_fr · 2026-07-20 05:58 Can anyone please check this https://gitlab.com/freepascal.org/lazarus/lazarus/-/work_items/42427 According the the reporter there is a TSmallPoint (x/y of Smallint). And (at some time) after assigning to TPoint (integer) the negative value in one of the 2 smallint becomes a value of 65520 (rather than -5 / or similar). I don't see any code that would just cast the bit sequence into the integer type. It really should be sign extended. I highly suspect a compiler bug. ---------------------------------------------------------------------- Thaddy · 2026-07-20 07:39 Quote from: Martin_fr on July 20, 2026, 07:58:29 amI highly suspect a compiler bug. I highly suspect multiple Tsmallpoint declarations.... and wrong unit order. Will test Lin64/AARCH64 and Apple, can't test Windows/AARCH64 ---------------------------------------------------------------------- szlbz · 2026-07-22 06:35 https://www.cnblogs.com/qiufeng2014/p/21761713 ---------------------------------------------------------------------- szlbz · 2026-07-22 08:27 Quote from: Thaddy on July 20, 2026, 09:39:06 amQuote from: Martin_fr on July 20, 2026, 07:58:29 amI highly suspect a compiler bug. I highly suspect multiple Tsmallpoint declarations.... and wrong unit order. Will test Lin64/AARCH64 and Apple, can't test Windows/AARCH64 The data obtained from the same code on Linux aarch64 is correct ---------------------------------------------------------------------- DonAlfredo · 2026-07-25 11:46 I have found a fix. Not sure if 100% correct. Testers are welcome. https://gitlab.com/freepascal.org/fpc/source/- /work_items/41822#note_3601167731 ---------------------------------------------------------------------- msintle · 2026-07-27 23:40 Quote from: szlbz on July 08, 2026, 01:53:22 amQuote from: Wallaby on January 25, 2026, 04:32:39 amI've got lazarus and the compiler fully working on aarch64. Lazarus still has a few issues, like there is no debugger (fpdebug only works with Intel/AMD), but otherwise things look good. See screenshots below. I'll now PM msintle about further testing and the bounty. hi Wallaby,Lazarus can be compiled now, thank！ Congrats! Is the debugger working yet? What steps did you follow to compile Lazarus - FPCUPDLX? ---------------------------------------------------------------------- msintle · 2026-07-28 20:49 BTW the previous patches don't seem to work very well anymore. I can get 1289 and this latest one to work but not the preceding 1268. And sadly choosing trunk for both FPC and Lazarus, FPCUPDLX isn't able to compile anymore! ---------------------------------------------------------------------- DonAlfredo · 2026-07-29 05:49 All FPC changes have been merged into trunk. FPC trunk works out-of- the-box on Windows ARM64. As does Lazarus. Few issues remain. One major issue still open: Lazarus must use lldb debugger. ---------------------------------------------------------------------- Martin_fr · 2026-07-29 06:56 Quote from: DonAlfredo on July 29, 2026, 07:49:06 amAll FPC changes have been merged into trunk. FPC trunk works out-of-the-box on Windows ARM64. As does Lazarus. Few issues remain. One major issue still open: Lazarus must use lldb debugger. Unfortunately I don't have an aarch64 machine. I managed to get Linux running on acceptable speed in qemu. Given that FpDebug works on aarch64 Linux (except for asm view, and except watchpoints), then Windows should be quite easy to do. Subclass the existing TDbgWinProcess. The main change should be the handling of registers. New names, different layout of the context record. Then use the same unwinder as for Linux aarch64. So if anyone wants to try changing that... And as a bonus: CallParamDefaultLocation (e.g. to get the correct message for an exception when caught). Also, I guess its not SEH? But that may be already handled, because "ifdef Win64" was already replaced to exclude aarch64 (but may need to be checked if there are some left...) ---------------------------------------------------------------------- msintle · 2026-07-29 12:47 Quote from: DonAlfredo on July 29, 2026, 07:49:06 amAll FPC changes have been merged into trunk. FPC trunk works out-of-the-box on Windows ARM64. As does Lazarus. Few issues remain. One major issue still open: Lazarus must use lldb debugger. I'm actually unable to compile trunk FPC and trunk Lazarus at all right now, using the win32 version of FPCUPDLX targeting win32. I'll take another look at it using the arm64 builds for everything. I suppose then we just ever have one patch left to merge in (winarm64.patch)? ---------------------------------------------------------------------- msintle · 2026-07-29 13:10 Trying stable/stable with just the one latest patch merged in, I get this error: Makefile:215: *** The Makefile doesn't support target aarch64-win64, please run fpcmake first.  Stop. When trying to build with aarch64 native FPCUPDLX. Using latest jp version downloaded fresh. Edit: same result with trunk/trunk. ---------------------------------------------------------------------- DonAlfredo · 2026-07-29 16:37 You can use trunk FPC hash e8e8e8b4. That will work. ---------------------------------------------------------------------- msintle · 2026-07-29 22:25 Quote from: DonAlfredo on July 29, 2026, 06:37:25 pmYou can use trunk FPC hash e8e8e8b4. That will work. Doesn't seem to? C:/Users/me/Downloads/fpcupdeluxe/fpcbootstrap/ppca64.exe -Ur -Xs -O2 -n -Fi../inc -Fi../aarch64 -Fiaarch64 -Fi../aarch64 -Fi../win/wininc -FE. -FUC:/Users/me/Downloads/fpcupdeluxe/fpcsrc/rtl/units/aarch64-win64 -vw-n-h-l-d-u-t-p-c- -dREVINC -daarch64 -dRELEASE -Fi../win -Us -Sg system.pp system.pp(460) Error: Assembler clang.exe not found, switching to external assembling Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted make[6]: *** [Makefile:3763: win64_all] Error 2 make[5]: *** [Makefile:5634: rtl] Error 2 make[4]: *** [Makefile:5466: next] Error 2 make[3]: *** [Makefile:5472: ppc1.exe] Error 2 make[2]: *** [Makefile:5484: cycle] Error 2 make[1]: *** [Makefile:3328: compiler_cycle] Error 2 make: *** [Makefile:3360: build-stamp.aarch64-win64] Error 2 fpcupdeluxe: ERROR: FPC Native Installer (BuildModule: FPC): Error running C:\Users\me\Downloads\fpcupdeluxe\fpcbootstrap\make.exe for FPC failed with exit code 2 . Details: . ERROR: Fpcupdeluxe fatal error ! Sequencer (FPC): Failure running fpcupdeluxe: error executing sequence FPC Sequencer (Default): Failure running fpcupdeluxe: error executing sequence Default ---------------------------------------------------------------------- DonAlfredo · 2026-07-30 07:20 The tools (clang) are here: https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/download/wind owsarm64_bins_all/Windows_All_Clang_15.zip Extract and just put or drop and overwrite them inside of the fpc\bin\aarch64-win64 directory. This is the directory where all tools are located, like make.exe, ar.exe, as.exe and more. ---------------------------------------------------------------------- msintle · 2026-07-30 13:22 Quote from: DonAlfredo on July 30, 2026, 09:20:29 amThe tools (clang) are here: https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/download/wind owsarm64_bins_all/Windows_All_Clang_15.zip Extract and just put or drop and overwrite them inside of the fpc\bin\aarch64-win64 directory. This is the directory where all tools are located, like make.exe, ar.exe, as.exe and more. Will try it this way - thanks! So the arm64 version of FPCUPDLX does not internally download everything it needs like the other editions, or is this temporary? Edit: Now I get Exception: EAccessViolation. Access violation as soon as the run begins! ---------------------------------------------------------------------- DonAlfredo · 2026-07-30 13:47 For sure magic will be added.  Speaking of ... new binary with magic just uploaded. You might test. https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/download/v2.4 .0jp/fpcupdeluxe-aarch64-win64.exe ---------------------------------------------------------------------- msintle · 2026-07-30 14:15 Quote from: DonAlfredo on July 30, 2026, 03:47:32 pmFor sure magic will be added.  Speaking of ... new binary with magic just uploaded. You might test. https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/download/v2.4 .0jp/fpcupdeluxe-aarch64-win64.exe I think I tested the latest version already, and it's broken as I edited my post above, instant exception at this point: 7/30/2026 5:14:05 PM: fpcupdeluxe: V513 (20260624) started. FPCUPdeluxe V2.4.0jp for aarch64-win64 running on Win64-10.0.26100 Built with: FPC 3.3.1 on Win11 x86_64 Checking dev-libs for win32 LCLWidgetType. ---------------------------------------------------------------------- DonAlfredo · 2026-07-30 16:08 My bad. New binary in the link. Thanks. https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/download/v2.4 .0jp/fpcupdeluxe-aarch64-win64.exe ---------------------------------------------------------------------- PascalDragon · 2026-07-30 19:01 Quote from: Martin_fr on July 29, 2026, 08:56:28 amAlso, I guess its not SEH? But that may be already handled, because "ifdef Win64" was already replaced to exclude aarch64 (but may need to be checked if there are some left...) It is SEH. Similar to x64, but with different meta data format. ---------------------------------------------------------------------- msintle · 2026-07-31 00:59 Quote from: DonAlfredo on July 30, 2026, 06:08:33 pmMy bad. New binary in the link. Thanks. https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/download/v2.4 .0jp/fpcupdeluxe-aarch64-win64.exe Happy to confirm it works - awesome! We now have a 64 bit ARM native Lazarus IDE ---------------------------------------------------------------------- DonAlfredo · 2026-07-31 05:31 Yes. FPC and Lazarus are amazing. Suitable now for so many systems. The devs have been and are magicians ! ---------------------------------------------------------------------- ydd · 2026-08-04 21:58 Quote from: DonAlfredo on July 30, 2026, 06:08:33 pmMy bad. New binary in the link. Thanks. https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/download/v2.4 .0jp/fpcupdeluxe-aarch64-win64.exe trying to run on virtual machine with Windows 11 for ARM on macbook air M4 getting error ---------------------------------------------------------------------- DonAlfredo · 2026-08-05 06:37 You need FPC and Lazarus trunk/main. ---------------------------------------------------------------------- ydd · 2026-08-05 18:57 Quote from: DonAlfredo on August 05, 2026, 08:37:19 amYou need FPC and Lazarus trunk/main. now I'm getting such error: ---------------------------------------------------------------------- ydd · 2026-08-06 16:54 I've tried to install Unleashed version, but got such error: ---------------------------------------------------------------------- Martin_fr · 2026-08-07 10:39 A test branch for FpDebug. (Hope it survived the rebase). Please test. https://gitlab.com/martin_frb/lazarus/-/compare/main...dbg%2Fwin- aarch64-fpdebug?from_project_id=28419588 - Should work: Breakpoints, stepping, watches, locals, basic stack (probably threads) - not stepping into finally blocks (not even without exception / well, might work with F7, since they are a subroutine) - Notify on raise exception / BUT NOT, stepping to except/finally - NO assembler - NO watchpoints - NO modify variables Given the speed of my QEMU setup, I have done almost no testing. ---- Aarch64 should not increase the PC when hitting a breakpoint (or so says any research I did). => But on my setup, Windows reports an increased PC. If breakpoints don't work for you (and possible even the target reports errors after silently passing one), then try the branch without the last commit "FpDebug: (Aarch64/Win) Adjust PC" ---------------------------------------------------------------------- DonAlfredo · 2026-08-07 12:11 Wow. I can debug !! Thanks very much. Quick work also. I did not do an extensive test, but the basics are working (like breakpoints and inspect). Very very good work ! ---------------------------------------------------------------------- Martin_fr · 2026-08-07 12:13 Quote from: DonAlfredo on August 07, 2026, 02:11:22 pmWow. I can debug !! Thanks very much. Quick work also. I did not do an extensive test, but the basics are working (like breakpoints and inspect). Very very good work ! That is with the "adjust pc" commit? ---------------------------------------------------------------------- DonAlfredo · 2026-08-07 15:59 Yes, I tested the latest sources ! ---------------------------------------------------------------------- Martin_fr · 2026-08-07 16:24 Added to main. Btw, the GDB that is in the fpc/bin/aarch64-win64 dir after installing with FpcUpDeluxe => that doesn't like the fileformat. Seems to be a gdb for x86? However that ended up there. ---------------------------------------------------------------------- DonAlfredo · 2026-08-07 16:37 Will solve. Thanks again for your work. ---------------------------------------------------------------------- Martin_fr · 2026-08-07 17:41 Quote from: DonAlfredo on August 07, 2026, 06:37:44 pmWill solve. Thanks again for your work. Well thanks for yours too. Without FpcUpDeluxe, I might never have gotten to it.  But thanks to your updates, it was one click to get all the infrastructure, all the dependencies, everything. And, it left me with a git based install, I could just add my local remote, pull in the changes I had on my main PC, and start testing. ---------------------------------------------------------------------- msintle · 2026-08-20 14:33 We've updated our installer: https://www.installaware.com/lazarus-arm64.msi And our blog: https://www.installaware.com/blog/?p=986 With the latest native ARM64 Lazarus IDE (and debugger). The installer will now install the 32-bit IDE if you're running on AMD or Intel, with the cross-compilation option as before. It'll install the native ARM64 IDE if you're running on an ARM64 device, with the awesome new native debugging that wasn't available before. This makes a convenient one-click option to get going for anyone who needs true ARM64 support. Delphi STILL can't get the job done A big thank you to everyone on the Lazarus team ---------------------------------------------------------------------- Igor · 2026-08-26 17:11 Thank you very much! Sounds very exciting. I felt the same in 2020 when I compiled for the first time for ARM64 target on Mac Developer Kit. I plan to try Lazarus and FPC on ARM laptop in the near future. ---------------------------------------------------------------------- Thaddy · 2026-08-27 06:37 @msintle I enjoyed reading your blog on this subject. Haven't got the MS/AARCH64 hardware, though. Have been using InstallAware in the past (company/bank) so I trust the quality is excellent. You explained very well that Delphi's  ARM64EC is actually a surrogate option. The Freepascal community has been profiting from a native AARCH64 compiler for a couple of years now and indeed, that is a great achievement. Thanks for your efforts. ---------------------------------------------------------------------- msintle · 2026-08-27 17:16 Quote from: Thaddy on August 27, 2026, 08:37:34 am@msintle I enjoyed reading your blog on this subject. Haven't got the MS/AARCH64 hardware, though. Have been using InstallAware in the past (company/bank) so I trust the quality is excellent. You explained very well that Delphi's  ARM64EC is actually a surrogate option. The Freepascal community has been profiting from a native AARCH64 compiler for a couple of years now and indeed, that is a great achievement. Thanks for your efforts. Many thanks, but all the credit is due to the excellent Lazarus team and FPCUPDELUXE! It was thanks to the encouragement and motivation of don Alfredo of FPCUPDELUXE that we even undertook this initiative at InstallAware. After a few false starts, the Lazarus community at large delivered! All we've done is repackage Lazarus - as installed by FPCUPDELUXE - in a single-click install experience, with combined bitness support. Once again, a massive shout out to the entire Lazarus community and don Alfredo! And we thank you also for your support of our blog post. There's a few gotcha's coming from Delphi indeed - which I hope our post helps alleviate