New version of XML-RPC Library Released!

XML-RPC is a spec that allows software running on different operating systems to make remote procedure calls over the internet using XML over HTTP. It was inspired by a more simplistic RPC protocol and an early draft of the SOAP protocol. xml-rpc-c is one such implementation of XML-RPC.

I used this library in the past for multiple reasons. First, I needed to (essentially) perform a remote procedure call. Secondly, I needed it to be cross platform (*nix and Windows). Third was the library must not run under some compatibility layer for Windows such as MinGW or CygWin (too many headaches in the past for my taste). On the wishlist was a single library that can be used on both platforms so I could concentrate on core application functionality and not worry about writing interface classes to several different implementations of a protocol. At the time, SOAP was out, and this library was in.

Granted, there was a bit of work needed on the Windows side. I wanted to use the WinInet API's so I wouldn't have to deal with configuring proxy settings in my application - if IE worked, I wanted my app to work, too. WinInet support wasn't working out of the box - in fact the original maintainer sort of dropped out of sight. Thanks to the community at the time (especially Alex), I was able to share a few patches and get it working.

When I saw that Bryan Henderson had taken over the library as the official admin and began active development, I saw it as an opportunity to contribute something back to the community. I suppose my role is maintainer of all things Windows-related.

The latest release features a new possibility for Windows users. I created an XML-RPC server using the http.sys dll shipped with Windows Server 2003 and Windows XP SP2. Applications using this dll can share the same port as other applications using this dll. Windows Server 2003's IIS 6 happens to use it, so you can even share port 80 and/or 443 with it seamlessly - no more ISAPI dll's to accomplish that feat!

For developers looking to use http.sys in your own code, as well as using it with SSL, this code may serve as an example for your own purposes - such as dealing with basic authentication or SSL connections which is not provided for in the http.sys API's or documentation. There is a dearth of example code out there for this particular API for some reason.

For making client-to-server calls on Windows, the only out-of-the-box solution was the WinInet transport. The problem with this API is it can't be used in a service. Although the xml-rpc-c library always supported using libcurl out of the box, the compilation and linking of this was difficult to figure out and required a few creative changes. With this release, I hope to have made it easier.

Finally, the last major change was tightening up the WinInet transport a bit. Previously, communication over SSL would succeed even if the server certificate was invalid. That functionality was great when developing using a test certificate, but probably not what you want to use in production. By default, the old behavior is now only active if set by a specific transport option at runtime.

If anyone is using this library, on Windows or otherwise, please feel free to give me a shout. If you have any feature requests, let me know. One note to downloaders - for some reason the tarball does not extract properly using WinRar. If you rename the download to have a .tgz extension and use WinZip to decompress it, you will be able to open the project files in Visual C++ 6 without problems. Visual Studio 2003 will also open, convert, and compile the project without problems.

Integrate the latest MSDN Library Help with VC++ 6

*See update at bottom of this entry*

There is an awesome article just published on Code Project that shows how to Integrate the latest MSDN Library Help with VC++ 6. Although you can simply download the demo project and follow the instructions after "How to set the default help collection?" at the end of the article, the article itself is a great primer on reverse engineering.

Of course, the newer-than-October-2001 MSDN libraries do not have the help files for the actual Visual C++ 6 development environment and/or compiler, if you are still using VC6, I would hope you don't need this documentation anymore.

I am curious why Microsoft did not include this integration ability (with the normal caveats) with the newer MSDN libraries, but I guess they sold a couple of extra copies of Studio .NET this way...

UPDATE: With this plugin enabled, I get a sharing violation on the .opt file if opening the project from explorer - a double-click or "Open With". Opening Visual Studio, then opening the workspace seems to not have this problem. Please let me know if you have similar problems.

More Setup Pet Peeves

Everywhere you look there are more setup pet peeves that keep popping up. Many of these new ones are in my top 20 list - some of them aren't.

Microsoft's JeffDav writes one about two installation issues - a 3rd party application and a Microsoft application. The second one was probably a MSI based installation, and I blame the MSI engine's design on this one - what ever happened to "Couldn't copy file from source media, retry" dialogs?

Raymond Chen chimed in with his own story, and the usual 2 billion responses to it - some of the catchy ones captured below.

Janus points out that several Java based apps have issues - write once, run anywhere (as long as there are no spaces in the path). Other commenters chimed in issues with *nix application ports having similar path issues. (My peeve #19).

Foxyshadis points out a few more: "are you sure you want to create the folder" AND "are you sure you want to install in an existing folder" - I don't get this one either (My peeve #10). "Once you install with custom options and later upgrade, and try to use typical, not only will it always forget which options you chose, it'll install into a completely new default folder." Why is that? This is a nice addition to my peeve #11.

Gryphonvere points out some applications "ask you rather forcefully to install some older version of DirectX" - some of this is the fault of the dependent application not providing a mechanism to determine the current version of itself, and some on the setup developer for not doing the smart thing and saying "This application was not tested with Acrobat Reader 12, if you have issues, try using Acrobat Reader 4.0." This is a corollary to my peeve's #17 and #13.

David Walker complains about the "Company Name\Product Name" default directory convention (My peeve #14). He also hits the "Common Files" directory issue. This latter point is somewhat valid, but for keeping the redistribution, duplicate files, and simplified patching for a company's product line shared components down to a minimum, I can live with that. We all have to understand that x-copy deployment of applications or product lines is not always possible. While on the subject (and expanding on my earlier peeve #20), my belief is that "Application Data" folders are underused. If I want to back up my system or use OS features such as roaming profiles, I want to have a one-stop method of doing so. Backing up the per-user application data folder, the per-system application data folder, and the "My documents" folders should be the only backup philosophy I ever have to use.

Doesn't anyone test the key features of an installation for both correctness and usability anymore?

Application Preloading at System Startup

Sometimes I wonder if we (as software developers) should have some form of a code of ethics, where violations can get you barred from writing software in the future. Mainly, this would apply to the spyware/malware developers (or perhaps the ethical violation is more directable to those who bundle the spyware).

If this ethical code existed, I would add a violation for any application that did not inform and offer a choice to the user at install time that some startup or background task will always be running. Some typical offenders are QuickTime, Real, Adobe, Microsoft Office, Microsoft Messenger, printer driver "status monitors", and more. These startup applications increase boot time and memory/pagefile requirements. Most of the time, I don't use these applications each time I boot the PC.

If the goal is to make your application start up faster (or appear to start up faster) there are ways of accomplishing this. Rebasing your DLL's, background/on demand loading of plugins, delay loading dependent DLL's, etc. are a few common tricks that can be used. The utility "Adobe Reader SpeedUp" accomplishes a magnificent improvement in load times, and this doesn't involve rewriting any of Adobe's code. If you wrote one of these startup applications anyway, at least offer the user the option at install time if they wish to use it.

Checking or Changing System Settings

Raymond Chen reminded me of a story I wanted to share. In non-MSI setups (and I am only using setups as an example of a larger problem in application programming), installing a service was a bit strange and usually flaky. Some installation engines would simply write the service registry keys directly into the "CurrentControlSet" section of the registry and require a reboot for the service to work. The reason was the Service Control Manager only looks at that portion of the registry when the machine is starting. Some engines decided to write values to the HKLM\System\ControlSet001 key - an even worse idea. Recall that "CurrentControlSet" does not really exist, it is mapped to the "real" ControlSet001 or ControlSet002 based on how the machine was booted. This is sort of like the HKEY_CLASSES_ROOT virtual key I blogged about before. If you need to query information about services, install them, etc. use the API's intended for this purpose - not the registry keys. Not only is this good advice for services, but in general. If you are using a registry key to check or change a setting, check for an API to set/check for the setting first. This generally isolates you from potential incompatibilities across future OS versions.

Raymond's post relates to User Interface settings, and describes an application that crashed under Windows 2000 because of the reliance on registry keys and not API's. Rephrasing my earlier point - if there is an API that reads or writes registry key data, it should be considered "Private".

One commenter to Raymond's post responded "sometimes its extremely hard to find the right api, with so many apis hanging around" - and he is 100% correct. This is where having experienced people around your development shop helps. If you don't have the former, this is a case where reading portions of the MSDN library (and blogs like Raymond's and Larry's) helps. If you are short a photographic memory, you won't retain everything - but you may remember reading something in the past and a few keywords that you can Google for later. Microsoft can help programmers avoid this trap somewhat by adding the keys that are read from or changed by API's in the MSDN documentation with a disclaimer - "The following key stores data related to this API but should not be relied upon as an implementation detail in future OS releases."

Sometimes it is hard to follow these "rules." Take for instance the Distributed Transaction Coordinator, or DTC for short. If you wanted to get or change any particular setting related to DTC you can't do it the same way across OS versions. In Windows 2003, there is the IDtcNetworkAccessConfig interface you can use. To change the same settings on Windows XP, the registry appears the only option. Furthermore, the upcoming Windows 2003 SP1 DTC changes (which mirror the XP SP2 changes) has not updated the API to reflect the change (at least in the SP1 RC2 version of the SDK documentation). Specifically, there is no updated method of allowing or disallowing specific transaction permissions such as inbound or outbound, so the API is useless - back to registry keys! Checking the DTC authentication level never had an API - just some registry keys documented in a KB article. I hope they fix this oversight for the final SP1 release - but in the meantime, what is a developer expected to do?