3 ms·

Raymond Chen wrote about this in his 2014 blog post "Windows is not a Microsoft Visual C/C++ Run-Time delivery channel" https://devblogs.microsoft.com/oldnewth

by nly 7y ago

Raymond Chen wrote about this in his 2014 blog post "Windows is not a Microsoft Visual C/C++ Run-Time delivery channel" https://devblogs.microsoft.com/oldnewthing/20140411-00/?p=1273 https://devblogs.microsoft.com/oldnewthing/20140411-00/?p=12... Stable ABIs are good, but the ability to break it and iterate/improve is even more so. GNU platforms are currently stuck with a shitty std::string implementation (32 bytes but only 15 bytes of SSO capacity) because breaking ABI means recompiling your entire Linux distro.

Asooka 7y ago
As he notes there, Windows does ship a C/C++ runtime, but you're not allowed to use that one - it is only for internal Windows stuff and only ever has to be compatible with whatever software comes with Windows. Any Windows update can make it binary-incompatible with a third-party program. User axjs notes in another top-level comment that a Google libc(++) will always just serve Google's products, including keeping bugs that a Google product relies on - somewhat similar to the Microsoft C/C++ runtime that comes with Windows, which you are strongly encouraged not to use.
- nly 7y ago
  If it will only ever serve Google then it shouldn't be part of upstream.
- Crinus 7y ago
  That ship has sailed a long time ago, anything compiled with MinGW links against MSVCRT.DLL and did that from the beginning. Considering they had to backpedal changes in that DLL because it broke some program, as mentioned in the linked blog, i doubt this DLL will ever be removed as that will break thousands of applications that have come to rely on it.
  - xeeeeeeeeeeenu 7y ago
    >anything compiled with MinGW links against MSVCRT.DLL It has changed recently, MinGW-w64 supports linking with UCRT instead of msvcrt.dll. Unfortunately, it's almost undocumented[1]. [1] - https://sourceforge.net/p/mingw-w64/mailman/message/36621319/ https://sourceforge.net/p/mingw-w64/mailman/message/36621319...
    - Crinus 7y ago
      Considering that it isn't the default and it is only available on Windows 10 (and that only since 2015) i think that it is very safe to say that for all intents and purposes "anything compiled with MinGW links against MSVCRT.DLL" is valid and will be for a long time. Though even if MinGW switched to UCRT tomorrow, it would still leave a ton of executables since 1998 (or whenever it started using it) relying on MSVCRT.DLL (which AFAIK is included by default in Windows since Windows 98 so it has a slightly wider support range than UCRT :-P).

by nly 7y ago

Asooka 7y ago

As he notes there, Windows does ship a C/C++ runtime, but you're not allowed to use that one - it is only for internal Windows stuff and only ever has to be compatible with whatever software comes with Windows. Any Windows update can make it binary-incompatible with a third-party program. User axjs notes in another top-level comment that a Google libc(++) will always just serve Google's products, including keeping bugs that a Google product relies on - somewhat similar to the Microsoft C/C++ runtime that comes with Windows, which you are strongly encouraged not to use.

nly 7y ago
If it will only ever serve Google then it shouldn't be part of upstream.
Crinus 7y ago
That ship has sailed a long time ago, anything compiled with MinGW links against MSVCRT.DLL and did that from the beginning. Considering they had to backpedal changes in that DLL because it broke some program, as mentioned in the linked blog, i doubt this DLL will ever be removed as that will break thousands of applications that have come to rely on it.
- xeeeeeeeeeeenu 7y ago
  >anything compiled with MinGW links against MSVCRT.DLL It has changed recently, MinGW-w64 supports linking with UCRT instead of msvcrt.dll. Unfortunately, it's almost undocumented[1]. [1] - https://sourceforge.net/p/mingw-w64/mailman/message/36621319/ https://sourceforge.net/p/mingw-w64/mailman/message/36621319...
  - Crinus 7y ago
    Considering that it isn't the default and it is only available on Windows 10 (and that only since 2015) i think that it is very safe to say that for all intents and purposes "anything compiled with MinGW links against MSVCRT.DLL" is valid and will be for a long time. Though even if MinGW switched to UCRT tomorrow, it would still leave a ton of executables since 1998 (or whenever it started using it) relying on MSVCRT.DLL (which AFAIK is included by default in Windows since Windows 98 so it has a slightly wider support range than UCRT :-P).