Get to your Windows desktop faster – secure automatic logon.
The common advice for automatically locking the computer after logging in is to create a batch file and add it to the startup folder. Unfortunately the experience isn’t very elegant, or secure. The desktop and shell will appear while applications are loading, long before the computer will lock itself. The possibility exists for someone to tamper with the computer while it is in this intermediate loading state.
A solution to this problem is to lock the computer sooner in the logon process. There are several good places within the logon process to put a task, but the one that may execute the soonest is certainly Userinit. Userinit is the first program which is executed after logon.
From MSDN: http://msdn.microsoft.com/en-us/library/aa378750(VS.85).aspx
Userinit.exe is an application that is executed when the user has logged on. It runs in the newly logged-on user’s context and on the application desktop. Its purpose is to set up the user’s environment, including restoring network uses, establishing profile settings such as fonts and screen colors, and running logon scripts. After completing those tasks, Userinit.exe executes the user shell programs. The shell programs inherit the environment that Userinit.exe sets up. The specific shell programs that Userinit.exe executes are stored in the Shell key value under the Winlogon registry key.
Add the lock command to Userinit
Create a batch file that will lock the computer:
rundll32.exe user32.dll,LockWorkStation
Name the file lock.bat and place it in the System Root. (c:\windows\system32).
Open regedit and navigate to:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
The registry value Userinit should contain the path to Userinit.exe
C:\Windows\system32\userinit.exe
Change the value to contain the lock batch file before the Userinit.exe, with a comma between.
C:\Windows\System32\lock.bat, C:\Windows\system32\userinit.exe
Log off to see the result. Note that using a batch file does not discriminate between automatic logon, and user-initiated logon. One could write a program that would only call LockWorkStation if the computer was up for less than 10 minutes.
To enable automatic logon
If automatic logon isn’t already enabled, execute control userpasswords2 at the Run prompt, and uncheck Users must enter a username and password to use this computer.
Windows XP SP3: Give Microsft a break!
I ran into this article today over at TechSpot, and became immediately annoyed at the way they are nitpicking at the decisions Microsoft made on the release of SP3.
I put SP3 on my laptop last week, it installed much the same way that XP SP1 and SP2 did, it took around 25 minutes to install, and everything feels the same as before the update. I have had problems in the past updating computers to SP2 and getting a blue-screen due to unexpected winlogon.exe termination. Perhaps it’s just that I do like Microsoft, and I cut them slack and don’t expect everything to be perfect, or perhaps it’s because I work in the industry and know how complicated it can be to push an update of this magnitude.
Windows is really complicated. It’s not as simple as it looks from a user perspective, there are very complex systems in Windows (this does apply to any operating system–OSX and Linux are just as complex), pushing an update can have an adverse affect on any one of those systems.
The Microsoft Windows operating system supports thousands of devices. More than 30,000 [as of October 2006] drivers have been released; more are introduced daily.
It is not a secret that the success of Windows in the recent years has been largely due to the massive hardware and software that are compatible with Windows, and only Windows. Microsoft has certainly put a substantial amount of effort into ensuring that more software and more hardware works with Windows than any other platform. When Apple releases an update to OSX, things break. Users expect software to break. Many applications weren’t compatible with 10.4 Tiger to 10.5 Leopard. Apple sees this as acceptable, and perhaps necessary to build a rock solid OS over time. I’m quite sure that the API for OSX has changed and evolved over the years, and is far cleaner and simple to use than Windows win32 API. This backwards compatibility–something that Microsoft often gets flack for, is one of their strongest selling points, and the track record of compatibility is one that businesses can depend on. Something written for Windows XP will still likely work on Windows 95, unless it is using advanced graphics, or has a dependency on the .NET CLR.
For these reaons, a service pack–or even an update can and eventually will break something. It’s a delicate system, if you want massive hardware and software support, you will need to deal with some of the shortcomings.
The aforementioned article also mentions how SP3 won’t be installed on any computer with IE8 Beta–and that if you install on a computer with IE7, it will no longer be able to roll back to IE6. This is because the components in IE (mainly the Trident Layout engine) are used in other parts of Windows. If the service pack allowed IE8b installed, or to roll back to a time before the service pack, file version inconsistencies would be created. There are many ways that this could happen, and it would have had to have been extensively tested. This costs more, and benefits very very few users. Most would not complain about the limitation.