7 ms·

Something I always wondered about Visual Studio and Windows programming: If you compile a C++ program with Visual Studio, it gets dynamic dependencies on some

Something I always wondered about Visual Studio and Windows programming: If you compile a C++ program with Visual Studio, it gets dynamic dependencies on some visual studio DLLs. DLLs that are not necessarily installed by default on the Windows of the target user you're compiling for. So the question is: MS created both Windows and Visual Studio. So why can't Visual Studio compile to something that works by default on the Windows of the target audience without requiring them to install those additional DLLs? Doesn't the win32 API provide enough, and can't Visual Studio statically link in whatever extras it needs, or those extras be added to the Windows API that is present by default if they're that necessary? Also, given that Windows comes with pre-installed programs that were written in C++, how did those programs get compiled to not require those Visual Studio dependencies, are MS not using Visual Studio themselves internally?

ChrisSD 5y ago
> can't Visual Studio statically link in whatever extras it needs It can but you have to change some options (`/MT` iirc). And if you want to be really minimalist you only need to statically link the runtime (if you avoid using the C++ standard library).
- quietbritishjim 5y ago
  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.
  - dilyevsky 5y ago
    Always link statically whenever possible (looking at you mac os)
stinos 5y ago
(note this reply might not use accurate terms, but it's just to explain some general principle) visual studio DLLs. I assume you mean the C runtime etc, which isn't tied to VS but to 'build tools' i.e. compiler/linker. VS just uses those. It can also use other non-MS compiler/linker. So why can't Visual Studio compile to something that works by default It largely can, see next answer. on the Windows of the target audience without requiring them to install those additional DLLs? I think (not 100% sure though) because there were historically different versions of those. And as said possibly from different compiler vendors. See also https://stackoverflow.com/questions/16167305/why-does-my-application-require-visual-c-redistributable-package https://stackoverflow.com/questions/16167305/why-does-my-app... But: things changed somewhat since then though, there's now a 'universal C runtime' which gets installed with Windows 10 and which covers versions of the runtime used per default by the built tools which ship with VS2015 and beyond. Which given the history is quite a piece of work they pulled off. how did those programs get compiled to not require those Visual Studio dependencies, Static linking.
Andrex 5y ago
This has annoyed me going back to Silverlight. They really just don't care users have to install extra things to get your program working. First-party toolkit stuff like this should be built into the OS.
- andrew_ 5y ago
  Java and .NET have entered the chat
  - Andrex 5y ago
    I've never quite understood why the .NET runtime didn't ship with Windows. And Microsoft presumably controls Windows Update too, right? :thinking:
    - pitterpatter 5y ago
      One reason why some have preferred not to ship with Windows is so that they aren't tied to the Windows release cycle. Not to mention, getting fixes into the monthly updates in a whole thing in and of itself.
    - tssva 5y ago
      A .NET runtime does ship with Windows . It is just often not the version being targeted by a developer which means the targeted runtime needs to be installed.
    - my123 5y ago
      The new (.NET Core then .NET 5 onwards) runtimes aren't installed automatically. But when you install them manually, they are serviced for security updates through Windows Update, so that you don't have to do that manually.
- passivate 5y ago
  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.
kaetemi 5y ago
You can completely avoid linking it, if you don't use any C or C++ standard library functionality.
ComputerGuru 5y ago
This lets you build against the MSVCRT that ships with all versions of Windows: https://github.com/neosmart/msvcrt.lib https://github.com/neosmart/msvcrt.lib
pjmlp 5y ago
Because of using binary libraries and the ABI can break at any time, in fact ABI stability is something quite recent, introduced in VS 2015 and now plenty of people are asking for them to break it again on VS vNext. C and C++ runtime libraries aren't an OS API on non-UNIX platforms, each compiler vendor ships their own libraries. Windows 10 now has C universal runtime library as part of the OS, but that is because nowadays almost everyone only cares about Visual C++ compatibility. You can have your binaries without extra dependencies, code against Win32 in C without any dependency on ISO C or ISO C++ calls, that is how demoscene competitions work.
- zerr 5y ago
  > are asking for them to break it again on VS vNext. Why?
  - pjmlp 5y ago
    Because some C++20 features can only be fully compliant with an ABI break. https://github.com/microsoft/STL/issues/1814 https://github.com/microsoft/STL/issues/1814 https://devblogs.microsoft.com/cppblog/msvc-cpp20-and-the-std-cpp20-switch/#msvc-extensions-and-abi https://devblogs.microsoft.com/cppblog/msvc-cpp20-and-the-st...
garaetjjte 5y ago
>So why can't Visual Studio compile to something that works by default on the Windows of the target audience without requiring them to install those additional DLLs? Since Windows 10 it ships with Universal C Runtime, which is used by VS2015+. System software uses these runtimes too. For Win7+ it was added as system update, though MS later relented and said it was fine to copy-paste all the api-ms* libraries from the SDK into your application directory so it also works on outdated installations. In the past it was different though, as system software was compiled against MSVCRT.DLL, but you wasn't supposed to use it and instead use version specific DLLs shipped in "Visual C++ Redistributables". Though going back to Windows 9x there was a time when MSVCRT.DLL was the library that was supposed to be used by applications. See http://bytepointer.com/resources/old_new_thing/20140411_092_windows_is_not_a_microsoft_visual_c_c_run_time_delivery_channel.htm http://bytepointer.com/resources/old_new_thing/20140411_092_...
- bni 5y ago
  "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.
  - Diggsey 5y ago
    There are two "components" to what used to be `msvcrt.lib`: - The C runtime library (now `ucrt.lib` AKA the universal C runtime) - The compiler runtime (now `vcruntime.lib`) The former has a stable API, but the latter doesn't - it changes from one compiler version to the next, as it is used to support various C++ language features. When these two were combined as `msvcrt.lib`, there was no way for windows to ship it with the OS, because it changed with each VC++ version - they could have shipped historical versions, but it wouldn't really help developers who can't guarantee that the the OS version used by their users is newer than their version of VC++. Now that these two are split, microsoft can ship the stable universal C runtime with the OS, and programs that only rely on the C runtime do not need a redistributable at all. (This makes things easier for other languages like Rust, or things compiled from GCC, which don't need the VC++ runtime). Programs that use the VC++ runtime still need to ship the corresponding `vcruntime`, although you still have plenty of freedom in how you do that (eg. bundle DLLs, statically link, etc.) and the compiler runtime itself is smaller than the whole C runtime library.
formerly_proven 5y ago
Because: https://zachmortensen.files.wordpress.com/2013/08/microsoft-org-structure1.jpg https://zachmortensen.files.wordpress.com/2013/08/microsoft-... > Also, given that Windows comes with pre-installed programs that were written in C++, how did those programs get compiled to not require those Visual Studio dependencies, are MS not using Visual Studio themselves internally? They do, iirc Windows pretty much always came with "unspecified" versions of the MSVCRT "for internal use only". Also, iirc, at some point Windows took some steps to remove those from the default search paths or something.
AtNightWeCode 5y ago
MS are not the best at dogfooding. I think they even once released VS as WPF to prove it can be used in a real app. Anyway, my experience with VC++ and the packages is that you get better control when shipping the dependencies separately. You can resolve the dependencies during installation but it is just more complex.
- pjmlp 5y ago
  More than once, that is VS still today since the 2010 rewrite.
  - AtNightWeCode 5y ago
    Thought it was abandoned but it explains the poor quality of VS and all the constantly resurrecting bugs.
    - pjmlp 5y ago
      Not more not less of other IDEs.
      - AtNightWeCode 5y ago
        True, but then VS is a commercial product and a fairly expensive one. Seems like there are no automatic regression tests at all. Basic functions breaks all the time. Just a very poor quality piece of software for being a software targeting developers.
        pjmlp 5y ago
        Ah you mean like the bugs I hit all the time on commercial IDEs like JetBrains products?
    - tester756 5y ago
      What do you mean? I feel like VS' GUI is somewhat decent
anaisbetts 5y ago
I mean, Visual Studio does this (compiles against its own version of the C/C++ standard library) to avoid the classic nonsense that every Linux user sees when they build a binary and bring it to an older OS then it demands a newer version of glibc and segfaults - this is why every commercial Linux app has to compile on the oldest Linux they can possibly find, and it's frustrating. You can either: * Statically link, so you don't need these DLLs at all * Just copy the DLLs along with your app in the same folder * Ask users to install the VC Redist package Option #2 is typically the best one and is pretty easy to do. macOS typically does #2 implicitly (i.e. libswift.framework et al), but ships all of those binaries in a "bundle" that is hidden from users.
- tonyedgecombe 5y ago
  >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.
  - plorkyeran 5y ago
    The redist installer is recommended but not required.
    - anaisbetts 5y ago
      I'm not sure it's even recommended any more. It's technically better because it means that Microsoft can apply security patches out-of-band, but on the other hand, it means that Microsoft can change The Code Your App Executes without you testing it, and tbh if you're writing a production app you should probably make sure your libraries are up-to-date anyways
  - rezonant 5y ago
    No you can redistribute them, that's why they are called redistributable. See here: https://docs.microsoft.com/en-us/cpp/windows/determining-which-dlls-to-redistribute?view=msvc-170 https://docs.microsoft.com/en-us/cpp/windows/determining-whi...
mook 5y ago
> So the question is: MS created both Windows and Visual Studio. So why can't Visual Studio compile to something that works by default on the Windows of the target audience without requiring them to install those additional DLLs? Because msvcrt.dll must be compatible with MSVC6 or something ridiculous like that (the amd64 version probably needs to be ABI compatible with a different version, because MSVC6 didn't have amd64). They want to maintain backwards compatibility with existing software, so they can't change the ABI around. You might think, who cares about old software? Well, last I checked MinGW links against msvcrt.dll as well, so to provide compatibility with them (and probably software built today with the MinGW toolchain) they still need to keep it around and compatible. This is analogous to running with really old glibc… even that had a soname bump (it's not at 1 anymore). Can't exactly add symbol versioning either, since 1) it needs to support older versions of Windows, 2) people could totally roll their own dynamic loader… PE isn't exactly secret. For your last paragraph, as I understand it the Windows team basically uses their own fork of the toolchain, stuck bring binary compatible…
pjc50 5y ago
> why can't Visual Studio compile to something that works by default on the Windows of the target audience without requiring them to install those additional DLLs? Not without a time machine; the problem is that you can target older versions of windows with newer versions of Visual Studio. When Microsoft produces vc_redist_2022.exe they can put it Windows 11, but how do they put it in the 2018 version of Windows 10? The arrival of the Windows Store raises the possibility of automatically installing dependencies. You can also create an "unpackaged" app that uses the WinRT APIs without being a Windows Store app distributed through the store, but if you do that you're exposed to all the horrific machinery yourself as a developer: https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/deployment-architecture#dynamic-dependency-lifetime-manager-ddlm https://docs.microsoft.com/en-us/windows/apps/windows-app-sd... In re static linking: I haven't checked but I suspect that COM is involved somewhere. Does anyone have a good summary of what's actually _in_ the redistributable?
- pjmlp 5y ago
  COM best practices should be to ship the libraries as registration free components. https://docs.microsoft.com/en-us/windows/win32/sbscs/creating-registration-free-com-objects 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.
jsmith99 5y ago
We've come a long way since the time Microsoft was almost broken up. I can't believe HN are now calling for Microsoft to be more tightly integrated.
pierrebai 5y ago
Because bundling DLL in your installer is not hard? Because most non-toy program will have DLL of their own anyway that will need installing? As for the original craziness header, I found it hilariously, but pretty typically, harsh and unfair. Finding the compiler and all is environment is not an easy task in any OS. I've been programming for a looooong time I remember havign to write code that compiled on: IRIX, Solaris, HpUx, IBM unix, Windows and more. Anyone who ever took a look at configure.sh knows the horrors it holds at bay.
kazinator 5y ago
> If you compile a C++ program with Visual Studio, it gets dynamic dependencies on some visual studio DLLs. DLLs that are not necessarily installed by default on the Windows of the target user you're compiling for. There is no "necessarily" about it. They are not installed by Windows, period. If they exist on the user's machine, it's because other applications have installed them, for themselves. Applications should have these libraries in their own folders, and those libraries are the specific version the applications were built with. When you ship an application build with the Microsoft toolchain, you ship the required redistributable libraries in your installer. Using libraries on Windows is a cinch, because Windows does the smart thing: when an executable needs a DLL, it first looks in the same directory as that executable. Thus your installer can just throw your exe's and dll's into one folder and be done with it. There is a new thing in Windows: the UCRT (universal C run-time library). It's an attempt to provide something similar to a libc in the Unix-like world: a stable library in the OS, so applications don't have to ship one. Or something of that nature. Windows has a C library for its own utilities and middleware called MSVCRT.DLL. That is off-limits to applications though. This new UCRT is documented for application use.
mmis1000 5y ago
Probably just because they aren't created by the same team. Teams in MS are so horizontally disconnected that you can even find 4+ types of menu in the windows 10 build-in apps. The people created windows and the one handling VS aren't necessary have very strong connection.

ChrisSD 5y ago

> can't Visual Studio statically link in whatever extras it needs It can but you have to change some options (`/MT` iirc). And if you want to be really minimalist you only need to statically link the runtime (if you avoid using the C++ standard library).

quietbritishjim 5y ago
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.
- dilyevsky 5y ago
  Always link statically whenever possible (looking at you mac os)

stinos 5y ago

(note this reply might not use accurate terms, but it's just to explain some general principle) visual studio DLLs. I assume you mean the C runtime etc, which isn't tied to VS but to 'build tools' i.e. compiler/linker. VS just uses those. It can also use other non-MS compiler/linker. So why can't Visual Studio compile to something that works by default It largely can, see next answer. on the Windows of the target audience without requiring them to install those additional DLLs? I think (not 100% sure though) because there were historically different versions of those. And as said possibly from different compiler vendors. See also https://stackoverflow.com/questions/16167305/why-does-my-application-require-visual-c-redistributable-package https://stackoverflow.com/questions/16167305/why-does-my-app... But: things changed somewhat since then though, there's now a 'universal C runtime' which gets installed with Windows 10 and which covers versions of the runtime used per default by the built tools which ship with VS2015 and beyond. Which given the history is quite a piece of work they pulled off. how did those programs get compiled to not require those Visual Studio dependencies, Static linking.

Andrex 5y ago

This has annoyed me going back to Silverlight. They really just don't care users have to install extra things to get your program working. First-party toolkit stuff like this should be built into the OS.

andrew_ 5y ago
Java and .NET have entered the chat
- Andrex 5y ago
  I've never quite understood why the .NET runtime didn't ship with Windows. And Microsoft presumably controls Windows Update too, right? :thinking:
  - pitterpatter 5y ago
    One reason why some have preferred not to ship with Windows is so that they aren't tied to the Windows release cycle. Not to mention, getting fixes into the monthly updates in a whole thing in and of itself.
  - tssva 5y ago
    A .NET runtime does ship with Windows . It is just often not the version being targeted by a developer which means the targeted runtime needs to be installed.
  - my123 5y ago
    The new (.NET Core then .NET 5 onwards) runtimes aren't installed automatically. But when you install them manually, they are serviced for security updates through Windows Update, so that you don't have to do that manually.
passivate 5y ago
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.

kaetemi 5y ago

You can completely avoid linking it, if you don't use any C or C++ standard library functionality.

ComputerGuru 5y ago

This lets you build against the MSVCRT that ships with all versions of Windows: https://github.com/neosmart/msvcrt.lib https://github.com/neosmart/msvcrt.lib

pjmlp 5y ago

Because of using binary libraries and the ABI can break at any time, in fact ABI stability is something quite recent, introduced in VS 2015 and now plenty of people are asking for them to break it again on VS vNext. C and C++ runtime libraries aren't an OS API on non-UNIX platforms, each compiler vendor ships their own libraries. Windows 10 now has C universal runtime library as part of the OS, but that is because nowadays almost everyone only cares about Visual C++ compatibility. You can have your binaries without extra dependencies, code against Win32 in C without any dependency on ISO C or ISO C++ calls, that is how demoscene competitions work.

zerr 5y ago
> are asking for them to break it again on VS vNext. Why?
- pjmlp 5y ago
  Because some C++20 features can only be fully compliant with an ABI break. https://github.com/microsoft/STL/issues/1814 https://github.com/microsoft/STL/issues/1814 https://devblogs.microsoft.com/cppblog/msvc-cpp20-and-the-std-cpp20-switch/#msvc-extensions-and-abi https://devblogs.microsoft.com/cppblog/msvc-cpp20-and-the-st...

garaetjjte 5y ago

>So why can't Visual Studio compile to something that works by default on the Windows of the target audience without requiring them to install those additional DLLs? Since Windows 10 it ships with Universal C Runtime, which is used by VS2015+. System software uses these runtimes too. For Win7+ it was added as system update, though MS later relented and said it was fine to copy-paste all the api-ms* libraries from the SDK into your application directory so it also works on outdated installations. In the past it was different though, as system software was compiled against MSVCRT.DLL, but you wasn't supposed to use it and instead use version specific DLLs shipped in "Visual C++ Redistributables". Though going back to Windows 9x there was a time when MSVCRT.DLL was the library that was supposed to be used by applications. See http://bytepointer.com/resources/old_new_thing/20140411_092_windows_is_not_a_microsoft_visual_c_c_run_time_delivery_channel.htm http://bytepointer.com/resources/old_new_thing/20140411_092_...

bni 5y ago
"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.
- Diggsey 5y ago
  There are two "components" to what used to be `msvcrt.lib`: - The C runtime library (now `ucrt.lib` AKA the universal C runtime) - The compiler runtime (now `vcruntime.lib`) The former has a stable API, but the latter doesn't - it changes from one compiler version to the next, as it is used to support various C++ language features. When these two were combined as `msvcrt.lib`, there was no way for windows to ship it with the OS, because it changed with each VC++ version - they could have shipped historical versions, but it wouldn't really help developers who can't guarantee that the the OS version used by their users is newer than their version of VC++. Now that these two are split, microsoft can ship the stable universal C runtime with the OS, and programs that only rely on the C runtime do not need a redistributable at all. (This makes things easier for other languages like Rust, or things compiled from GCC, which don't need the VC++ runtime). Programs that use the VC++ runtime still need to ship the corresponding `vcruntime`, although you still have plenty of freedom in how you do that (eg. bundle DLLs, statically link, etc.) and the compiler runtime itself is smaller than the whole C runtime library.

formerly_proven 5y ago

Because: https://zachmortensen.files.wordpress.com/2013/08/microsoft-org-structure1.jpg https://zachmortensen.files.wordpress.com/2013/08/microsoft-... > Also, given that Windows comes with pre-installed programs that were written in C++, how did those programs get compiled to not require those Visual Studio dependencies, are MS not using Visual Studio themselves internally? They do, iirc Windows pretty much always came with "unspecified" versions of the MSVCRT "for internal use only". Also, iirc, at some point Windows took some steps to remove those from the default search paths or something.

AtNightWeCode 5y ago

MS are not the best at dogfooding. I think they even once released VS as WPF to prove it can be used in a real app. Anyway, my experience with VC++ and the packages is that you get better control when shipping the dependencies separately. You can resolve the dependencies during installation but it is just more complex.

pjmlp 5y ago
More than once, that is VS still today since the 2010 rewrite.
- AtNightWeCode 5y ago
  Thought it was abandoned but it explains the poor quality of VS and all the constantly resurrecting bugs.
  - pjmlp 5y ago
    Not more not less of other IDEs.
    - AtNightWeCode 5y ago
      True, but then VS is a commercial product and a fairly expensive one. Seems like there are no automatic regression tests at all. Basic functions breaks all the time. Just a very poor quality piece of software for being a software targeting developers.
      - pjmlp 5y ago
        Ah you mean like the bugs I hit all the time on commercial IDEs like JetBrains products?
  - tester756 5y ago
    What do you mean? I feel like VS' GUI is somewhat decent

anaisbetts 5y ago

I mean, Visual Studio does this (compiles against its own version of the C/C++ standard library) to avoid the classic nonsense that every Linux user sees when they build a binary and bring it to an older OS then it demands a newer version of glibc and segfaults - this is why every commercial Linux app has to compile on the oldest Linux they can possibly find, and it's frustrating. You can either: * Statically link, so you don't need these DLLs at all * Just copy the DLLs along with your app in the same folder * Ask users to install the VC Redist package Option #2 is typically the best one and is pretty easy to do. macOS typically does #2 implicitly (i.e. libswift.framework et al), but ships all of those binaries in a "bundle" that is hidden from users.

tonyedgecombe 5y ago
>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.
- plorkyeran 5y ago
  The redist installer is recommended but not required.
  - anaisbetts 5y ago
    I'm not sure it's even recommended any more. It's technically better because it means that Microsoft can apply security patches out-of-band, but on the other hand, it means that Microsoft can change The Code Your App Executes without you testing it, and tbh if you're writing a production app you should probably make sure your libraries are up-to-date anyways
- rezonant 5y ago
  No you can redistribute them, that's why they are called redistributable. See here: https://docs.microsoft.com/en-us/cpp/windows/determining-which-dlls-to-redistribute?view=msvc-170 https://docs.microsoft.com/en-us/cpp/windows/determining-whi...

mook 5y ago

> So the question is: MS created both Windows and Visual Studio. So why can't Visual Studio compile to something that works by default on the Windows of the target audience without requiring them to install those additional DLLs? Because msvcrt.dll must be compatible with MSVC6 or something ridiculous like that (the amd64 version probably needs to be ABI compatible with a different version, because MSVC6 didn't have amd64). They want to maintain backwards compatibility with existing software, so they can't change the ABI around. You might think, who cares about old software? Well, last I checked MinGW links against msvcrt.dll as well, so to provide compatibility with them (and probably software built today with the MinGW toolchain) they still need to keep it around and compatible. This is analogous to running with really old glibc… even that had a soname bump (it's not at 1 anymore). Can't exactly add symbol versioning either, since 1) it needs to support older versions of Windows, 2) people could totally roll their own dynamic loader… PE isn't exactly secret. For your last paragraph, as I understand it the Windows team basically uses their own fork of the toolchain, stuck bring binary compatible…

pjc50 5y ago

> why can't Visual Studio compile to something that works by default on the Windows of the target audience without requiring them to install those additional DLLs? Not without a time machine; the problem is that you can target older versions of windows with newer versions of Visual Studio. When Microsoft produces vc_redist_2022.exe they can put it Windows 11, but how do they put it in the 2018 version of Windows 10? The arrival of the Windows Store raises the possibility of automatically installing dependencies. You can also create an "unpackaged" app that uses the WinRT APIs without being a Windows Store app distributed through the store, but if you do that you're exposed to all the horrific machinery yourself as a developer: https://docs.microsoft.com/en-us/windows/apps/windows-app-sdk/deployment-architecture#dynamic-dependency-lifetime-manager-ddlm https://docs.microsoft.com/en-us/windows/apps/windows-app-sd... In re static linking: I haven't checked but I suspect that COM is involved somewhere. Does anyone have a good summary of what's actually _in_ the redistributable?

pjmlp 5y ago
COM best practices should be to ship the libraries as registration free components. https://docs.microsoft.com/en-us/windows/win32/sbscs/creating-registration-free-com-objects 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.

jsmith99 5y ago

We've come a long way since the time Microsoft was almost broken up. I can't believe HN are now calling for Microsoft to be more tightly integrated.

pierrebai 5y ago

Because bundling DLL in your installer is not hard? Because most non-toy program will have DLL of their own anyway that will need installing? As for the original craziness header, I found it hilariously, but pretty typically, harsh and unfair. Finding the compiler and all is environment is not an easy task in any OS. I've been programming for a looooong time I remember havign to write code that compiled on: IRIX, Solaris, HpUx, IBM unix, Windows and more. Anyone who ever took a look at configure.sh knows the horrors it holds at bay.

kazinator 5y ago

> If you compile a C++ program with Visual Studio, it gets dynamic dependencies on some visual studio DLLs. DLLs that are not necessarily installed by default on the Windows of the target user you're compiling for. There is no "necessarily" about it. They are not installed by Windows, period. If they exist on the user's machine, it's because other applications have installed them, for themselves. Applications should have these libraries in their own folders, and those libraries are the specific version the applications were built with. When you ship an application build with the Microsoft toolchain, you ship the required redistributable libraries in your installer. Using libraries on Windows is a cinch, because Windows does the smart thing: when an executable needs a DLL, it first looks in the same directory as that executable. Thus your installer can just throw your exe's and dll's into one folder and be done with it. There is a new thing in Windows: the UCRT (universal C run-time library). It's an attempt to provide something similar to a libc in the Unix-like world: a stable library in the OS, so applications don't have to ship one. Or something of that nature. Windows has a C library for its own utilities and middleware called MSVCRT.DLL. That is off-limits to applications though. This new UCRT is documented for application use.

mmis1000 5y ago

Probably just because they aren't created by the same team. Teams in MS are so horizontally disconnected that you can even find 4+ types of menu in the windows 10 build-in apps. The people created windows and the one handling VS aren't necessary have very strong connection.