It's now official, the conference that had been hinted at last month will be on May 15-16th at the Sydney Hilton Hotel.

Now to wait and see if there's enough "technical" content to make it worth me attending.

My blog feed has been available through FeedBurner for a long time, but I've now changed the blog template so that it publicises the FeedBurner feed directly.

If you've subscribed to my feed, first of all "Thanks!"

I'd encourage you to update the URL to point to the new feed source. That way if anything changes in the future, you won't need to worry - it should all just continue to work.

Subscribe to Dave's Daydreams

I'm preparing to re-install my workstation and go from Vista RC2 to the RTM version, now that we've got access to the volume license versions. As they are only "Upgrade" versions, I'm planning to try this workaround to achieve a clean install without having to install XP first.

When I installed RC2, I didn't re-partition the disk - I just left it as one big C: drive. This has now come back to haunt me, as it means in order to to a clean install of the new OS, I've got to move everything that I want to keep onto an external disk, and then copy it all back when the new OS is up and running. Previous machines have always had two drives, so didn't used to be such a problem.

I've created a batch file to run robocopy.exe (which is actually included in Vista now), so I can select which folders I want to backup to the external disk.

That all worked fine until I pointed robocopy at my profile folder.

Your profile is located in %USERPROFILE% in case you were wondering - on a clean install of Vista, that maps to a folder under C:\Users. The old "C:\Documents and Settings" as used by XP is still there, but it redirects to the new folder.

This is related to where things went wrong. The way Vista does the redirect is by using Junction Points - they're kind of like symbolic links in Unix. The trouble is that Junction Points are also used inside your profile folder to redirect from the old name (eg. "Application Data" to the new name "AppData").

I wondered why robocopy was taking so long, and then looked at what it was doing - it seemed to be copying the same files over and over again - and then I realised that's exactly what it was doing - it was stuck in a recursive loop because it kept hitting a junction point that took it one directory deeper each time. Eek!

So I stopped the batch file, but now I needed to remove the mess on the external disk. This handy batch file did the trick - curiously it also relies on robocopy to remove a directory heirarchy that suffers from "the path is too long" errors.

I'm now using an extra argument "/xj" with robocopy to tell it to ignore junction points and it should all be fine.

robocopy c:\users\username e:\users\username /mir /r:0 /xj

There's a few sample scripts around to list the installed applications using WMI. The trap on 64-bit platforms is that the 32-bit and 64-bit installation information is stored in different places in the registry, and you need to be clever about telling WMI that you want the 32-bit data instead of the 64-bit.

Here's some VBScript that will list first the 32-bit and then 64-bit installed applications:

strComputer = "."
Const HKLM = &h80000002
Set objCtx = CreateObject("WbemScripting.SWbemNamedValueSet")
objCtx.Add "__ProviderArchitecture", 32
objCtx.Add "__RequiredArchitecture", TRUE
Set objLocator = CreateObject("Wbemscripting.SWbemLocator")
Set objServices = objLocator.ConnectServer("","root\default","","",,,,objCtx)
Set objStdRegProv = objServices.Get("StdRegProv") 
WScript.Echo "32-bit Applications"
WScript.echo "-------------------" 
Call GetApplications 
objCtx.Add "__ProviderArchitecture", 64
objCtx.Add "__RequiredArchitecture", TRUE
Set objLocator = CreateObject("Wbemscripting.SWbemLocator")
Set objServices = objLocator.ConnectServer("","root\default","","",,,,objCtx)
Set objStdRegProv = objServices.Get("StdRegProv") 
WScript.Echo "64-bit Applications"
WScript.echo "-------------------" 
Call GetApplications 
Sub GetApplications 
' Use ExecMethod to call the GetStringValue method
Set Inparams = objStdRegProv.Methods_("EnumKey").Inparameters
Inparams.Hdefkey = HKLM
Inparams.Ssubkeyname = "Software\Microsoft\Windows\CurrentVersion\Uninstall\" 
set Outparams = objStdRegProv.ExecMethod_("EnumKey", Inparams,,objCtx) 
For Each strSubKey In Outparams.snames 
Set Inparams = objStdRegProv.Methods_("GetStringValue").Inparameters
Inparams.Hdefkey = HKLM
Inparams.Ssubkeyname = "Software\Microsoft\Windows\CurrentVersion\Uninstall\" & strSubKey
Inparams.Svaluename = "DisplayName"
set Outparams = objStdRegProv.ExecMethod_("GetStringValue", Inparams,,objCtx) 
if ("" & Outparams.sValue) = "" then
'wscript.echo strSubKey
Else
wscript.echo Outparams.SValue
End iF 
'Inparams.Svaluename = "QuietDisplayName"
'set Outparams = objStdRegProv.ExecMethod_("GetStringValue", Inparams,,objCtx)
'wscript.echo Outparams.SValue 
Next 
End Sub

Vista got released in November last year, and I've now come across the first "big" application that doesn't currently run on Vista.

Oracle will support Windows Vista but most likely not completely until the second half of 2007!

I would have thought a company the size of Oracle could dedicate a few resources to running their stuff on the beta releases of Vista, so that it wouldn't be such a big step to get it all working.

At least I don't do much Oracle stuff, but it does happen occasionally (like today), where it is a problem.