Add support for macOS.

[13xforever]

That's neat, but I have some reservations:

1. I do not have access to Mac or even macOS VM, this is the main reason mac build isn't a thing yet
2. I take issues with using external utilities and parsing text output from them. For one, I have no idea if different locales will change the output and if you need to set something like LC_LANG similar to Linux. And considering you're already not using the output as is, why not simply enumerate /dev/rdisk devices?
3. Some partial code is specific for Linux, and it depends on build configurations, so idk if renaming Linux build to Unix is warranted instead of having a new separate configuration for macOS
4. There's no support for any sort of event system to detect disc mount/unmount (for accidental ejects etc), and current implementation will shit the bed if you accidentally hit the eject button during dump, which is not ideal
5. I have zero experience with macOS security model and executable distribution in modern systems, and if it will run as is or if it requires system changes/signing to work properly on vanilla unmodified installation

[13xforever]

1. Yes, proc is a kernel device/filesystem, so the interface is guaranteed to be stable and non-localizable (i.e. specifically for machine consumption). I still don't understand why you can't simply enumerate the drives, ps3 discs will have specific files in root and specific filesystems, so it doesn't matter that you can check other disk devices as well.

4. Yes, Windows has several mechanisms (window messages / wmi), Linux right now is kinda a crutch, but I plan to do proper dbus events at some point

[13xforever]

I pushed some changes:

• use LibraryImport instead of old DllImport in MacOS utils
• clean up the usage of SupportedOSPlatform attributes (lowercase official RIDs)
• reuse StringBuilder in Dumper
• revert and update csproj changes to define platform-specific constants to make Rider happy (Linux build is still semi-broken)
• reverted changes in MainViewModel, these changes do not concern this PR
• change MainWindow.xaml binding for client decorations (Linux doesn't use them as well)
• fixed CoreFoundation namespace conflict (new .net8 defines)
• removed custom delegate and local variable declarations for event handlers (needs testing just to be sure)
• moved macos build in a separate publish script as it requires macos and xcode tools (there's no cross-compilation support similar to linux on windows)
• remove mac-x64 build configuration, as rpcs3 is only officially supporting m1+ anyway, and for intel macs it's recommended to dual-boot to windows or linux

please test that it builds and runs correctly

[13xforever]

Can you pull and test again with these changes?

Normally you target -macos as far as I understand, but Avalonia does its own packaging, so it's kinda try and see what does and doesn't work. They also have this doc page for macOS deployments specifically: https://docs.avaloniaui.net/docs/deployment/macOS (though it's still describing build process for .net 6 and there's been a lot of changes in 7/8).

[13xforever]

And another commit that may or may not work, that's using native function pointers for interop callbacks

[13xforever]

Sweet. Can you test one more commit? I'd prefer not to use StringBuilder in interop if we can.

[13xforever]

Yeah, idk why I thought '\0' may be required, but I also fixed the index check as it returns -1 if nothing was found

[13xforever]

Let me tinker with publish scripts so I can build on windows and I think it'll be good to go

[13xforever]

I'll see what I can do with github actions to automate release publishing Here's the result from local windows build that probably won't work: https://1drv.ms/u/s!AruI8iDXabVJgaA1577Lm3J3njqxOQ?e=gxjLaK

[13xforever]

Thank you for sticking with this pr, I'll see about setting up github actions asap (probably next weekend)

[13xforever]

Nah, I need some specific workflow and I have some experience with gh actions