Isn't the answer obvious? How many MFC devs are there working primarily in OSX or linux? It has to be tiny, even if they had the ability to do so. Great, I can compile; still need to boot up Windows to run it. My userbase is still 100% windows users. We still use Windows on every PC in my company. So who cares? What's the value proposition here?

None, because you can't, the same reason you don't see many iOS developers using windows. I don't know if there are many people that want to work that way or if it's worth supporting, but your current argument is circular reasoning at it's finest.

C'mon, how is this not completely obvious...

...

What, Fedora?

What's the point, you can't debug or even run such an executable? What developer is just going to compile stuff without testing it? It makes no sense to want this.

I can and I do. Don't be so unimaginative.

For starters, Wine actually works really well. And beside that, time spent writing code is measurable in weeks while time spent running an executable to test or debug is measurable in minutes. The amount of time spent testing and debugging is a tiny fraction of the time spent coding. RDP/VNCing for one of them every second of the day can be a huge pain in the ass. Doing it for the other once in a while is a minor inconvenience.

Next time just say "I'm glad I don't have that problem" instead of "You can't possibly". A mindset like that ends up making you look foolish, because you'll be wrong most of the time.

That said, we also have to be able to encourage others to present their ideas. We clearly can't grow if we don't hear and consider external ideas. It's a difficult balance to strike.

Maintaining two separate development environments, on two operating systems that you have to boot into separately is very annoying. Developing for an operating system other than the one you're running is about as old as the personal computer, I think :).

If time and cost was no option, sure I'd agree with you. Put everything on everything. But this is such a niche situation that's not worth the cost.

This is a niche situation only because Microsoft's tools make it a niche situation. It's pretty much how all embedded software on this planet is developed (except that the network is replaced by a serial connection on the lower end of the performance spectrum, of course). In nix world, it's a super-common situation; e.g. at $work, where I write software for networking equipment, no one seriously expects that I'm going to compile stuff on the routers that ends up running that software. Most of them are capable of the required heavy lifting (they have CPUs in the same performance class as a pretty beefy desktop), but why?

The question is backwards. The real question is, why doesn't Microsoft do what is necessary to bridge them. And the answer seems to be simple -- developer man-hours are limited, your use case is not the use case of the majority of people who want a Microsoft development environment on a Mac, they are handling the most common use case, not the edge case.

I don't think so. Win32 with MFC is already in the free VS Community Edition on Windows, so we know that the work to package up those libraries is already done. We also know that Clang and GCC can already cross-compile targeting Windows, all you need are the aforementioned platform libraries.

I guess I don't understand what sort of developer workflow you can have building windows apps and not actually running windows, even if it's just in a vm.

How are you going to test your program?

I never believed in cross compilation without testing.