Windows ARM64 Support (Runtime/SDK) (Core) #197
Comments
|
Take into account that e.g. BouncyCastle with the SunEC Provider requires sunec and msvcp120 which is unavailable for arm64. So … mixed bag here. |
|
We don't make use of any of the native openjdk bits. |
|
Phrased differently: IKVM won’t be 100% arm64 compatible, because client libraries like BouncyCastle, which depend on (JDK8) sunmscapi, won‘t work on arm64, due to ancient dependencies and missing platform libraries. |
|
Ahh. If so they don't work now. |
|
So the hardest part of this is going to be adding Windows ARM64 PE support into IKVM.Reflection. Thing basically has it's own PEWriter, and includes a startup stub for executables, which is just an array of machine code.... obtained from somewhere. So will need an arm64 version of that. And a bunch of other stuff, like reallocation offsets, heap sizes, etc. Probably should defer this guy until we just replace IKVM.Reflection with System.Reflection.Metadata. |
|
+1, looking forward to this as a Windows on Arm (Arm64) user. I'm going to take a stab at it but I currently have low confidence that I'll be successful 😊 |
|
Okay. So my thinking on this hasn't changed since my last comment. There's not a whole lot of reason to struggle with updating IKVM.Reflection for this. Effort should instead be put into removing IKVM.Reflection, and emitting assembly data through SRM.Ecma335. This has the added benefit of allowing us to likely remove a good deal of #IFDEF statements that conditionalize System.Type. There's a bit of complication here, since IKVM shares the same code for runtime code generation and static code generation. And at runtime, we have to use DynamicAssembly, since we're compiling individual types on the fly. So, we need to use SR at Runtime, and SRM.Ecma335 at static time. And these aren't compatible APIs. One good thing is I think we can just switch to System.Type all throughout, since SRM provides MetadataLoadContext, which provides System.Type instances. But, all of the metadata building is going to have to have two paths. So, I think it makes sense to abstract that out through some interface. And then for runtime compilation, provide an implementation that makes use of SR. And for static time, provide an implementation that uses SRM.Ecma335. |
|
I was familiarizing myself a little with the code today, and noticed the .NET FX 4.6.1 build, and of course only 4.8.1 is supported for ARM64. After the work is completed that you mention above, does this mean that 4.8.1 would need to be added as an additional target framework, while ignoring 4.6.1 for win-arm64? Or just ignore .NET FX entirely on win-arm64 and go straight to i.e. .NET 6? |
|
There's a lot of things. First, the executables will need to have an additional NET481 target for ARM64. 'ikvmc' will need to be capable of generating such things from JAR files. 'ikvmc' right now is incapable of generating Framework executables for ARM64. Second, for Core, Core 3.1 doesn't support ARM64 at all. So for that we'd need to support the executables running in .NET 5 or above. Which means we'd need to support a drop for .NET 5.0. |
|
Reading through this it sounds as if neither for .NET framework nor for .NET Core IKVM on Windows supports ARM64. Why does https://github.com/ikvmnet/ikvm say: "Windows x86/x64/ARM/ARM64"? |
|
Because it'll run on it. We can't build the executables though: so no ikvmc, etc. No tools or build environment. But the apps you make that use IKVM will run on ARM64. |
|
So trying a project IKVM.NET.Sdk/8.5.0 with a build configuration ARM64 is expected not to work and show errors like e.g. |
|
What exactly are you trying to build there? |
|
Hmm. Ok. I get it. Targeting framework. Which requires the tool chain to emit a PE. It will be fine on Core, which doesn't require that. But also if you just build a platform independent library and only reference it from a platform dependent assembly. |
|
I managed to use that IKVM.NET.Sdk/8.5.0 with the default Any CPU configuration to compile the Saxon HE 10.9 Java sources to .NET (the allowed target frameworks Now I am experimenting whether the lib from that project can be used to build Windows ARM64 versions of Saxon's C#/.NET command line tools But I am not sure I have grasped how far a platform independent build will get me, probably better to see later this day when I have access to an ARM64 machine whether the code runs without experimenting with all the configuration switches. |
|
So here's the background on this: In order to generate .exe files, you have to emit Windows PE files. Portable Executables. That's native code. With headers, tables, and all that entails. IKVM has it's own entire implementation of doing this, in IKVM.Reflection. IKVM.Reflection is a nearly complete copy of System.Reflection. Including System.Reflection.Emit. From 10 years ago. The problem is nobody ever added the ARM64 PE support to IKVM.Reflection. So, consequently, ikvmc cannot emit ARM64 PE files. This doesn't matter in Core, because PE file generation has been removed from the toolchain. Instead, apphost.exe is precompiled and distributed by MS for the available platforms, and the SDK just copies it into output. And the toolchain only has to produce a .dll file. So, when targeting Core, everybody is really just using the exact same apphost.exe file, copied and renamed. IKVM doesn't have to do anything. So, narrowly, this restriction we have applies to generating PE files for Windows for ARM64. Anyway you can avoid that avoids the issue. Easy option: use IKVM.NET.Sdk to generate a library instead. And then just call that library from a standard C# project which can generate an ARM64 executable. Or use Core, where none of that matters. |
|
Thanks, it indeed seems VS 2022 Windows let's me publish .NET 6 or 7 executables for the different operating system and architecture (e.g. amd64 vs arm64) options. I will need to check later whether the Windows 11 x64/amd64 machine really creates stuff for a Mac with OSX and ARM 64 or a Linux ARM 64. That looks all promising currently, just need to check later whether it runs on the target system(s). |
|
It does. We don't use Configuration any more though. We used RIDs |
|
I have now tested some of the VS publications on some different machines and other than the lack of OSX M1/M2 (arm64) and the lack of .NET framework arm64 support it seems to work fine. Looking at the published files, I however wonder, whether, if I wanted to create installers or a zip of files for a certain platform, for every platform there needs to be a whole lot of ikvm subdirectories e.g. if I publish for e.g. Linux arm64 and net6.0 Visual Studio creates a folder named Am I right to assume that any .net 6 app I want to use on or package for Linux and arm64 only needs that |
|
You are correct. We need to fix the build scripts to only publish the appropriate folder. But it's not super easy because we need to trace compatibility between RIDs. So right now we just include them all. For instance, if you publish RID ubuntu-20.04-x64, we need to include linux-x64. Hard to determine. |
|
The real issue here hasn't changed. Still can't emit .exe files for AMR64. But, as to @martin-honnen's mention of the ikvm/ image directory: in 8.7, we rewrote the IKVM.Image logic to better detect the target platform (by navigating the RID graph), to determine the appropriate RID of the image to emit to the publish directory, and to remove instances where downstream library files compiled without RID being included into upstream executables with RID were including unnecessary files. publish, now, should only include the single ikvm/ image for the target platform (unless doing a platform independent publish, where everything is still included). |
|
8.7.0 is going to add support for the SDK and the Runtime for .NET Core for Windows ARM64. Which is a pretty big advancement, I think. Still no Framework, because of our lack PE support. Going to duplicate this issue for Framework, and allow this one to close as part of 8.7.0. |
wasabii
changed the title
|
Great, is that SDK and runtime support already in the preview 2 of 8.7? I might have missed that being busy testing the MacOs ARM64 support. |
|
It will be in the next build. I'll do one more preview. |
|
@wasabii , I am curious (and don't have always access to that architecture to just test), does the preview 3 of 8.7 now support .NET 6 on ARM64 for the SDK? Or is that only coming in the final 8.7 release? |
This would be nice to add, and should be no big deal.
[EDIT]
It is.
The text was updated successfully, but these errors were encountered: