HANDS-ON - Windows nt - Silver service

I am sure that many of you will remember how dreadfully long it was between reading about Service Pack 4 in these pages and its actual appearance. By now, you may well already have heard that Service Pack 5 is in beta test - it has been reported in various news services. But this time we shouldn't have to wait quite so long for the released version.

Microsoft has changed its policy and, instead of waiting to squeeze in every last possible update and improvement before releasing a service pack, is moving to a model of much faster releases. Service packs now have their own dedicated team at Microsoft so it's no longer a case of having to force Windows 2000 developers to grudgingly spare some time.

And, hopefully, we will hear rather less of the 'we can't be bothered to fix that for NT 4 - wait until Windows 2000' attitude that had prevailed.

In fact, I'm pleased to note that one bug I reported appears to have been fixed in SP5 (Fig 1).

One of the drawbacks of many of the protocols in use on the internet is that they are frequently not catered for as standard, by firewalls.

H.323 video conferencing protocols are an example but another is Microsoft's own DCOM (distributed COM) client/server communication.

In the world of H.323, certain vendors have addressed the problem by tunnelling H.323 communications through HTTP because this protocol is always going to cross firewalls successfully. With Service Pack 5, it is expected that Microsoft will introduce DCOM/HTTP tunnelling, to allow DCOM client/server communications to perform the same trick and cross firewalls using the HTTP protocol port (port 80).

Some of the other changes are fairly obscure and relate primarily to Windows NT in the role of a router. Also, WINS, DNS and DHCP each receive a number of fixes and 'quality improvements'. There are a number of updates to the Option Pack and, if you subsequently install it, you should re-install Service Pack 5. Similarly, if you install Microsoft Routing and Remote Access Service (RRAS) after Service Pack 5, then a re-install of SP5 is necessary.

- Corruption concerns

A few readers have been concerned at the following message appearing after rebooting a Windows NT system. As far as they know, they had never seen it before installing Service Pack 4: 'WARNING! Your drive may be corrupt. Please let AUTOCHK run. Skipping AUTOCHK on a volume may lead to an unmountable volume. Skipping AUTOCHK on a system drive may lead to an unusable system. AUTOCHK resumed.'

Although there is a program called AUTOCHK.EXE, this is really just CHKDSK in a different guise.

AUTOCHK has to run at such an early stage of the boot sequence that it is unable to take advantage of a whole pile of Win32 services, so it is a separately-compiled version to run in these conditions.

The warning message is clear, and it sounds as if one really ought to be patient, and wait for CHKDSK to complete. But there's a problem. This message only appears if the system was shut down unexpectedly. If that is the case, you probably want to get it back up again as quickly as possible, but CHKDSK can take literally hours to run on very large, full disks - it can actually take several days in some circumstances. It is therefore very tempting to skip AUTOCHK (Fig 2).

With Service Pack 4 two new options, /C and /I, have been added to CHKDSK.

The /C switch will skip cycle checking (self-referential sub-directories) but only speeds up CHKDSK by one or two percent. Fortunately the /I switch, which skips the comparison of directory entries with file record segments in the master file table, makes a much bigger difference - it reduces the time for CHKDSK to run by as much as 50 to 70 percent. Both of these switches could potentially leave some corruption, such as orphaned files, and files which appear to exist but can't be accessed. Happily, though, they will remove all corruption which affects the integrity of the file system in such a way that corruption could snowball.

So, in an emergency, you could skip the startup AUTOCHK, and then run an abbreviated CHKDSK using the /C and /I switches. But whenever you run CHKDSK, and errors are detected, some corruption may remain - files which cannot be accessed, or data that is itself corrupt. For any system where the data is important, you should always protect it with backups or some other mechanism.

Please note that all of the above applies only to NTFS volumes.

- Open with Notepad

In the April column, I suggested a means whereby right-clicking unknown file types would offer an Open With Notepad option on the shortcut menu.

This method doesn't work for known file types but reader Paul Kane has written to me with one of the methods that will work with these.

- Create a file NOTEPAD.REG with the following content:

REGEDIT4

(HKEY_CLASSES_ROOT/*/shell/d

Notepad)

@="Open with Notepad"

(HKEY_CLASSES_ROOT/*/shell/d

Notepad/command)

@="notepad.exe %1"

(Key: d code string continues)

Then, double-click NOTEPAD.REG in the Explorer to import these new keys into the registry. Thereafter, Open with Notepad should appear as the first item on the shortcut menu, whatever file type you click on (Fig 3).

In case you didn't see the April issue, the whole point of the above is to make it quick and easy, from within the Windows NT Explorer, to open files of any type in Notepad for viewing and/or editing.

However, what I more often want to do is email someone a file from within the Explorer window. Normally, you have to find the Send To menu item and select Mail Recipient. But by following a similar technique that above, you can have it always appearing as the first item on the first shortcut menu.

- The registry changes you'll need to put in a file called MAIL.REG are:

REGEDIT4

(HKEY_CLASSES_ROOT/*/shell/Mail)

@="Send to Mail Recipient"

(HKEY_CLASSES_ROOT/*/shell/d

Notepad/command)

@=""D:/Program Files/Microsoftd

Office/Office/OUTLOOK.EXE"d

/c ipm.note /a "%1""

(Key: d code string continues)

A new mail message window will appear with the file as an attachment.

Of course, this will only work with Outlook, whereas the Send To Mail Recipient menu item will work with whatever is the registered mail client (Fig 4).

Remember, although you can change the registry manually and get the same effect, if you put these items in a file then if you ever need to reinstall NT, or set up a new machine, tuning the registry to suit your requirements is simply a matter of clicking on that file.

- Forcing numlock

Reader James Townsend asks whether it's possible to force numlock to come on when the system boots up. Well, it is something which has irritated me for years so I was pleased that James spurred me on to doing something about it. The answer is not straightforward, though. What you can do is to force the numlock state to be retained after a reboot. So, as long as you never turn it off you'll be OK.

Another snag is that this works on a per-user basis and doesn't kick in until you actually log on, although if you set the state for the default user, then it will be set prior to logon.

- Here's what you do: in the registry, go and find either HKEY_CURRENT_USER/Control Panel/Keyboard, or HKEY_USERS/.DEFAULT/Control Panel/Keyboard, according to whether you want to set the state for just one user or the whole machine. Change the data for the value InitialKeyboardIndicators from 0 to 2. Ensure that you actually turn numlock on, then reboot, and the state will be preserved.

- James also asks whether changing PowerdownAfterShutdown from 0 to 1 in HKEY_LOCAL_MACHINE/ SOFTWARE/Microsoft/Windows NT/CurrentVersion/Winlogon can be expected to work? The answer this time is no - unless you have been provided with NT-specific utilities by your hardware manufacturer. For instance, Toshiba provides the appropriate additional software to work with some of its laptops.

- Registry editing - a necessary evil

As we all know, and many of you keep reminding me, registry editing is something that you should avoid at all costs - and if you have to do it at all, it is probably best done via a .REG file rather than by directly manipulating keys, values and data using either regedit or regedt32.

In the real world, however, many of us will spend a significant part of our working lives with regedit on the screen in front of us, navigating clumsily through the keys to, in many cases, the same old places over and over again. Wouldn't it be nice to have a drop-down list of places you've been, so you can easily return there? Although regedit allows you to copy a key, there's nowhere to paste it in. So, even if you come across a key name that you can cut from an internet document or email message, you still have to navigate to it manually.

This is where RegEditX, or Registry Editor Extensions, from DC Software Design, comes in handy (Fig 5). With RegEditX you get a new drop-down list box for the registry editor, rather like the one in the Windows NT Explorer.

RegEditX is available for download from www.dcsoft.com/ prod01.htm, and what's more, it's freeware.

Being lazy, I dislike having to leave my seat to walk across the room to make changes to the server's registry - a frequent necessity when attempting to get NDS for NT working (Fig 6). Although Hyena will carry out just about every other administrative task you could possibly want over the network - including restarting the server - the one thing it will not do is provide the ability to remotely edit the registry. Into this breach steps another registry utility, RegWeb 1.0 from ProStream. As the name suggests, it uses web technology to provide remote registry editing capabilities.

You need IIS 2.0, or the personal web server, to be running on the machine whose registry you want to edit, and a frames-capable browser on the client PC.

You can do pretty much everything using RegWeb that you can from the registry editor itself. There are only a few minor restrictions: you can neither add nor update binary data, and DWORDS are restricted to positive numbers less than four billion.

RegWeb can be downloaded from www.prostream.com/regweb.htm. You may want to consider rather carefully before installing it on any production systems attached to a network. I would suggest that it is really only safe to use in a development and test environment.

You will find information on other useful registry tools on Microsoft's web site at the following URL: www.microsoft .com/ntserver/nts/exec/vendors/freeshare/Maintnce.asp#registry.

- Now you see me ...

Reader David England is concerned that a supplier is trying to sell his organisation full Intel video conferencing for NT, whereas they would be happy with the cheaper cameras and CU-SeeMe. He wants to know whether there is any reason why normal video cameras shouldn't work with NT.

Really, there are several issues here. Firstly, any PC-based video conferencing is, in general, an unsatisfactory experience. Users I have interviewed, who have it, say that they turn off the video once they have checked to see what tie everyone is wearing today, and then get on with the real business!

Certainly, video does have its place. But if you really need it - for instance, to show ceramic defects to the world's expert on the other side of the globe - you probably need a reasonable system, and the supplier does have a point. But in my book, a reasonable system is a proper dedicated appliance.

However, as with anything else, you need to establish a business need, define some objectives and then find a system to match. A PC-based system may be just the ticket for your application. And, as for the cheaper alternatives, software such as VocalTec Internet Phone, CU-SeeMe and Microsoft NetMeeting all work under NT quite happily.

Cameras though, are a different issue. By far the easiest cameras to use are USB devices, but of course, USB is not supported under NT. Certainly, there are plenty of cheap cameras that do work under NT - even some of the really low-end parallel port versions - but you may have to hunt around.

By no means take your supplier's word for it. Double-check directly with the manufacturer (on the organisation's web site is usually the easiest way). For instance, the Intel Create & Share Camera Pack I have sitting here, still boxed, is destined to stay that way forever. The Intel web site gleefully informs me that 'Intel Create & Share 1.0 PCI version supports Windows 95 B (OSR2) and Windows 98. Windows NT is not supported'.

PCW CONTACTS

Andrew Ward welcomes your comments on the Windows NT column. He can be contacted via the PCW editorial office (address, p10) or email NT@pcw.co.uk

- Useful registry tools at www.microsoft .com/ntserver/nts/exec/vendors/freeshare

/Maintnce.asp#registry

- RegEditX www.dcsoft.com/ prod01.htm

- RegWeb www.prostream.com/regweb.htm.