4 ms·
It's also a problem with Windows itself. It really is a nasty environment for coding non-MS-based software on. If I want to support Windows I have to setup a (
by mpk 18y ago
It's also a problem with Windows itself. It really is a nasty environment for coding non-MS-based software on.
If I want to support Windows I have to setup a (virtual) machine with a license code just to have any basic functionality. As someone who doesn't work with Windows anywhere, this is a huge hurdle. Then there's the hoops I'd have to jump through just to get a decent shell and a compiler ready.
Oh, but the fun doesn't end there. Which version of Windows are we talking about? More than one? Ah, well, each of these will require its own machine (virtual or otherwise). With matching keys, of course.
Supporting Windows is a pain and when it's not required for what I want to do, I'm simply not going to do it. Period. I have better things to do with my time.
Letting people who want this code running on Windows do it themselves and having them submit patches upstream is a perfectly valid choice.
- Maascamp 18y agoWhat if I'm an anything else coder and I want to support Mac? Forget license, I need to buy a new machine. Linux is the only really painless platform to support if you're not using it.
- Niten 18y agoBut if you support any sort of *nix, then you quite possibly work on OS X already. If not, there's still probably minimal work to do. It's not like going from Unix to Windows, where you have an entirely different access control mechanism, system API, filesystem structure and path separator, etc.; it's just going from one Unix to another. So the author only has to accept a couple patches from his Mac-using colleagues, and then he's basically set for OS X. On the other hand, debugging a Unix app on Windows can become a full-time job, and may be more work than you can reasonably expect a few random patch contributors to accomplish.