tonioni / WinUAE

WinUAE Amiga emulator
http://www.winuae.net/
552 stars 90 forks source link

Cross platform fixes for WinUAE #285

Open emoon opened 10 months ago

emoon commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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

johnnovak commented 9 months ago

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.

luvwagn commented 9 months ago

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 GitHubhttps://github.com/tonioni/WinUAE/issues/285#issuecomment-1925507651, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AP2ELBTZ3MCLLLZUGBIKOM3YR3NCDAVCNFSM6AAAAABCDZ67IGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRVGUYDONRVGE. You are receiving this because you are subscribed to this thread.Message ID: @.***>

rofl0r commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 ;)