That would be amazing.
Using XCode is very frustrating.
I don't understand how Apple can actually write their software using XCode.
No support for bookmarks.
Very bad find/replace usability.
Scrolling text is painful even on my brand new top of the range MBP.
Sometimes I have to switch to Sublime for some editing tasks that are too painful in XCode.
I've started using AppCode for actually writing code and just using XCode for the interface builder. Trying to transition from IntelliJ to XCode was very painful.
The thought of porting a decades old, 50 million line code base from windows to Unix, one that was deemed too complex to retrofit 64 bit support, makes me put my own insignificant development hassles of the past few days in perspective.
No matter how bad it seems, at least I'm not on that team.
I worked with an ex-Microsoftie who was responsible for getting Excel onto the Mac, in the 1990s. He quit and swore off computers for a couple of years, and we had to convince him that (a) we were a great company and he should definitely interview with us, and (b) we weren't going to treat him the way Microsoft had.
He was pretty good, but there were parts of his psyche that seemed . . . damaged.
True: hiring non-programmers from top schools and then giving them tasks like "fake out multifinder enough that WinHelp runs" is a unique form of cruelty. But most work in the 1990s was like that. He should be glad he landed at Microsoft instead of Commodore or 3DO or half a dozen other places.
"Welcome to hell. Here's your 15 year old MSC code base to port to OS X."
You couldn't pay me enough... not because I wouldn't want a fat salary, but because I literally do not think I could actually bring myself to do it. It would require drugs.
You could still take the fat salary until they found out it's not working (because, of course, it cannot possibly work). If they decided the code base is too crufty (instead of deeming you incompetent) you could still keep the fat salary and land in another realm of the company. Unfortunately for you, the odds of them deciding the codebase is too crufty (and, therefore, that the very senior exec sitting on it managed its aging poorly) are not good.
I don't see why people complain so much about Xcode. I haven't used VS for a few years now, but I have bad memories of it. Xcode is in my opinion excellent compared to Visual Studio (especially for C/C++ work).
There are so many things Xcode does worse than Visual Studio, and so few things it does better. 5:1 ratio. Yesterday I was dealing with how Xcode's disassembly mode debugging is so bad compared to VS that it's nearly unusable.
Visual Studio is way more than what one sees at the first look. Huge part (and value) of it is the probably unparalleled debugging/profiling capabilities. That are very much Windows specific, porting them to OSX/Linux means writing a lot of new code, not just taking the old stuff and adapting it.
Their first steps I would think would be allowing support for other compilers in Windows like GCC and Clang maybe? But again all this is every programmers pipe dream for now...
GCC is pretty much written such that non-GPLed code cannot interact with it. You could use it as a compiler, I guess, but Intellisense and such wouldn't work with GCC.
Specifically, in 2015 our C99 Standard Library implementation is complete, except for tgmath.h (irrelevant in C++) and the CX_LIMITED_RANGE/FP_CONTRACT pragma macros.
When I was 16 years old I would get into the nuwen IRC where I learned and really started my whole programming education / career through STL. I still remember the std::vector explanation that included cats in buckets. Prior to him I only opened VB's IDE and...that was it. He had me writing algorithms in C++.
Too bad I'm so rusty in C++ nowadays; need to get back on it. I like using the nuwen MinGW distro when I worked on Windows; made picking up boost and SDL really simple.
(Just figured I'd share since you mentioned him; he probably doesn't remember me at all but without him I don't know if I would have ever become a developer. In fact at the time I was thinking about becoming a doctor but was a lazy high schooler who dreaded the years of education required)
Back when I first had the shock of discovering that VS only supported C89 I remember poking around to figure out why and finding a rant from a higher-up on the compiler team along the lines of "C is a dead language, just use C++." What happened? Did he leave? Did an order come down from on high? Did he mellow with age?
Our current statement of support is that we support enough of C99 to unblock commonly used libraries. We support a large swath of C99 but it is correct that our support isn't complete yet as we prioritized C++ conformance. If there is a C99 library that you need to use that we don't work with, please let me know.
(I'm the VC++ dev manager)
It seems that MSVC really has improved its support for C99, though, and I'm glad about that. What about C11? Does it support _Atomic/stdatomic.h? I can't tell from Googling, and I'm too tired to install the CTP tonight... If it does, it'd be ahead of OS X, hopefully not for long. The C11/C++11 memory model is powerful, way nicer to use than volatile plus OS-specific library functions, and, compared to other features, it's difficult to properly implement as a shim. It's too bad that only C++ can take advantage of it on some platforms.
Existing libraries are one thing, but when writing new code (and yes, I want to write new code in C), one of the big three compilers not supporting a feature is strong motivation not to use it... even if it would be really nice to have. Maybe in the coming years Clang will improve its Windows support enough that I can just tell everyone to swap it in for cl.exe, so I won't have to care about MSVC's standards support, but for now it and GCC are missing a lot of features on Windows.
The C11 Standard Library has not been incorporated into any C++ Standard (not even the C++17 Working Paper as of right now), so we have not attempted to support it. On the other hand, our C++11 <atomic> implementation has been significantly improved in VC 2015.
I believe the choice was to spend time on adding C99 support, vs spending more time on C++ support. C++ had more people asking for it, so it got priority over C99.
I suspect it's in the works. I don't know how reliant it is on Win32 APIs (probably awfully reliant), but some work to isolate those calls and attempt to bring POSIX into the fold could certainly be possible. I guess it's really a matter of getting developers on Mac to buy into using Visual Studio, which could be a challenge.
Dont, please dont. Save people resource to focus on visual studio windows. Maybe the better solution is use different approach, send minor team to assist xamarin fixing xamarin studio fixbug
If it works good, this might do wonders for Microsoft's Windows phone app store. They are surely hoping people will be willing to build and upload the apps on their platform as well once they're written in an almost platform independent manner.
As I already mentioned in Reddit, this is great for those of us that enjoy using Visual Studio.
If I would be part of the Android team I would feel bad to have Microsoft providing a better developer experience than the team is able (willing) to deliver to NDK users.
When comes to ease of debugging Visual Studio is outstanding. Not the most powerful debugger in the world (WinDBG is much more advanced), but it's my experience is that it's easy to work with even for new people.
In my mind, these two just occupy a very different niche. WinDBG is great when you don't necessarily have the source or symbols at hand, where VS excels with that information available.
That to be said, when comes to OSX/Linux I had to deal less with debugging (more with logging), but QtCreator's debugging while missing features, saved the day for me while in C++ land, and NetBeans quickly got me to solve java issues (java is something I'm learning/using right now so I'm not entirely versed in what's good in there, but trying out Eclipse several times to debug didn't do it for me - maybe I was too impaitient... where is the damn "Attach to Something" and do it kind of thing...)
I'm quite suspect on how is 'cross-platform' feat is achieved. Non-UI code shares well. As for the other: "Windows, iOS, and Android app development" ... "Free Microsoft extensions available for download for iOS and Android development" may not as positive as it's spun to be.
You are confusing Android with desktop Linux, very different beasts. Just try to open/create a graphical window on a typical Linux distro, after that try to create a simple app on Android and you will understand.
And very different UIs. If by desktop Linux you meant text based programs (no GUIs) than I think, at least technically, it should be possible to use a cross compiler toolchain (based on Clang) from VS 2015.
I think the question isn't so much "Can I make VSC++ Android apps run on Linux" so much as "Can I futz around with linker flags, and get a desktop binary if I point it to the right runtime, start files, and so on?"
Does anyone else find the use of "acquisition" a little weird here? I don't think anyone ever talks how "easy this software is to acquire" when they talk about features.
You don't need to use an IDE (like Xcode) on OS X in order to compile standard C++, a Makefile will do just fine. They've probably developed the C++ code on Windows with Visual Studio and tested on Windows and OS X.
For the GUI part it depends, technically you don't need an IDE to create GUIs on OS X. However, most people use Interface Builder from Xcode for this.
There is a difference between niche things like that, and being the most installed full desktop os in the world. I repeatedly run into C++ projects saying no C++11 because of windows, and only windows.
Because C++ is faster and can be compiled to machine code and, at least for now, you will need a 3rd party solution like Xamarin in order to compile and run C# on other platforms.
So it looks like this targets Windows and Android only (maybe iOS via Xamarin...?)
For an alternative the Poco C++ libraries[1] work on Android, iOS and Windows out of the box. Probably not as full featured and you obviously can't use existing Visual C++ code..., but its Open Source and mostly just works.
Meh, you know what - this is a bold move of Microsoft, and its quite compelling to see how they have embraced the platform-ology that must be embraced in mobile, these days. I applaud the effort.
But the tricky part of all of this is that so much of the mobile space is more common than people think. Glomming one platform on the other is sort of de-rigeur, in mobile - as it has (and still is and always will be) been on desktop, in the server space, and so on. Tricky thing: you can Run X on A if you use Y and A to make/build/run X. Got Y?
Microsoft: please port Visual Studio to all platforms, including my iPad, kthxbai..
