Prepare cross compile

[ThijsWithaar]

Note sure how well this fits your plans, let's see:

This PR adapts the code to make it compatible with GCC, with the minimal set of changes to achieve that.
That will allow cross-compiling and also directly building it as WINE dll.
The latter gives the RS-ASIO dll direct access to the linux libraries, which makes interfacing with pipewire, jack or others easier.

[mdias]

According to MS docs, this should be using uintval.
Why did you change it to use ulval?

[ThijsWithaar]

In Wine, tagPROPVARIANT::uintval does not exist. Both uintval and ulval are defined as VT_UI4, where this page only mentions ulval:
https://learn.microsoft.com/en-us/windows/win32/api/propidl/ns-propidl-propvariant
Since it's all the same union, and both are 32-bit unsigned integer, it should be functionally equivalent.

[mdias]

TCHAR is not always a wchar_t*.
depending on _UNICODE (or something similar, can't remember right now) it might also just be a char* which would make the conversion even easier, but I would also rename this whole function to ConvertTcharToStr or something similar.

[ThijsWithaar]

Ah, I missed that. I've moved this to Utils.cpp, and put 2 function overloads there for char* and wchar_t*, so the compiler picks the right one.

[mdias]

This looks very good!
I have no way of testing it ATM but I assume you already did.

I left a couple of comments on some things that I found could be improved but overall looks good.
Not sure if I should merge it right into master branch for now, or a dedicated branch for now, but for sure I won't mind keeping this.

[ThijsWithaar]

This looks very good! I have no way of testing it ATM but I assume you already did.

I have not done proper testing yet, currently I'm struggling with wineasio/jack/pipewire under Wine.
I'll go try to see if can get steam running in a windows-VM and try this out.

As for testing: Under steam/wine, audio-output works, I see nothing weird in the logs, but audio input does not work (with and without the changes in this PR, due to pipewire).

[mdias]

If it works under steam/wine it should be ok. The only thing that could be an issue is the workaround for NtProtectVirtualMemory.
Looking at your changes I see that you added NtProtectVirtualMemory.S but it doesn't look like you're using it anywhere, not sure. But you should know that the syscall is different for wine and native windows, which is why the current workaround reads the code from the actual on-disk DLL.

Just let me know if/when you manage to test it on actual windows and I'll merge it if all ok :)

[ThijsWithaar]

It took a bit to get Rocksmith itself running, but I've tested the PR as it is now:
Both playback and recording works, I can successfully tune the guitar, so notes get detected.
This is tested under linux/steam, with wine-audio routed to pipewire-jack.

I did make some changes:

1. Remove NtProtectVirtualMemory.S since it's not used yet
2. Replace some fread() calls with Readfile. The latter handles windows paths under wine, the former does not. So this is required for a wine-dll to work.
3. Initialized RSBaseDeviceEnum::m_DefaultRenderDevices. I believe this can lead to crashes if not done, since the unitialized data can be Released() in RSBaseDeviceEnum::ClearAll(), which is called by RSAsioDeviceEnum::UpdateAvailableDevices()

[mdias]

Everything looks great, and very nice catch on the uninitialized pointers!
Merged 👍