After 2 weeks of constant distractions ranging from security updates, through a couple of major OGRE issue reports that needed investigation, and learning how VS2005’s release affects us, I finally managed to spend some time on Kadath today. Most of that time was spent with a pencil and paper, chewing the former in between trying to draw something sensible on the latter. Basically I was planning how I take what I have now, and perform yet more automated magic to turn it into something more useful.
After some initial double-takes and discomfort over some of the things that were changed in VS 2005, I’ve become convinced enough of the benefits of the new version to cough up for the Professional upgrade. The free Express edition is an extremely good deal, but there are definitely things that I miss from the Pro version of Visual Studio, and given that I spend a very large part of my time indeed in this environment it’s worth spending the money.
Well, I’ve learned enough about WiX and MSI to get an installer ready for the XSI v5 exporter, which will accompany OGRE v1.0.6 in just over a week’s time. Getting it working didn’t actually take very long, although sometimes the declarative syntax can be a little obtuse. The thing that had be pulling hair out for a good while was that I wanted to auto-locate the XSI install folder so the user didn’t have to choose it.
I managed to build a working version of the OGRE XSI exporter for XSI v5.0 using VC.Net 2005 Express today, which is excellent. I had a problem at first because I had all sorts of linker errors with XSI::CString, but it turns out it’s because one of the changes in VC.Net 2005 is that wchar_t is a built-in type, and you can’t link against older libs which aren’t using that option and wide characters (XSI uses wide characters and is built with VC 7.
Ok, so I’ve been looking quickly for free tools for creating MSI files, since deploying the dependent Visual C++ runtime libraries as Merge Modules is the only really supported way of deploying applications built with VC8 on all versions of Windows. The 2 main contenders are MakeMSI and WIX. I haven’t had lots of time to investigate them but here’s my initial assessment. MakeMSI MakeMSI purports to automate the process to some degree, although you are still manually editing text files.
I’m sure you’ve already read about how Sony has effectively turned hacker by installing a rootkit on your PC just because you wanted to listen to some music that you paid them for. That’s customer service for you. Sony’s little tyke of a copyright protection device (developed presumably by a bunch of monkeys at First4Internet who just wanted Sony’s cash and didn’t realise they were doing something really, really dumb) likes to squeeze itself deep into your Windows system calls, intercepting everything you try to do with your CD drive, before sneakily trying to hide itself, cackling manically all the while and rubbing it’s hands with glee.
Ok, after further investigation the origin of the .Net 2.0 dependency on binaries created with VC8 Express is becoming clearer. The major change that has occurred in VC8 is that the core C/C++ runtime libraries and standard libraries like STL, MFC, ATL etc are now configured as ‘side-by-side native assemblies’ rather than the usual simple native DLLs. The point of this is to allow version control over shared libraries so that different applications don’t mess each other up by overwriting shared DLLs.
Well, the OGRE community has been taking it’s first look at VC8 (2005) Express Edition, which on the face of it seems like quite an incredible deal - a free copy of a great IDE with an optimising compiler and all the tools you need to make most native applications with C++ (among other things, but that’s what we’re most interested in). Besides a few minor missing features, such as a resource editor, 64-bit support and profile-specific optimisations, this seemed like the perfect tool for a budding native application writer.
I’ve been catching up on a few of my TODO items, one of which is addressing a few remaining stability issues with the OGRE DirectX7 render system, a plugin which allows you to run OGRE on older computers running Win98 (which can’t run DirectX9) and with perhaps pretty dodgy drivers. It’s not been a priority for a while, since to attract new users it’s generally the newer tech that interests people, but at the same time having a solid solution for older computers makes it more useful for those targetting the shareware market.
Well, I spent the whole of this evening testing security updates to various bits of software that the OGRE website uses and applying them rather carefully to the real thing. I intend to script a sync from the main site to my local copy on a regular basis (I already transfer database dumps) so it’ll take less time to get the test setup running in future. Once again my tiny multi-purpose Gentoo box bore the brunt of the work, being as it is a mail server, database server, proxy server, web server, file server, router, OGRE release builder and probably a few other things too (it used to be a print server until I got my standalone wireless printer earlier in the year).