I'm scratching my head after this article, not really sure if the author really believes in what he's complaining on fully? For me, those are kinda nice "wishes", in that if they happened, the porting team would have less work to do now, sure. But, actually, especially those specific things listed - they sound to me like things, which would be unnecessarily hard and
really costly things to do "in the past", assuming they were initially aiming just for Windows (and maybe OSX, don't know it well). So, like, I feel like doing them that way originally was actually a
very good decision. I'm even starting to think: if the author has
just those things to complain about, then maybe actually the codebase should be described as written fairly portably and future-proof...
To explain my argument, I'll try to elaborate a bit more on the points raised by the author:
1. Case sensitivity in paths.
So, as others mentioned too: on a case insensitive filesystem like Windows, you'd have no chance to verify (i.e. test) "case-sensitive-correctness" anyway. So, you'd fail on this here and there anyway. Ok, maybe using the OSX FS with case-sensitive option would be a guard. But, OTOH, I believe OSX has it case-insensitive by default anyway, no? So, by testing in case-sensitive, you're actually testing the "least used path", which sounds not so smart, actually... especially given that switching from case-sensitive to case-insenstive (i.e. the other way) has its own surprises, then...
2. No OS #ifdefs
Um;... so... like... what else to use instead?...
3. "Assumptions":
3.1. Compilers.
This point seems actually to be more "no C++11". OK; yeah; sure; but remember: then you'll get maimed for being backwards, "corporate-ish", you'll get no "smart young hackers", people will get more frustrated...
Not that you'd really have a good alternative to C++ (Java/Python need huge and messy runtime env; and if you need performance of C++, you need performance of C++; if you started now, you could maybe at least try using Go as a kinda compromise, but depends on your actual needs).
You know, whichever way you choose, you have pros and cons. And, supposedly, some time ago when the decision was made, the pros were actually outweighing the cons; so, it wouldn't sound so smart to me to choose otherwise...
3.2. & 3.3. "Assumptions about [GUI]"
Sorry to say, but: GUIs are just not portable. Every GUI environment has different "idioms", "interface guidelines", etc. Windows has different. OSX has different. Linux has different. Heck, different versions of the OSes have them different! On Linux, even in the same "OS version" (um, distro? kernel?) you have multiple "desktop environments" with different widgets, layouts, etc (KDE, Gnome, ...). Conversely, on Windows, Microsoft likes to sometimes pull you in multiple directions at the same time too, e.g. when new MS Office introduces new widgets, or new Explorer does the same, or you have Metro+classic, or whatever. Dunno about OSX; I dare suppose it's not all roses there either.
I seem to believe now, that if you want to have a cross-platform app with a GUI, you should really write the GUI for each platform from scratch (only trying to reuse some parts). Or, consciously break with staying consistent with any OS interface guidelines.
As to "copy & paste": on Linux it has actually totally different underlying mechanism(s) than on Windows. So, you probably have to rewrite even low level parts of it very differently. Not just menu entries.
So - I don't really see what's there to complain on. The app was written for some 2 OSes; now guys port it to a third one; awesome! just, sorry, you know, there's gonna be some work needed in order to complete that.