Re: Logic & Gui
No, its the fact that you have built your code to assume a specific API, like win32, and a specific model for GUI, maybe even worse with assumptions of the size of 'int' or similar instead of using int32_t or whatever options were supported. That makes even a small program an absolute PITA to port. That is what most legacy software is like.
The exceptions are stuff that was written to be multi-platform, even if just two variants of "UNIX" (say Linux and later MacOS) as then you have to write your code with some degree of abstraction for GUI and low-level stuff, and that greatly mitigates the pain for porting because you are probably started using two compilers/dev environments and can never be quite sure of what API consistency will be like, so you learn to segregate from the beginning.
MS have needlessly and artificially made it difficult for themselves. Windows always has been multi-platform (back in the early days there were PowerPC and Alpha versions of Windows - all quite trivially easy really). A few years ago MS pulled the same trick with ARM. They wrote the required Hardware Abstraction Layer, recompiled Win7 and Office2007 for ARM along with an Epson printer driver, and showed the whole lot working satisfactorily at some conference.
To a lot of us this looked like a good idea. It made sense, it built nicely on what went before, there were no big problems to solve. Visual Studio could easily have been made to automatically build fat binaries for x86 and ARM (just like Xcode on OS X used to for PowerPC and x86), and the distinction between an x86 and ARM based machine could have been made irrelevant.
The only thing was that ARMs at the time were only 32 bit and not that fast, nothing that a bit of Moore's law wouldn't solve (which has since happened). An ARM PC? Why not, it'd be smaller, quieter, cheaper, etc... Even back then one could see there being an ARM server running Windows.
But no way was it anywhere near ready for a universal mobile desktop / mobile app. With ARMs as they were, desktop was going to have to remain desktop, mobile was going to have to remain mobile. There simply wasn't enough compute power in ARMs to support a full desktop. MS tried too soon to unify them, but the result was the hideous mess that was WinRT, Windows8, etc.
They probably tried to do it simply to be different to Apple. Whilst the allure of a universal app is strong, Apple had seen quite clearly the advantage of building a completely new ecosystem for mobile (iOS). This advantage was that at that time it would work, and that really devs would cope quite readily with the idea that there was no way that OS X apps would run on iOS and vice versa.
Now the idea of a fat binary application is realistically achievable (at least from a hardware point of view). Many mobiles now have more compute resources than the PCs that were around when Windows 7 first came out. I like the idea of a mobile that can be plugged in to a monitor, keyboard and mouse and becomes a full PC. If only a fraction of the apps work in mobile mode that'd be fine; I'd only want a browser, messaging client and a few specific apps (trains, etc) to work when in mobile mode. If MS put full fat Windows on ARM like they did all those years ago and have visual studio build fat binaries, that'd solve their upcoming server problem, supply software for an mobile ARM desktop, etc.