I'm considering porting my memory hungry, CPU-bound program from Windows Forms to Blazor. It is very resource intensive, and routinely consumes > 4 GiB of memory. This precludes it from running in a 32-bit address space.
However, the GUI components can clearly consume a view model that hides this large memory consumption from the caller. The Windows Forms code is already partitioned into an "engine" part and a "user interface" part. The engine does almost no UI, but is CPU-bound.
In the Windows Forms program, I could spawn a 64-bit process hosting the engine. This process could expose a View Model that the Windows Forms program could consume over some suitable IPC protocol. The Windows Forms program could then be a 32-bit client of the 64-bit process.
I want to make the Blazor application feel like a traditional desktop app: SPA and serverless. Ideally, users would visit a web page, download the Blazor app, and then start using it without having to comminicate with some "compute server" -- the engine should be running on the user's machine. However, I'm not sure how I can spawn the 64-bit engine process from the Blazor program.
How would you go about designing this to circumvent the limitations of wasm (32-bit address space)?
I don't belive this qualifies as an answer but at least it could give you some starting points and maybe someone more experienced in this area could supplement a better answer later.
Let's start with the assumption that you will split what you have into UI and engine processes as there is no way for web-based technologies to fulfill your performance requirements meaningfully. So this is about "how to make a Blazor UI with native capabilities". Note that this has implications for your distribution/deployment: I'd expect the end user has to install the engine process (native) and UI before launching them.
There are lots of SPAs that actually ship as native applications. This is typically done through a wrapper shell that is a native app that bootstraps and runs the SPA, similarly to how a web browser would (this is also referred to as a hybrid app). A developer typically has the capability to modify the shell, including integrating native capabilities. However, since such shells are typically cross-platform, they tend to be limited in their capabilities to the least common denominator. There are exceptions, though - Xamarin.Forms, for example, allows you to create platform-specific assemblies with low-level capabilities.
Such wrappers, however, do typically come with some quirks with respect to UX or performance - if you ever used Slack or Postman for longer periods or move them between screens, you will know what I mean. These apps simply don't feel native and sometimes end up eating 100% of one your CPU cores until you restart them.
I do believe you will spend a lot of time to make the wrapper integration work correctly, especially if you will want the wrapper to do IPC for you.
In that light:
How would you go about designing this to circumvent the limitations of wasm (32-bit address space)?
I wouldn't. There is a reason why WinForms and WPF are still supported.
These are some of the wrapper technologies from the top of my head if you are still interested in researching them (with the risk of being flagged off-topic):
EDIT:
There is also BlazorWebView control for WinForms and WPF since .NET 6 Preview 3, you might want to give that a shot. The concept is similar to other wrappers, but being able to use this from WinForms directly, you can experiment with using Blazor and gracefully port your application to it without disrupting any business continuity.