James Wiseman

Periodically, I see the following sort of email being broadcast across the department:

Can you please log out of [Some Machine]. I need to restart [SomeService]

Once sent, some kind individual will log out and send an email confirming this. The original correspondent will then log onto the machine and perform the necessary actions before logging out, emailing the original user, who will then log back in.

Hassle, right?

Happily there is a simple shortcut from the service control manager on your local PC.

1. Simply open this up from the control panel (or typing ‘services.msc’ into the ‘run’ dialog available from the start menu).

When it has loaded, if you look at both panes you will see the text ‘Services(local)’.

2. Click on the ‘Services(local)’ item in the list in the left pane and then click ‘Action’ from the main menu (the options in this menu change depending on what you have selected) then click ‘Connect to another computer’.

3. Type in the name of the computer you would like to connect to.

4. Restart the services as you would have done:

This facility isn’t just limited to the service control manager. The following tools/services also allow you to connect remotely in some way:

• Component Services
• Computer Management
• Event Viewer
• Registry Editor

So next time you want to log onto a box, why not consider whether or not you really need to, and instead use the method above?

Short and sweet and to the point. No graphics and no-nonsense.

• Control Panel -> Programs and Features -> ”Turn Windows Features On Or Of”

(Command line option: Or type “OptionalFeatures.exe” in the Start-Menu (Windows button) ‘Start search’ box to achieve the same effect)

• Check “Internet Information Services”
• Wait. (It could well take a few minutes – the last time I did it, it took over 20! – you might think nothing is happening).

Job done!

Most people who have had any cause to edit registry settings on a regular basis will probably be familiar with the registry file (.reg) file convention:

[HKEY_LOCAL_MACHINE\Software\Test]
“TestValue“=”SomeValue”
“TestValue2“=”Some Other Value“

When you double-click the registry file from Windows Explorer, the registry settings are applied quote effortlessly.

I recently found out, however that its possible to delete registry settings in the same way by a cunning placement of the hyphen character (-).

To delete a value, use the following:

[HKEY_LOCAL_MACHINE\Software\Test]
“TestValue“=-

(Note the hyphen after the equals sign.)

To delete a whole key, use the following:

[-HKEY_LOCAL_MACHINE\Software\Test]

This time we put the hyphen in front of the key name.

Read more here, (including the disclaimer on the inherent risks of registry editing): http://support.microsoft.com/kb/310516

I recently encountered a problem in getting 32-bit Windows COM components running on a 64-Bit Windows server. This surrounded the reading of registry entries and COM registration.

As it turns out, running in a .reg registry file, or registering a COM component on the server will invoke the default programs associated with these operations, namely, regedit.exe and regsvr32.exe. These default programs are filed under c:\Windows\system32. Nothing new, right? Wrong!

Do not be mislead by c:\windows\system32. On a 64-bit machine c:\windows\system32 contains 64-bit versions of regsvr32.exe and regedit.exe. The 32-bit versions that you want are in c:\windows\syswow64.

Sorry, let’s just clarify. The 32-bit versions are in the folder with ’64′ in the name, and the 64-bit versions are in the folder with ’32′ in the name.

Err. Ok. Just to be clear, I meant that, and as we would expect, 64-bit Windows defaults to to the 64-bit versions of these components.

So why call it System32? Well, I think a lot of legacy apps have this (ill-advisedly) hard-coded. Microsoft state that “64-bit system files are in the \Windows\system32 directory for compatibility reasons.” Wikipedia says much the same thing as well.

So what’s the difference? Well, these two programs basically add information to the registry; but we have two different ‘Views’ upon the registry,  predictably a 32-bit view, and 64-bit view. In the background these are just separate branches of a wider registry tree that is hidden from us.

So what of WOW64? Well, this stands for “Windows-On-Windows 64-Bit Emulation Environment”. In this instance, the ’64′ means that we are emulating Windows 32 bit on a 64 bit environment. Maybe a better name would have been W32OW64, but that’s harder to say than “WOW-Sixty-Four.”

When you run a 32-bit component on 64 bit Windows, it automatically runs in the WOW64 Emulation Environment. This isn’t clearly stated in the documentation; when I started out I was looking for a way to get the component to run in this environment before I suddenly realised it already was!

The component will access the 32-bit view of the registry, so as long as you have registered things correctly, you will be ok.

Microsoft has made available a page on Running 32 Bit Applications on a 64-Bit server. In addition this, there is a document outlining best practice guidelines for WOW64.

There’s more reading in the above on maximum addressable memory and such-like, but I’ll leave that to you.