Hacker News Reader

Comment by userbinator | Hacker News Reader

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

View on HN

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

> and your application's installer installs the redistributable DLL for that version

I don't want an installer, nor to include the redistributable which is around 2 orders of magnitude larger than the application itself! I want a single tiny binary, just download and run on any system, and that's what using MSVCRT allows.

Sure, and for that upside you pay the downside of not knowing when that ever-changing dependency may inadvertently break your application. There's no free lunch.

What's wrong with an installer? An unattended installer or even a click through one is no obstacle these days.

- I write my applications to run anywhere and not require any installation. There is a huge convenience factor in this. As a collorary, they also don't require uninstallation since they do not "embed" themselves into the system (registry, config files, additional files elsewhere, etc.)

- It makes for a bigger download, of code and data that would never be used again, with one extra step the user has to do before use, and also an extra step for me to build the installer too.

I can see the advantages of an installer for large applications that need to be "installed" since they modify various other things in the system, but that's not the type of applications I work with.

The problem with that is that your software is a bad citizen in the windows ecosystem. Even a one shot can be pushed out or run via an msi package with no install. And you get the benefit of being able to easy throw it out via GPO, pull dependencies like VCRT versions etc. MSI packages are pretty small as well - our current VSTO package which has about 25,000 LoC in it is only 400k.

> your software is a bad citizen in the windows ecosystem

According to MS who seem to be trying to force the idea that all software needs to be "installed" and have an overly complex installer/uninstaller. I care more about the flexibility and convenience for my users than what MS thinks (which is ultimately heading towards locking users in a walled garden, so no surprise that "just download and run a self-contained executable anywhere" is perceived as somewhat of a threat.)

> And you get the benefit of being able to easy throw it out via GPO, pull dependencies like VCRT versions etc.

Those are not needed for what I'm doing, so they're not benefits to me. But I guess if your idea of "pretty small" is 400k, then that's not really a concern...

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

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.

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.

What if your application is a plugin. Or SDK?

It enough, when you application uses several third party SDKs or plugins, each built with different MSVC version.

Sometimes, it has interesting impact. For example, you aren't going to get PyQt5 for Python 2.x, because binaries (builds from python.org and ActiveState) for Python 2.x are built with MSVC9 and Qt5 requires MSVC10 at minimum.

Reply on news.ycombinator.com