Cross platform fixes for WinUAE

[emoon]

Hi,

Lots of the code in WinUAE is cross-platform today, but there are some cases here and there where the general code doesn't compile. This is excluding the Windows specific code of course.

I wonder if you would be open for PRs fixing these? These fixes will be made as least intrusive as possible and in many case they are straightforward, but some of them may require a bit more talking.

The plan would be to start with the easiest fixes first and then potentially have some more discussion about the more involved ones if they make sense or not.

How does that sound?

[midwan]

I can probably help with this as well, since Amiberry has those pieces of code altered already, in order to compile for Linux and macOS natively.

[tonioni]

Yes but it depends. Anything under pcem-directory won't be accepted. And no "gcc-isms" either.

[johnnovak]

Would be nice to make the UI and core emulator layers modular too. Then ordinary mortals such as myself could take a stab at writing some other alternative frontends for Linux/macOS without going near the core stuff 😅

But then you'd need some abstract interface for all the audio, input handling, and shader stuff for that.

[luvwagn]

Did the Linux version fork? UAE used to be quite portable, and the Win parts were somewhat layered.

…

________________________________ From: John Novak ***@***.***> Sent: Saturday, February 3, 2024 5:04 PM To: tonioni/WinUAE ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [tonioni/WinUAE] Cross platform fixes for WinUAE (Issue #285) Would be nice to make the UI and core emulator layers modular. Then ordinary mortal as myself could take a stab at writing some other alternative frontends for Linux/macOS without going near the core stuff 😅 — Reply to this email directly, view it on GitHub<#285 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AP2ELBTZ3MCLLLZUGBIKOM3YR3NCDAVCNFSM6AAAAABCDZ67IGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRVGUYDONRVGE>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[rofl0r]

there is no "the" linux version, at least not anymore. UAE itself is dead since decades. all that's left is a couple forks that try (or tried) to keep pace with WinUAE. PUAE tried to stay in C while still backporting WinUAE changes, until so much C++ crept in that it became inpractical so it's stuck somewhere around 2.8 level. FS-UAE went the path of shiny 3d gui, and afaik hasnt been updated to latest WinUAE for quite some time too. the best option currently is probably the amiberry version, even though it also lacks a lot of WinUAE's features.

[emoon]

Would be nice to make the UI and core emulator layers modular too. Then ordinary mortal such as myself could take a stab at writing some other alternative frontends for Linux/macOS without going near the core stuff 😅
But then you'd need some abstract interface for all the audio, input handling, and shader stuff for that.

It is actually fairly modular, but there in no such thing as an interface. Most platform specific code for WinUAE is in od-win32 and if you remove that then you are left with the functions you need to implement. Would a proper interface for this be easier and more clear to implement? For sure, but I'm not sure it's worth it.

Did the Linux version fork? UAE used to be quite portable, and the Win parts were somewhat layered.

This is mostly the case of the WinUAE code, but there are some instances when the general code doesn't compile on non-msvc anymore and these are the parts I plan to do PRs for at some point.

[johnnovak]

Most platform specific code for WinUAE is in od-win32 and if you remove that then you are left with the functions you need to implement.

Yeah, that sounds like all we need then. I should have said "proper separation" instead; I don't actually care if there's technically a literal interface there or not ;)