Hacker News Reader

Comment by BugsJustFindMe | Hacker News Reader

> Definitely keep the feedback coming

> Our goal with Visual Studio for Mac is to create a native IDE for Mac users...That means "desktop app" development will target macOS.

Feedback: This target ghettoizing mentality seriously hurts my workflow. I just want to cross compile to target Windows. I want to make Win32 MFC C++ executables without having to boot into an operating system (Windows 10) that I never want to use on my development laptop for anything other than running MSVC. It's literally just a set of headers and object files that will, in even the very worst case, produce more applications targeting your platform. Why does Microsoft continue to keep them walled off?

View on HN

>Why does Microsoft continue to keep them walled off

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?

Because it doesn't have to be that way. You're just arguing from the "we've always done it that way" perspective. Years ago, I took the extra time to compile a Qt application so that it would run on Windows and Linux with the same code base. Why not? Why not compile for Windows and Mac, and let people choose what works for them? You may have no use for it, but I do. Is it worth the effort? Depends on the application? Is it worth Microsoft's time to support? Obviously not. But at this point, the ability to compile for multiple platforms at the same time shouldn't have to be rocket science for the situations where it makes sense.

That's not my argument at all, but whatever, look at yours. You initially mention MFC, a Windows only technology, and follow that up with a QT example. Well yes; QT is meant to be cross platform! The MFC example made no sense whatsoever.

> Isn't the answer obvious? How many MFC devs are there working primarily in OSX or linux?

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.

Yet Microsoft supports, and was investing heavily in, iOS development in Visual Studio on Windows...

As long as you have a Mac and an iOS device to connect to.

I know, total PITA. Why can't I run my iOS app on Windows?! Screw you M$!

...

My argument was that it makes absolutely no sense to develop an MFC app on OSX. I asumeyou'll want to, you know, run the thing, right? well get out your Windows VM!

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

I guess one value proposition is the devs that refuse to work for your company because you're 100% Windows might re-consider if both your company and Microsoft opened this up slightly?

But you still can't run any of the code you write on OSX, so what's the point?

This has already been addressed elsewhere in the thread.

Kind of amusing considering the platform you (apparently) prefer. However walled Windows is, Apple is at least as bad, if not worse. At least with Windows development one isn't restricted to a particular brand of computer.

> amusing considering the platform you (apparently) prefer.

What, Fedora?

No, Mac. Since this is, after all, a story about VS on Mac, and you didn't make it clear in your comment, it was an inferrence I made.

Alright, well, since we've veered off on this tangent, I prefer Fedora. Between macOS and Windows, I prefer macOS...though I may never get used to the new capitalization scheme. But I don't see why any of that should be a reason to want to boot multiple operating systems in virtual machines. How do the two subjects relate?

I think the relation is that Apple is even more guilty of the thing you were complaining about Microsoft doing.

Uh, I guess? But where did I say I develop Mac apps? God, do I have to lowercase mac now?

I'm not sure where this is getting confusing. You complained that Microsoft's Mac offering doesn't make Windows apps. It was then observed that this is an ironic complaint because development for Apple platforms is way more locked down.

Allow me to rebut: Someone else being bad isn't a reason to be bad. Ok, so it's a reason, but it's not a great reason. Ok, so maybe it's a great reason, but it's not a good reason. Also that's not what irony means. Ok, so maybe it's what a kind of irony means, but only in a new transgenerational sense where someone else implied to themselves something that I never said. Ah, you know what, that's definitely situational irony.

> I just want to cross compile to target Windows.

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.

sigh

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.

Despite the negative tone, I think you are correct about the mentality that leads us to conclude that we have the simple solution for every problem and that others who can't see those simple solutions are clearly not up to par. Comments of the form, "Why don't you just...", usually end with something that doesn't fit the situation, just the mental model of the poster. Over time, and with enough experience, you learn empathy for other developers. You've seen enough adversity to know that we solve problems in different ways. I don't subscribe to absolute relativism, but we have to allow for the practical, not just the theoretical.

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.

Wine still doesn't support many Win32 APIs or typical Windows deployment scenarios, specially in the enterprise contexts.

I'm glad that I don't have those problems.

You can run it on a remote computer (or a VM) and debug it from an OS X front-end that connects to the remote-running debugger over the network. It's a pretty common technique, gdb has had it for, what, fiftenn? Twenty years?

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 :).

Why not just compile it on the remote computer as well?

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.

The remote computer is often good enough to run an application but way too slow to productively compile a large codebase on it. Besides, you don't need to maintain two development setups at once.

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?

We're not talking about just a compiler here. Nobody says "You should try CL.exe, it's really awesome at compiling!" No, they say "Visual Studio is the best C++ IDE you'll ever use." Which is true, but not because of the compiler. And without all the Windows-specific libraries, intellisense and code analysis tools that are second-to-none can't work.

> Why does Microsoft continue to keep them walled off?

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.

> The question is backwards.

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.

Visual Studio for Mac is based on Xamarin Studio, which is MonoDevelop. You have to port over everything to support C++ projects to Mac before you can use C++ projects in Visual Studio for Mac. The libraries may be packaged up, they may be portable code, but it's nontrivial. The work is >0. You can argue how close to 0 it is, but it's not like they don't have other work to do.

They already plan to support C++. Boom, done. No, I'm kidding here. I have no idea what they're planning to add. This thread started because it actually looked (I commented on this somewhere else) like it would support C++ from the website interface. I do at least have some reason to believe that they have a C++ dev manager named Steve, and that they will add support for more languages over time.

And when will I be able to develop Mac OS X applications on Windows? Probably never. I don't want to boot into another OS or buy a new very expensive computer...

I agree, wouldn't it be nice! Unfortunately delivering Apple's library code might be outside of Microsoft's control.

Sounds like you really hate Microsoft/Windows. Maybe you're not the target market here.

In what universe is people who want to build more Microsoft Windows executables for other users of Microsoft Windows using Microsoft Visual Studio not part of Microsoft's target market? I have an operating system on my computer already. I don't want two.

How will you test those apps? By installing a second OS no doubt. Why not run visual studio inside that, perhaps with vmware or parallels?

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.

Yeah, I totally agree with you.

I'll refer you to my other answer to this same question.

Building in a VM is pretty slow.

I do a ton of Windows dev in a VM. It's not that bad.

> I want to make Win32 MFC C++ executables without having to boot into an operating system (Windows 10)

How are you going to test your program?

This has already been answered elsewhere in the thread.

How do would you test that your application works at all as it should?

I never believed in cross compilation without testing.

This has already been answered elsewhere in the thread.

Because they lose control.

Reply on news.ycombinator.com