My .02. Having an init function that is required to be called outside of the constructor is only useful in three situations 1 - When you have multiple constructors that all perform a set of common steps in addition to the custom steps that require different constructors. Moving the common steps to an init() function and calling it from the constructor makes for more modular code. 2 - When you are designing a class at the base of a class hierarchy that will need custom initialization before it can be used. Making init virtual and _NOT_ calling it from the constructor will perform the custom initialization. (Calling init from the base class in a constructor is BASE::init and not DERIVED::init). This can usually be done in a different manner. 3 - The class manages an expensive resource (or requires additional function calls to set parameters - username/password), and can't/shouldn't be ready for use on initialization. Usually the expensive resource scenario involves not a call to init(), but a call to open() or something similar. The username/password is similar, but I've seen always open socket designs that require authentication, but in those cases the init took the credentials. Regardless of what any book says I think that calling Some_Type * c = new SomeType(); c->init(); // Use some type here c->cleanup(); delete c; Is unnecessary, creates more of an opportunity to screw up, and ultimately just involves a wasted function call. In general if you have two steps that should always follow each other with nothing in between, they should be encapsulated to make sure that you always do so. Not doing so does not add any appreciable benefit. Debugging should be easier b/c everything is properly initialized, rather than it being seperated out.

When MS releases a replacement spec for the PE file specification (which all "native" apps and dlls are) and they move the system dlls, the kernel and the loader to this new specification I think that native apps are safe. Even then, there is no reason why c/c++ couldn't be compiled to a different spec. On linux it compiles to the ELF spec.

At one point I did some work on the WiX project and spoke at length with Rob Mensching. I'm *far* from an expert, and it's been about 8 months since I've even looked at install code so I doubt I could answer too many questions. IMHO, WiX is your best option if you want to use MSI. The thing that I liked most about it is that it's XML based. It does not (at least not the last time I checked) provide a way to automatically generate an installer for you. I know that there was work proposed for that. A little more on WiX, it was pioneered by Rob Mensching. Rob Mensching wrote ORCA (MSI Database Viewer) and has worked on the Office install team. I *believe* that he has said that WiX is used by the Office install team currently, if not I know that he has stated that there are many teams inside of MS that do use it. As far as scalability, it is just as scalable as MSI is. Visual Studio install projects are supposed to be notoriously bad, I've never used one so this is hearsay. They particularly fail when doing upgrades and often leave you launching ORCA to accomplish what you want. At my prior job I was presented with the fact that we needed a new installer. The one we had was based on NSIS (an older version). I evaluated many options, including InstallShield (too pricey), InnoSetup (not enough control on what it output), creating by hand (........), etc. In the end I decided that because of the fluidity of our installer I wanted something that would build from XML. I was about to write a bunch of scripts to accomplish this when I found WiX. I wrote some fairly complex installers that looked great and still think that after working with it that WiX was the best option.