Microsoft_craziness.h (2018)

The slight trickiness with this is that if you have any C/C++ libraries that you link into your application, then you need to static link those too. The problem with dynamically linking against a library while statically linking against VS runtime is that you basically end up with two or more copies of the runtime running at once in your application (e.g. two copies of any internal data structures used to manage memory with malloc/free/new/delete).

For similar reasons, you can't have static libraries that are used by higher-level dynamic libraries (e.g. gRPC dynamically linked with protobuf statically linked). In the end, the easiest solution is usually to pick static linking or dynamic linking and use it for everything, although it's possible not to if you're really careful.

Having said that, statically linking everything, including the Visual Studio runtime, works really well and I'd recommend it.

Sorry, but I disagree with you, this is a packaging issue. The average user is not in a position to make a determination of which toolkit is required for which binary. The only entity with that information is the developer. The developer should make sure all dependencies are either in the OS, or shipped along with the binary.

> are asking for them to break it again on VS vNext.

Why?

"Windows 10 it ships with Universal C Runtime", really? Is this a different thing than vc_redist?

Games still require vc_redist.x86.exe or vc_redist.x64.exe to be installed, even on Windows 10. Ancient games also require ancient versions of these to be installed.

I have always found it very strange that these wasnt just included in Windows.

More than once, that is VS still today since the 2010 rewrite.

>Just copy the DLLs along with your app in the same folder

I think the license precludes distributing the DLL's with your application. You are supposed to use the VC Redist package.

> Option #2 is typically the best one and is pretty easy to do

Your app's manifest is more important than you realise and I wonder if the OP is aware of this? Its SxS not SxSW. :-)

http://tinyurl.com/y3q8h3ks

This might be useful as well https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-...

IIRC Windows has been UTF-16 for ages which this link suggests has been since 2000. https://en.wikipedia.org/wiki/Unicode_in_Microsoft_Windows

I always treat UTF-8 as internet territory like web pages because its reportedly easier to recover from corruption which occurs more often online than with the components inside a computer.

> compiles against its own version of the C/C++ standard library

The C++ library yes. However IIRC Windows now ships a conforming somehow-modern C standard library (ucrt) and modern MSVCs link to it. It is probably also included in current redistributables for the still supported (by MSVC) old versions of Windows that did not have it. Also, the forever binary incompatible C++ standard lib had its limit regardless of the platform (more because of 3rd party binary libs) and MS has switched to a backward binary compatible C++ redistributable for a few years now (they may rebreak in the future).

So on some points (but not all, and it is likely to never be all) the situation is converging.

> to avoid the classic nonsense that every Linux user sees when they build a binary and bring it to an older OS

The thing with building a binary-only program for "Linux" is that "Linux" is not a single OS, and you don't really have cross-distro binary compat except by luck, and for the different versions of a same distro they concentrate on rebuilding everything from source, plus you have a unified namespace of symbols in ELFs so you would not be able to load 2 different C++ libs anyway. This brings drawbacks, but also advantages (for ex you can use C++ libraries of the platform, with an unconstrained C++ API)

So the end result is kind of what you say, except if you want things to work really well you should probably even do:

* a specific native package for each distro (maybe × version) * try to dynamically link to the fewest possible libs of the platform, ideally only glibc (and yes, an old enough one), maybe also libstdc++ if you want to support plugins, and maybe others if they come with a compatibility policy (so on a case by case basis) * or target something else than a native distro (ex: flatpak, appimage), although it is sometimes kind of equivalent to yet other distros -- anyway at this point it starts to resemble to how you would distribute a binary for Windows -- so with those possibilities existing it is just that under a GNU/Linux distro you also have the classic/more-integrated ones.

Anyway, Chrome manages to do binary packages for various version of Debian, and probably other distros; likewise for VS Code and Virtual Box. And building for multiple targets is arguably less a pain today than 10 years ago.

> macOS typically does #2 implicitly

On macOS libSystem.dylib provides the C runtime (i.e. libc). It cannot be statically linked, and AFAIU you cannot ship it with your own project.[1] To support older environments you declare an ABI/API target using MACOSX_DEPLOYMENT_TARGET, -miphoneos-version-min, or similar toolchain option. It's normative for projects targeting an Apple platform to explicitly declare a target several releases in the past, but without an explicit declaration the default is to build a binary targeting the version of the SDK you're using, which would normally be the most recently released.

Bundling your own dynamic libraries is trivial on Linux by simply defining the run-time search path (aka rpath) when building your application. In general, the systems's dynamic linker is entirely agnostic. And this is even easier on Linux than most other platforms as you can use the $ORIGIN macro to define paths relative to the main binary rather than using fixed absolute paths. $ORIGIN was supported several years before the similar capability on macOS, @loader_path and @executable_path.

Bundling dynamic libraries is extremely simple on Linux, it's just not common.

Linking to an older glibc ABI is also possible--glibc rigorously utilizes ELF symbol versioning--but admittedly very difficult. None of the build toolchains provide built-in facilities (i.e. not even anything similar to the musl-gcc wrapper for cross-compiling against musl on glibc-based systems), and for the most part glibc only versions its run-time binary symbols, not its compile-time header API. That means you basically need to download old glibc headers or, as most people tend to do, build on old distributions.

OTOH, on Linux you can at least statically link your own libc on account of the kernel's [relatively] stable ABI.

In practice neither Linux, macOS, nor Windows provide an ideal situation. But at least in principle Linux supports all the common permutations anyone may want, excepting the absence of any singularly blessed system libc. (But to reiterate both musl libc and especially glibc provide strong backwards ABI compatibility, notwithstanding the absence of compile-time knobs for selecting older ABIs.)

[1] Perhaps you can hack things to load a bundled libSystem copy. I have a vague memory of someone pointing that out on HN before. But in any event that's definitely not a supported feature.

> * Just copy the DLLs along with your app in the same folder

Gosh I wish things worked like this by default on Linux (dynamic linker search path by default starts with the directory where the binary is located)

COM best practices should be to ship the libraries as registration free components.

https://docs.microsoft.com/en-us/windows/win32/sbscs/creatin...

Unfortunately, like in every best practices from Microsoft, some teams are in deep need of internal advocacy.

And sometimes (which is I think what most applies to Microsoft) too many authorities that must be pleased and nobody with imperial power to say "In the interests of simplifying, we're going to piss off key stakeholders for a period of time." Microsoft's OS team has, at points in the past, rebuilt data structures from C++ to C with very specific memory footprints rather than break, for example, Photoshop (which was getting more performance from running its own OS structure allocator instead of calling the APIs designed to allocate structures).

Simple ecosystems and simple software usually have the same thing in common: they are either young, or they've recently survived an extinction-level-event. Older systems with many dynamic constraints breed complex webs.

But how do you find vswhere?

I have VS installed on my system, yet vswhere is not in PATH.

The ideal solution is to use modules/classes and parameters names to contextualize, eg:

Windows.find_kit_root(key)

And is even better if your language supports pattern match on the parameters like elixir, so you can "overload" the function with many types of arguments, eg:

Windows.find_kit_root(%User{key: key})

Windows.find_kit_root(%Admin{key: key})

Providing different behaviors to the same function name

Windows is actually quite a bit better. The APIs require you to use an encoding. The multibyte `A` APIs can be whatever encoding the current process is using and will be automatically converted to valid UTF-16. The `W` APIs are for UTF-16. The issue is the latter does not enforce valid UTF-16.

So in practice the only way invalid UTF-16 shows up is from malicious programs (or people testing their handling of non-unicode).

Bags of bytes is at least the honest, "we know that none of you know jack shit about encodings and if we gave you nice APIs some Go developer will ignore them to avoid dynamic linking so the only safe thing to do is poke file paths as opaque blobs and let people optimistically decode them.

MS's approach is better in the case where we're all good stewards of the filesystem but the edges are sharp when someone isn't.

NTFS is old, so I think they're actually just sequences of 16-bit values, once upon a time these were presumed to be UCS-2 characters, now they're presumed to be UTF-16 code units, but either way just as Unix filenames are actually just [u8] the Windows filenames are just [u16]

Which is trivial. For all versions of Visual Studio it's has always been in the same location. They changed the directory structure somewhat around 2017 but it was a minor change.

Also, if you want to run that command you need to run it from the developer command prompt. Otherwise it's location isn't in your path but like I said this script is always in the same location and what it does is that it sets up the environment for you and it's configurable via parameters.

I’m sure that’s why this person posted this snippet.

wchar_t is also more than one byte, so the buffer is at most half as big as the code appears to expect.

That's code copied from the linked gist. But, it omits some key lines in the middle, and does not actually overflow:

    DWORD required_length;
    auto rc = RegQueryValueExW(key, version, NULL, NULL, NULL, &required_length);
    if (rc != 0)  return NULL;

    DWORD length = required_length + 2;  // The +2 is for the maybe optional zero later on. Probably we are over-allocating.
    wchar_t *value = (wchar_t *)malloc(length);
    if (!value) return NULL;

    rc = RegQueryValueExW(key, version, NULL, NULL, (LPBYTE)value, &length);  // We know that version is zero-terminated...
    if (rc != 0)  return NULL;

    // The documentation says that if the string for some reason was not stored
    // with zero-termination, we need to manually terminate it. Sigh!!

    if (value[length]) {
        value[length+1] = 0;
    }

`length` starts at 2 greater than naively needed, then is updated to the real value (again, always 2 less I guess).

Right? So it's for tooling.

I can sympathize. Years ago (more than two decades) the situation was already pretty crazy. I managed to use some version of GNU make for building Visual C++ code.

The Microsoft CL.EXE compiler knew absolutely nothing without being told. Unlike /path/to/whatever/gcc, it doesn't know where its headers or libraries are, nothing.

In the Makefile, had to specify all the include and library paths in the SDK installation.

It's like trying to use GCC's cc1 directly or something.

Since that time there have been many more releases of Visual Studio and the SDK, all of them moving targets without a doubt. Yikes!