ARM64 version needed

[lionelconswork]

We'd appreciate an ARM64 version to run&test opensource filesystem drivers using BootBypass

[lionelconswork]

@wesmar Maybe I am wrong, but is it simply replacing build_pooldiag.cmd /platform:x64 with build_pooldiag.cmd /platform:arm64?

[lionelconswork]

Never mind, there is also https://github.com/wesmar/BootBypass/blob/556711f000984a3bc97b8f63c01a5c75ec7b005a/src/bbs.asm which must be translated to ARM64 assembler.

[wesmar]

@lionelconswork,

Thanks for reaching out! You've actually touched on two very critical architectural points here.

First, regarding the build platform change: while Windows 11 ARM64 can emulate x64 user-mode applications, it does not support kernel-mode emulation. Since this utility drops and loads a kernel driver, that driver must be compiled natively for the ARM64 architecture. Furthermore, because the main executable runs within the subsystem:native environment during the early boot phase (SMSS), standard Win32 x64 emulation layer isn't active there either.

Second, as you correctly noticed in your second comment, the assembly files (.asm) are strictly written for x64. Porting this to ARM64 is not just a matter of recompiling; those files require a complete translation to ARM64 assembly instructions and its specific calling conventions. But that's not a problem because I could handle it easily

The primary bottleneck for me right now is hardware. I don't currently own an ARM64 device such as a Snapdragon-based laptop to properly build, test, and dynamically debug this kind of low-level native/kernel code.

Once I get my hands on an ARM64 machine, I will definitely implement a proper native port. Alternatively, if anyone is able to assist by providing a temporary testing environment—for example, a Windows 11 ARM64 Hyper-V instance accessible via Tailscale so I can attach a remote debugger - I would be more than happy to cross-compile the code and look into resolving this sooner!

Best regards,
Marek

[lionelconswork]

@lionelconswork,

Thanks for reaching out! You've actually touched on two very critical architectural points here.

First, regarding the build platform change: while Windows 11 ARM64 can emulate x64 user-mode applications, it does not support kernel-mode emulation. Since this utility drops and loads a kernel driver, that driver must be compiled natively for the ARM64 architecture. Furthermore, because the main executable runs within the subsystem:native environment during the early boot phase (SMSS), standard Win32 x64 emulation layer isn't active there either.

Second, as you correctly noticed in your second comment, the assembly files (.asm) are strictly written for x64. Porting this to ARM64 is not just a matter of recompiling; those files require a complete translation to ARM64 assembly instructions and its specific calling conventions. But that's not a problem because I could handle it easily

The primary bottleneck for me right now is hardware. I don't currently own an ARM64 device such as a Snapdragon-based laptop to properly build, test, and dynamically debug this kind of low-level native/kernel code.

Once I get my hands on an ARM64 machine, I will definitely implement a proper native port. Alternatively, if anyone is able to assist by providing a temporary testing environment—for example, a Windows 11 ARM64 Hyper-V instance accessible via Tailscale so I can attach a remote debugger - I would be more than happy to cross-compile the code and look into resolving this sooner!

Best regards, Marek

I know that all kernel binaries must match the native hardware, we had that "fun" with the OpenZFS and Windows NFSv4.2 drivers. HyperV-instances we don't have, and server-farm is firewalled. I'll ask around.