Category: Blog

Some versions of Windows Vista comes with Volume Shadow Copy, a souped up version of the system restore function of Windows XP. Now, not only registry and core files are restored but any file on a protected drive can be restored to an earlier point in time.

If this feature is enabled on a drive, Windows Vista sets aside a significant amount of disk space to keep the old copies. Supposedly this space can be reclaimed by using the Disk Cleanup feature. I had partitioned my hard drive and installed Windows Vista. When reinstalling Windows Vista I only reformatted my system drive and later noticed that a large amount of disk space was not accounted for when adding the sizes of all folders on the drive.

It turned out that Volume Shadow Copy was not enabled on my data drive after the reinstallation, but the data was kept from the previous installation and just wouldn't go away. To see the shadow storage I opened a console as administrator and typed 'vssadmin list shadowstorage'. I enabled Volume Shadow Copy on the data drive and ran the Disk Cleanup, before I disabled Volume Shadow Copy. No luck.

From what I have been able to tell, the Disk Cleanup feature does not work in this case. When I did the same thing but instead of the Disk Cleanup function issued the following command (still in the administrator console) it worked:

vssadmin resize shadowstorage /For=D: /On=D: /MaxSize=300MB

By default, Windows Vista, like all previous versions, insists on saving user data on the same disk as the system files. This may be fine for many people but I really don't want it to work that way. Before Windows Vista, you could edit the registry to move the folders around. Now in Windows Vista, Microsoft has added support to move the folders directly from within the file explorer which, in theory, should simplify matters. However, it doesn't always work and many applications fail to save in the new location. What is even worse, it appears to be impossible to change the location of the public folders from the GUI – even though the text in the GUI states that it is possible.

Realising that doing the changes via the GUI was totally worthless I tried to find another way. What worked very well for me was to change the two keys ProfilesDirectory and Public under HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ ProfileList.

The change to the key Public affects all users in the system whereas changing the key ProfilesDirectory only affects accounts that are created (or rather when the user first logs on) after the change was made. I recommend you create an Admin user at the end of the Windows Vista installation process, make the changes to the registry and then add normal accounts for the users who will use the system.

As always, be very careful when changing the registry as a mistake could potentially wreck your system.

For years I have been annoyed by the fact that Microsoft Outlook insists on capitalising the letter 'i' when I write email. In Swedish 'i' means 'in' and is not to be capitalised like the pronoun 'I' in English. It was not exactly apparent how to stop this AutoCorrect (bad name in this case) feature.

For me, the 'bug' didn't manifest itself all the time but only when I wrote mail in plain text.

One would assume that application wide options for Outlook could control this behaviour. I could uncheck the 'Replace text as you type' option but that removed all corrections which was not what I wanted.

It turns out that the way to change the behaviour is to change the AutoCorrect options from within a plain text email (i.e. not from the main Outlook window). Just remove the i/I pair from the list of corrections. After that, 'i' will not be changed to 'I' in future emails.

If you have tried to write ATL based smart device applications under Visual Studio 2005 on a computer running IE7 you may have seen this error message. This error is due to changes in IE7. Apparently the upcoming service pack for Visual Studio 2005 (scheduled for Q3 2006) will fix this issue but until that happens, this is how to do it.

Run regedit.exe and add an empty key under HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Ext \ PreApproved. Name the new key “{D245F352-3F45-4516-B1E6-04608DA126CC}”. Then restart Visual Studio.

You may also use the attached file.

Attachments

• VS_WM_IE7_Fix.zip

I found Windows Services for Unix by chance but has since got used to having a Unix-like environment on my Windows system, enabling me to more easily work with boxes running Linux.

If you have installed Windows Services for Unix (for a description of how to do it, please read this article) you might have realised that there are only so much you can do with the system out of the box. Many commands you take for granted in a Linux system are not there and some of those which are actually included don't behave quite the way you expect them to function.

Not to worry. The source code for most commands can be downloaded (www.gnu.org is a prime source) and compiled within SFU.

To save you the time to set up an environment with some tools that at least I found more or less necessary I provide a link to a set of scripts at the bottom of this post. The scripts automate the process of building the system by downloading and compiling the following applications:

• bash
• bzip2
• freeradius
• gawk
• grep
• lynx
• make
• nano
• openssh
• openssl
• tar
• wget
• which
• whois
• zlib

To install, download the file below to a directory within your SFU installation (e.g. /tmp, normally c:\sfu\tmp from your Windows Explorer), then type the following from a C Shell window:

gunzip SfuPlus.tar.gz
tar -xvf SfuPlus.tar
cd SFU_Plus
./sfuplus.sh

The build process will take about 15 minutes on a modern computer. Slower computers may take more than an hour.

Attachments

• SfuPlus.tar_.gz

Microsoft Windows Services for Unix (or SFU for short) is a relatively unknown product. This is a shame since it can be quite handy for some people. And the price is definately right – free!

Contrary to other applications (e.g. cygwin) that attempt to provide a Unix/Linux envrionment under Windows, SFU is not an emulator running under Windows. Instead SFU provides a Posix subsystem that runs side by side with Win32 directly on top of the NT kernel. This should provide for better performance but I have not tested that myself. What I have found very nice, however, is that commands compiled and existing under SFU can be executed under Win32 anv vice versa.

Windows Services for Unix comes with a basic set of tools. Some of them are crippled in comparison with what you might be used to. In a separate post I will provide my setup script that adds a number of utilities (nano, wget, openssl, openssh etc) to the default setup.

To get started you need to download SFU from Microsoft and run the setup file. To help you I provide screenshots of all the steps necessary to set up SFU on your computer.