Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: 64-bit plugins for 32-bit foobar (Read 5446 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

64-bit plugins for 32-bit foobar

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.
Jon Bokelman

Re: 64-bit plugins for 32-bit foobar

Reply #1 –
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.

Re: 64-bit plugins for 32-bit foobar

Reply #2 –
Quote from: TheQwertiest on
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.
Jon Bokelman

Re: 64-bit plugins for 32-bit foobar

Reply #3 –
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.
Microsoft Windows: We can't script here, this is bat country.

Re: 64-bit plugins for 32-bit foobar

Reply #4 –
I dislike pipes because they usually entail more data copying. Typically, each byte is touched entering and leaving the pipe.

Jon Bokelman

Re: 64-bit plugins for 32-bit foobar

Reply #5 –
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.

Re: 64-bit plugins for 32-bit foobar

Reply #6 –
foobar2000 is already Large Address Aware, as far as I know.