Personally, I prefer their integration with CMake, letting me `find_package(spdlog 0.16 REQUIRED)` allowing others to point to their own version with `-Dspdlog_DIR=...`.
But I think the front matter on that section gives (at least for what I'm after) a pretty good start on an answer to my question. They aim to version all libraries together as a platform (like, say, homebrew or yum+rpm). Where Conan aims to behave a little more like what I'd term "pypi for C++". That is, if I'm reading this correctly, and I'm not yet certain that I am.
One thing that I want to do, and it's clear to me how I'd do it with conan (or pip) but not yet clear to me how I'd do it with vcpkg, is have a version of a package that's available in a public repository also be available in my internal repository with some added private patches, and have my version "win" for my projects.
Our recurring need for this is when we're building out patches that we want to have incorporated upstream but aren't ready to do that yet for one of many reasons.
I don't like package managers that force me to install a programming language just to use them.
vcpkg install boost cgal [etc...]
Their team has also been super friendly and responsive on Github. Looking forward to seeing where this goes.
ChromeOS, Android, Android Things.
This is what you want us to believe. But this makes little sense: if you really believed in "any platform", this would go against your the interest of the company (Windows sales), and therefore also against the interest of shareholders. I liked you more when you didn't pretend.
On the other hand, I've lived long enough to see the same tricks played my MS and not to trust them with anything. This "any platform" seems particularly double-faced when Linux is almost 30 years old but you still have to install it after Windows in multiple-system setup because Windows doesn't believe any other system could exist.
C++17 is powerful and user friendly enough for writing such a tool.
This would've been an insightful comment in 2007, but the world has changed. Microsoft makes its money on Azure now, and that means supporting developers everywhere.
For crying out loud, post-reorg Windows doesn't even have someone reporting directly to the CEO anymore.
If they want to be competitive, they have to offer easy migration options from other cloud providers (Azure Migrate). What is everyone else running? Linux. So Microsoft has to do it, too. What determines popularity? To a large extent, winning the hearts and minds of developers. MS always understood this. As developers changed, MS needed to change the way they talk to them, that's it.
If that was true then Microsoft wouldn't be pushing DirectX 12.
I’d love them to be, but unfortunately there’re technical reasons for that. Both depend on too many Windows components. WinForms is really a thin wrapper around Win32 windows and GDI+. WPF relies heavily on DirectX 9.
For mobile platforms, Microsoft offers Xamarin for GUI.
> Microsoft wouldn't be pushing DirectX 12.
Again, there’re technical reasons. For the same reasons Apple is pushing Metal, and Khronos is pushing Vulkan, all 3 are conceptually quite similar.
And yet somehow Mono is able to (mostly) emulate WinForms, while Wine can (mostly) emulate D3D9. And MS can't (at least) throw their weight behind that, rather than wasting time on WSL?
> Again, there’re technical reasons. For the same reasons Apple is pushing Metal, and Khronos is pushing Vulkan, all 3 are conceptually quite similar.
So why aren't Microsoft (and Apple) pushing Vulkan as well, rather than their own "quite similar" APIs?
I don’t know the answer to that, I’m unrelated to MS, not even on the same continent. But I have an idea why. Because outside Android, Linux GPU stack is a mess. Maybe Vulkan will fix it, but it’s not happened yet. I’m just not sure it’s possible to build a good product on top of that.
But they sure can build a single cross-platform GUI library for Windows, OSX, and mobile platforms. And I hope they will.
> why aren't Microsoft (and Apple) pushing Vulkan as well, rather than their own "quite similar" APIs?
Apple released Metal in 2014. MS released DX12 in 2015. Vulkan was first announced in 2015, and they released 1.0 version of the spec only in 2016. That’s why.
For one, MS has a long history of using DirectX to force people to buy the next version of Windows. Second, DirectX 12 seems to deliver uneven results when benchmarked against DirectX 11. Some go even as far as say it's just plain worse than the previous version. Nevertheless, MS will do what they can to make people switch to Windows 10, no matter what people really want, and what their personal and business needs are.
Same applies to Vulkan.
And that’s understandable.
If you’ll just port a DirectX 11 game engine to 12 (or an OpenGL game engine to Vulkan), without drastic redesign of renderer, you’ll unlikely gain huge performance improvement, if any at all, compared to the older technology. The renderer need to be designed quite differently to benefit from these new multithreading focused low overhead GPU APIs, be in VK, DX12 or Metal.
Let’s compare with Vulkan on Linux, I hope we all agree Microsoft has nothing to do about them.
Intel Vulcan drivers for Linux require at least kernel 3.10, released in 2013.
nVidia Vulkan driver requires Linux kernel version 3.13+.
Should Vulkan support be related to Linux kernel version? Probably not, but it still is.
> forcing people to change their systems to Vista
They haven’t forces too many, Vista never surpassed XP (1). And around 2009, average installed RAM amount exceeded 2GB (2), I think more people upgraded the OS because of the 64 bits. I know about XP 64, but the software & driver support just wasn’t there.
Windows 10 upgrade was also free for a couple of years.
> has an iron policy on userland regressions
GPU drivers include a lot of code running in the kernel. And Linux doesn’t give a damn about broken device drivers, especially third-party binary drivers, like GPU ones.
> aren't bundled with malware
Windows kernel is not bundled either. And Linux userland sometimes is, e.g. https://news.ycombinator.com/item?id=4558049
And the first thing it does on Ubuntu 16.04 is to force me to install g++-7 from the toolchain ppa. So now presumably I have to link everything statically (ever tried that with gtk?) or the users of my software will have to install g++-7 too?