Windows support

[rzumer]

This issue is for enhancement tracking/feature request. Since portability is a goal stated here and there does not seem to be an issue tracking this, I thought I would create one. If it is no longer a goal then feel free to close it, but I think that it would be useful even if low priority, and I might start some work on this if I can find the time.

Since the non-Mac Unix builds run on SDL it should not be too much trouble to port most of the application. That said I have not yet looked at the code base, so if there is anything to keep in mind, or any observations, warnings, information regarding portability to Windows, comments would be helpful.

[TomHarte]

It should still be entirely portable; if anything it's more portable than ever since the releases of this month as even OpenGL is now something that both platforms opt into rather than an assumption.

My recent work in this area has been merely to install Windows 10 in a virtual machine and start reading about C++/WinRT. I also had a look around ANGLE as a potential avenue for reusing much of the existing OpenGL code, though it's ES 3 rather than desktop OpenGL so I had the feeling that getting to Windows via either Android or a private iOS build might be intelligent.

In other words: I've read a bunch of things, failed to come to a conclusion, and not done any work (!)

I think I will immediately write a Wiki entry on how to port. The good news is: it should still be really easy. There's a single point of entry for obtaining 'a machine', then you need to register with it destinations for audio and video (and, optionally, 'activity', which means status LEDs in practice — drive activity, caps locks, etc), then push keyboard and joystick activity to it, and tell it how much time to run for.

There's some reflection on machine settings, though I could do a better job there.

Anyway, I'll write it up properly — concrete classes, etc — and reply again.

[TomHarte]

There's an inital draft of that documentation at https://github.com/TomHarte/CLK/wiki/Porting-Guide ; I'm sure I'll realise I've left a bunch of things out at some point, so watch for revisions.

[ghost]

when do you think we will see windows binaries in releases

[rayman3003]

We want Windows version? Come on.

[TomHarte]

Alright, fair enough. Upcoming development schedule: (i) complete Qt port (as it's virtually done now); (ii) write Metal backend, so that the macOS port doesn't cease to exist upon Apple's switch away from Intel; (iii) use everything I just learnt in adding a new UI and adding a new backend to do at least the former and hopefully also the latter for DirectX. Though possibly in two steps — an initial OpenGL port would be better than nothing.

The only blow to my original planning is that Windows 10 is essentially unusable on my machine (possibly only given that I'm sticking with virtualisation), so I've switched down to Windows 7 and therefore C++/WinRT won't be an option. I think Win32 is now un-deprecated, so I guess I can fall back on that at least for now. The stuff of UI controls is actually pretty small compared to making sure everything else works correctly so I don't think that's necessarily a terrible thing.

[rayman3003]

adding a new UI

If u need a good GUI, u can check this:

https://github.com/ocornut/imgui

And thank u.

[stuaxo]

3D in virtual machines is often a bit lacking. I think vmware and virtualbox have varying levels of older 3D support. Qemu + kvm is also an option.

You may have some mileage in running the binaries in Wine.

If you develop on a machine with two graphics cards (many laptops have something like intel graphics + nvidia), then it's possible to make one of those exclusive to the VM, and get round many of the problems that way, but I believe it's a little tricky to setup.

[TomHarte]

Yeah, I also primarily test the Linux version in a virtual machine and under VMWare Fusion 10 my use of OpenGL would crash the entire virtual machine every time. That specific issue was fixed in Fusion 11 but of course I can't speak as to what may be lurking if trying to use OpenGL or DirectX from Windows 7.

Given Apple's new roadmap, a virtual machine isn't sustainable in the long term anyway so I guess I'll look into the current state of mini PCs. My 2015 1.1Ghz Core M runs the emulator mostly acceptably (i.e. debug builds can be a bit of a dirge, but it's manageable) so even a modern-ish Celeron would probably do — from the little research I've already done, the 2017 Celeron Js appear to outperform my existing Core M in the important ways (i.e. multicore and GPU), and I don't imagine there's a big performance differential between Windows 10 and macOS.