Windows is not a Microsoft Visual C/C++ Run-Time delivery channel
1–10 of 98 posts
Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel
#2[deleted]
Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel
#3A lot of 'real' (cough) hackers like to look down at MS, but Raymond Chen is one of those guys I'd hate to get into a technical argument with: he has experience, is extremely sharp, and very sarcastic. Those three attributes make Old New Thing my favorite MS blog even if I don't write Win32 anymore.
If anything, Windows' level of backward compatibility is a giant cautionary tale: enable poor behavior from devs, and it will proliferate. You cannot trust app devs to do the right thing, they need to be forced to; whether by gatekeepers at app stores, or OS restrictions. It is a tragedy of the commons. Whether it's inane programs inserting themselves into the systray, 'preloaders' for bloated apps (which slow startup), browser extensions, Explorer add-ons, or other garbage, app devs still seem to do a fantastic job of gunking up a Windows install.
This is why it's a bit of a blessing that webapps can't do much; because the more powerful they become, the more annoying and inane they will be.
Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel
#4Sorry, but I'm not going to link to a huge convoluted mess of variously versioned DLLs just to get standard C library functions. Maybe the situation is different with C++ (probably due to no real ABI standard), but the C library functions shouldn't change since they were standardised. If an application breaks because the internals of a library were changed, that's none other than the applications' fault.
Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel
#5A lot of 'real' ( cough ) hackers like to look down at MS, but Raymond Chen is one of those guys I'd hate to get into a technical argument with: he has experience, is extremely sharp, and very sarcastic. Those three attributes make Old New Thing my favorite MS blog even if I don't write Win32 anymore. If anything, Windows' level of backward compatibility is a giant cautionary tale: enable poor behavior from devs, and…
Yea, you can't simultaneously say "Developer, don't do this!" and then "Well, to maintain backwards compatibility with developers who did it, we're going to let you do it. BUT DON'T DO IT!"
MS is in a tight spot. They have this maintanance mess because of their otherwise admirable dedication to backwards compatibility.
Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel
#6Sorry, but I'm not going to link to a huge convoluted mess of variously versioned DLLs just to get standard C library functions. Maybe the situation is different with C++ (probably due to no real ABI standard), but the C library functions shouldn't change since they were standardised. If an application breaks because the internals of a library were changed, that's none other than the applications' fault.
> If an application breaks because the internals of a library were changed, that's none other than the applications' fault.
The issue is that it becomes Microsoft's problem if popular apps break during OS upgrades. Breaking a high-profile app and saying "it's the app's fault" is a good way to attract angry blog posts on the top of HN.
Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel
#7Sorry, but I'm not going to link to a huge convoluted mess of variously versioned DLLs just to get standard C library functions. Maybe the situation is different with C++ (probably due to no real ABI standard), but the C library functions shouldn't change since they were standardised. If an application breaks because the internals of a library were changed, that's none other than the applications' fault.
Not so - I don't think - because so many types in the C standard library are value types. Say you have an array of struct stat (the first thing that springs to mind) - now your program depends on the size of that structure. When its size changes, your code will stop working. The standard doesn't guarantee the size of things, only what members they need to have.
Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel
#8Sorry, but I'm not going to link to a huge convoluted mess of variously versioned DLLs just to get standard C library functions. Maybe the situation is different with C++ (probably due to no real ABI standard), but the C library functions shouldn't change since they were standardised. If an application breaks because the internals of a library were changed, that's none other than the applications' fault.
"If an application breaks because the internals of a library were changed, that's none other than the applications' fault."
I agree 100%, it's certainly the application's fault, but Microsoft has some very large corporate customers that it wants to keep happy, so in some cases it will eat the cost of cleaning up after sloppy developers.
I don't work for Microsoft, but the company I work for (we write expensive enterprise software) has a similar practice of bailing out customers who get into trouble by relying on undocumented behaviors... as long as the customer is important enough that alienating them could cost us significant future revenue. Being willing to provide support like this can differentiate you from your competitors. Not to mention that you can also charge customers extra for this higher level of support.
"Sorry, but I'm not going to link to a huge convoluted mess of variously versioned DLLs just to get standard C library functions."
You don't really have to do that. If you build your application with Visual Studio 2013, you link against the version of the runtime library that it uses, and your application's installer installs the redistributable DLL for that version (if it's not already installed on the customer's machine). You don't have to deal with any other versions.
Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel
#9Sorry, but I'm not going to link to a huge convoluted mess of variously versioned DLLs just to get standard C library functions. Maybe the situation is different with C++ (probably due to no real ABI standard), but the C library functions shouldn't change since they were standardised. If an application breaks because the internals of a library were changed, that's none other than the applications' fault.
It is the application author's fault but it becomes the customer's problem. This is what Raymond repeats over and over. And just telling the authors to fix their problems is no solution either because they are sometimes long out of business but companies still love to use the software that JustWorks™ even though it is 20 years old.
Re: Windows is not a Microsoft Visual C/C++ Run-Time delivery channel
#10The discussion in the comments is interesting. MinGW, the compiler for VLC, LibreOffice and most other FOSS projects on Windows does exactly what Raymond says not to do. In fact, the entire purpose of MinGW is to make GCC able to target msvcrt.dll. Developers and users love this, since they don't have to distribute and install the CRT with the program. Developers following the GPL aren't even allowed to distribute the CRT with their program, so they have to use one already present on the system.
Though Raymond is correct. The MinGW guys should probably "write and ship their own runtime library," or at least use the msvcrt from ReactOS or Wine. That should make it possible to statically link to it.
Having said that, Microsoft probably won't change their msvcrt.dll in a way that breaks MinGW software, since their users will complain that they broke VLC.