Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The problem isn't getting your files in the right place, the problem lies in how inter-connected and "integrated" everything is on Windows. There are many examples: "Internet Settings", for instance, from the control panel, while they seem to be IE's settings, actually affect how some Windows Internet-family API functions behave. Then there is a big hairy mess called COM/ActiveX: you can't parse XML without it, yet there will be computers, be it one out of 100, with broken XML parser COM registration. Same applies to various "shell services" which are essential to desktop integration.

Then there are cases when other applications break your code: Symantec used to install their own version of MFC DLL right into System32. Then there are super-aggressive anti-spyare/anti-virus/anti-whatever packages that are basically hacks breaking all kinds of legit software. Windows encourages this style of development: when an application essentially becomes a collection of COM servers scattered across your hard drive, hooked into your system via complex mesh of registry settings. And there is no way around it: this is what MSDN tells you to do.

Then you'll have users complaining that when they launch your RSS reading software (or whatever you do), they get a popup that says "Windows Installer: configuring Microsoft Office" that disappears after about a minute of "collecting system information". And users will tell you that everything worked great for 2 months but then "computer did something" and this popup started appearing.

And they keep adding more shit on top of existing shit. Now, in addition to COM and MSI and registry you get this "side-by-side execution" bullshit, when you can't even tell which version of a DLL is being loaded and Windows Explorer essentially hides fucking files from you so even locating a misbehaving DLL becomes a debugging session on its own, where you'll need to decode cryptic hidden directory names and extract a manifest from some executable's resources to see which DLL it actually wants. When they rolled that out I felt sick for a while.

And finally, there is no such thing as "Windows API" anymore. XP machine connected to a domain controller/AD is a very different beast than XP home or Win2K. I'm not even mentioning Vista here.

For my last Windows project I went for "xcopy deployment" with one single fat executable statically linked to everything it needed to run with some help from open source libraries, essentially very similarly to how Firefox does it. But this style of development isn't really for "Windows Platform", this way you're targeting a "sane subset" of Windows platform.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: