Comment by greenyoda | Hacker News Reader

Comment by greenyoda | Hacker News Reader

Parent Full thread

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

Reply on news.ycombinator.com