My current foobar DSP plugin project requires more address space than is available to a 32-bit process. To get around that limitation, I use a virtual memory hack called File Mapping that allows multiple processes to map the same real memory space into their own virtual address space. It works very nicely but my implementation is not pretty because I am an old-time assembly language programmer who knows only a little C at the DOS level but nothing about programming C++, Windows, or foobar other than copying code snippets from tutorials.
As it works now, when my DSP plugin is initialized it attempts to open an existing file mapping object. If that fails, the plugin spawns a 64-bit companion process and then waits for the for the companion process to create a file mapping object. Once the plugin detects the file mapping object, the two processes begin the dance whereby they alternate access to the shared address space. In my implementation, the companion program and its file mapping object persist while the DSP plugin process comes and goes.
I hope an experienced foobar developer will expand this idea and create a package that will give any foobar component access to the advantages of a 64-bit environment without having to muck around with process creation, synchronization, messaging, and control.
That's a neat trick! :D
It's applications are limited though. Fb2k itself is 32bit, so it can't operate on 64bit pointers. Hence these 64bit pointers can be used only inside the plugin itself. Thus, in the end, the plugin itself must be run in a separate 64bit process and communicate with fb2k through a 32bit `wrapper plugin`, but this `wrapper plugin` must not contain any 64bit pointers...
So it seems that this hack could be used only for off-loading tasks that require large memory (calculations, large file manipulations and etc), but it can't be used for the usual fb2k stuff because of the need to `downgrade` pointers to 32bit every-time fb2k API is called.
PS: That is, if I understood correctly how this `hack` works.
PS: That is, if I understood correctly how this `hack` works.
Obviously not. Please reread my description.
The foobar plugin, let's call it FP, is a 32-bit process that runs in its own 32-bit universe. Like wise, the companion process, let's call it CP, is a 64-bit process that runs in its own 64-bit universe. File Mapping allows FP and CP to each access the same block of real memory as if it was their own. The shared memory appears in FP as part of its 32-bit address space that can be read and written. Like wise, the shared memory appears in CP as part of its 64-bit address space that can be read and written. But here's the cool part. Anything FP writes in the shared space 'instantly' appears in the CPs shared space, and vice versa. There are no address pointers. There is no 32-bit wrapper.
I call File Mapping a hack because it is. It exploits features of the OS, in this case, virtual memory and the file system, in clever ways to create something unique.
Note that 64-bit companion processes have already been in use for a long time:
Converter with 64-bit encoders
foo_input_exe with 64-bit decoders
foo_input_ffmpeg with 64-bit FFmpeg
foo_out_asio has 32-bit & 64-bit driver host processes, some ASIO drivers only come in 64-bit flavour
foo_out_wasapi also has 32-bit & 64-bit worker processes because there were bugs with using WASAPI from 32-bit code
All of them used pipes to communicate rather than shared memory though.
I dislike pipes because they usually entail more data copying. Typically, each byte is touched entering and leaving the pipe.
Not totally related, but a good workaround on some 32bits programs is to use 4gb_patch.exe which will allow 32bit EXEs to use 4Gb instead of 2Gb under 64 bit windows. It makes a BIG difference on some programs as ICEECC.exe or VirtualDub.exe for using 32bit only plugins.
foobar2000 is already Large Address Aware, as far as I know.
foobar2000 is already Large Address Aware, as far as I know.
Large Address Aware 2.0.4 confirms that:
(https://i.imgur.com/Yo8HJy3.png)