Notes About WinInet compared to libcurl
- there's a tech note from Microsoft that says not to use WinInet from system context.
- Even if you ignore the tech note, there are a bunch of annoyances with using WinInet from system context. The biggest of which is proxy settings. In general, the settings are stored per user, so if you find yourself in system context, the correct settings may not be there. Or, if you need to impersonate another user, you're in the same boat. Gotta love the plain text config file. I am curious if people worry about their proxy credentials lying around in plain text, or if they encrypt them, or what.
- Even with the correct settings, there are certain versions of IE (I think it's 6, and maybe with some service packs) that don't work properly when communicating to proxies with basic authentication.
- There are so many sweet features with curl that aren't available with WinInet. Like for example support for more protocols.
- I've never tried to deal with Microsoft for WinInet support, but the curl support (i.e. the libcurl mailing list, and Daniel in particular) is really good.
- Even if portability isn't a concern now, it might be later. And, there's more than just code portability. If you get good with curl, you'll have a useful skill if you work on other platforms. I doubt we'll see WinInet ported anywhere else anytime soon.
- We had some servers in-house and others outside our main network. Each one needed its own proxy and id/password settings for connecting. WinInet will only store one current configuration. This meant that we couldn't connect to both an internal and external server at the same time.
- Another issue was trying to explain to people that when they messed up their IE settings, the application would fail.
- Some of our customers did not USE Internet Explorer. It was installed, but not configured. This meant they had to set up and configure the beast that is IE, even if they would never use it.
A quote from Leonard Rosenthol on the abiword development mailing list:
WinInet is fine for a "hack", but isn't usable for serious I/O - libcurl is MUCH more robust, flexible, and faster.
Thanks to David Byron and Bradford Bruce for much of this input.
If you disagree, agree and/or have other facts/opinions. Mail the curl-library mailing list and tell!