Digging around the announcement a bit, I'm having a hard time seeing why I might prefer this over Conan[1], and I'm not seeing anything about how I can stand up my own private repository for vcpkg, which is what I am about to do with Conan. Can anyone sound off (or link a page where someone has done so) on what might tip someone toward this over Conan or vice versa?

Thanks. It looks like at least the third bullet has been reconsidered, based on this announcement.

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.

We've been using vcpkg on Windows and it's really made the process of managing c++ dependencies far less painful. Great to see this coming cross-platform as we can now simplify the dependency section of our install guide to one line.

vcpkg install boost cgal [etc...]

Their team has also been super friendly and responsive on Github. Looking forward to seeing where this goes.

> At Microsoft, the core of our vision is “Any Developer, Any App, Any Platform”

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.

DevDiv stil operates as its own business - and the profit margins for licenses for Visual Studio (and Azure subscriptions) is higher than Windows. The bulk of Microsoft’s Windows license fees come from OEMs anyway.

Also, don't forget that DevDiv is the oldest Microsoft, maybe the truest Microsoft. Microsoft's first products were all programming languages/environments. If Microsoft's DevDiv should outlast Windows, that may be poetic.

I like the tool, really. I don't know why they didn't choose to support Conan, but I guess they had a good reason to create their own tool from scratch.

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.

The fact that they make money on Azure made them do some Linux(kernel)-related work. It made them join Linux International. But it's because they had no choice, not because they wanted to or suddenly stopped believing in vendor lock-in.

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.

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.

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

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?

> MS can't (at least) throw their weight behind that, rather than wasting time on WSL?

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.

That's interesting.
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.

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.

Except that it shouldn't be related to Windows 10 at all. MS did the same with DirectX10, forcing people to change their systems to Vista (for some reason they call it an "upgrade"). Eventually it turned out DirectX 10 actually can be run on Windows XP and it was just a ruse on the part of Microsoft to make people buy Vista.

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.

Yet another package manager for Linux/MacOs to put yet more duplicates of already packaged software on our disks. As a solution for Windows, vcpkg fills a gap (I use it myself). For other platforms, this just adds more waste.

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?