Two noteworthy Second Life newsitems, today.
Firstly, IBM and Sears are partnering on a new build on the IBM island complex. The idea is to allow customers to explore the Sears product range in a more immersive environment than is currently possible with an online store. Mike Rowe gave an interview about the Sears build to 3pointD, and it is worth reading.
Secondly… a little snippet… the Second Life client has been released as an open source project! This is extremely cool. Hopefully it puts an end to the need to play around with libsecondlife – it will be interesting to see how that project goes forward now. Actually I’d only just posted about libSL to eightbar, when Roo posted the news about the full client – which kind of negates my post…
Lots of coverage, including Reuters actually referring readers to eightbar; and IBM’s Irving Wladawsky-Berger being quoted by Fortune.
Things I’d like to see:
I’m really looking forward to seeing how this all develops.
Technorati tags: eightbar, Second Life, open source, Linden Lab, Sears, libsecondlife, IBM, Irving Wladawsky-Berger
I’ve been having trouble getting Mugshot to pick up what I was playing in iTunes. The Music Radar just wouldn’t pick up anything from iTunes. I’m running iTunes 7.0.2. I’d usually play music via Windows Media Player, but Mugshot doesn’t currently support that; therefore, iTunes it is.
Looking at the code in client\windows\HippoUI\iTunesMonitor.cpp, I saw this:
#import <libid:9E93C96F-CF0D-43F6-8BA8-B807A3370712> named_guids raw_dispinterfaces
So, the code tries to register for use of the iTunes COM interfaces. Unfortunately, searching through the Windows registry, I couldn’t find any sign of that GUID. I also took a look at all of the type libraries that the system did know about, using the free Type Library Viewer from iTripoli. I couldn’t find any sign of the iTunes type library, although I could see an iTunes admin library and an iTunes Outlook addin.
You can usually register DLLs with regsvr32. Unfortunately, the iTunesApp class is in the main iTunes type library, which is represented by iTunes.exe. You can’t register an exe with regsvr32. I could have created the registry entries by hand, but that seemed like a fragile way of fixing things.
To resolve the problem, I re-ran the iTunes installer and chose the “repair” option. Once I’d done that, the correct registry entries were created and the iTunes type library was usable. Mugshot now advertises what I’m listening to, if I have iTunes running 🙂
It has been a while since I did any significant development for the Windows platform, either using the Win32 API or any of the tools. Once upon a time (about six years ago) I used to port utilities from HP-UX to Windows, and write Windows installers. These days, whenever I have to look at any Windows code, I tend to gingerly prod at it using Bloodshed Dev C++, or the SharpDevelop IDE.
Recently I was trying to work out why the Mugshot client was crashing, and needed to look at the debugging tools available. Disclaimer – I’m no expert here, this post just represents “some stuff I’ve learned lately”.
When an application crashes on Windows XP, sometimes you get an error along the lines of “there was a problem with xxx and it needs to close”. Something like this:
If you click for more information, you can then get more technical details:
Unfortunately, you can’t cut-and-paste the contents of the details window into a text file.
When the error dialog is on the screen – before you close it – if you look in C:\Documents and Settings\<your user>\Local Settings\Temp you should find two files – a xxxx_appcompat.txt file (which will be named in the Error Report Contents window… 9982_appcompat.txt in the example above), and a yyyyyyy.dmp file. I don’t know what the pattern is for naming these – the numbers seem to differ, and I can’t see that they have any relation to e.g. the PID, so I assume they are random. The two files seem to get deleted when you close the dialog, so if you want to try to get more debug information, copy and paste them somewhere else.
The appcompat file contains some information about the libraries that were loaded to support the running process. The .dmp file seems to be similar to a core file on UNIX – a dump of the process.
There are several ways to look at the dump file:
- dumpchk: this is available by default in Windows XP. If you run dumpchk <dmp-file>, it will print out some more information about the loaded modules and threads. Basic, but may be useful.
- windbg: this is available as part of the free Debugging Tools for Windows package from Microsoft. It is a graphical tool that you can use to open the .dmp file. If there is any useful information in the dump, you can enter .excr in the debugger and it will take you to the exception; !analyze -show will show you the error; and lm will list out the loaded modules.
- kd: this is the command-line equivalent of windbg. Run it with -z <dmp-file> to get into the debugger.
That’s a really brief summary. Check out the MS Knowledge Base article on debugging for more details.