XP embedded: different users use different shell programs

This article from: http://www.microsoft.com/china/MSDN/library/mobility/embedded/EDGvirtu.mspx? MFR = true

Abstract:

Making applications a shell is one of the key features of Windows XP embedded. A device can be started in a custom shell instead of an Explorer Shell, which provides two benefits. The first advantage is that the system can be started faster. The Explorer Shell takes a lot of time to load all the supported libraries and files, and a specific application may need to load fewer libraries. The second advantage is that you can restrict access to the management functions of the device, depending entirely on how the custom shell application is written.

Limiting user access to management functions (such as control panel) may be advantageous, but there is a small drawback: the Administrator is also restricted, unless the administrator can start in different shell programs.

The ideal solution is to set Windows XP embedded so that the user account can be started in the application shell, while the Administrator account can be started in the management shell. Then, the built-in security functions in Windows XP embedded can prevent users from accessing the management functions. This article describes how to implement this solution.

 

Content on this page

Registry is the key
Working Principle
Windows XP embedded settings
Notes
Summary

Registry is the key

Microsoft Windows XP provides a solution through the registry. You can set the registry for each user account and administrator account to start the user-specific shell program. There are three required items. The first two items are common to all users. For simplicity, these items are referred to as "key1", "key2", and "key3 ".

Key1 is a string value. When Windows XP is started, key1 is called and the default Windows shell program is started. However, if the default value is changedUSR: Software/Microsoft/Windows NT/CurrentVersion/WinlogonWindows will detectHKEY_CURRENT_USERTo start a specific shell program for the login user. If no specific User Shell is found, key2 is called and the default shell is started.

Item:HKEY_LOCAL_MACHINE/software/Microsoft/Windows NT/CurrentVersion/inifilemapping/system. ini/boot/ShellType:REG_SZ

Value:SYS: Microsoft/Windows NT/CurrentVersion/Winlogon

If the User Shell application cannot be found, key2 provides the default shell program. When you select the shell component for the Microsoft Windows XP embedded configuration, key2 is set as the shell application of the default shell program.

Item:HKEY_LOCAL_MACHINE/software/Microsoft/Windows NT/CurrentVersion/Winlogon/ShellType:REG_SZ

Value:Assumer.exe(Or different default applications)

Key3 sets the shell program for the current user or login user. Therefore, the only way to change the shell program for a specific user is to log on to the user account and create the registry entry.

Item:HKEY_CURRENT_USER/software/Microsoft/Windows NT/CurrentVersion/Winlogon/ShellType:REG_SZ

Value:C:/Windows/system32/ Account shell.exe,Where, Account shell.exe Is the name of the application.

Working Principle

When a user logs on, Windows uses key1 to determine which item stores the shell information. Generally, key2 is used in windows. However, if the value of key1 is changedUSR: Software/Microsoft/Windows NT/CurrentVersion/WinlogonIn Windows, key3 is used for the login user to start the specific shell program of the user.

It is quite easy to change the registry key value in a system with a registry set. The difficulty lies in how to do this in Windows XP embedded-on this platform, the Registry is set during the first boot agent (FBA) process.

You can set it in the target designer.HKLMItem because they are unique to computers. However, set it in the target designerHkcuItem is not possible, because no account is created before FBA runs. The User Account and administrator account components only create accounts, user names, and passwords. These components cannot be used to set specific Shell programs. The only solution is to set a specific shell after the Windows XP embedded image has completed the FBA process.

Back to Top: settings for Windows XP embedded

The tips for generating different shell programs for different users in Windows XP embedded exist in the settings. You need to include several components in the configuration so that you can set key3 for your account:

• Windows logon. Because the image contains different accounts, Windows logon (standard) is a required component for configuration. Windows logon supports local and remote logon to different accounts. In contrast, the minlogon component only supports logging on to a single administrator account.

• Two User AccountComponents. At least two computer accounts are required. At least one account must be an administrator account. You can set the user account component as an administrator account on the extended properties page. When a user account is set as an administrator account, it replaces the normal "Administrator" account, just like in other versions of Windows XP. Because the Administrator account is removed, you may want to use two user account component instances. You can set one component as an administrator (it will have an administrator shell) and another component as a regular user (it will have a system shell ).

• Automatic Logon. Most OEMs want their systems to start directly in applications. You can add the automatic logon component to the configuration so that it can be directly started in the user account (its shell program will be a system application.

• Default shell. Windows XP embedded comes with several Shell programs: Explorer, task manager, and command. You can also create custom Shell programs. Shell components are required in the configuration. When selecting shell components for configuration, the shell will be the default shell for the Windows XP embedded image, so key2 is not required.

For setting different shell programs for different users, the selected shell component is an administrator shell, and the shell must allow the registry to be configured to set access permissions for key3. Task Manager may be a good choice. Taskmanager is a small shell that can be used to start other applications, such as control.exe (Control Panel) or regedit.exe (Registry Editor ). If the TaskManager shell is not suitable, you may want to create your own management shell. After the FBA process is completed, all accounts will have the same administrator shell. Then, you can log on to any account and set key3.

• User Shell. The last component is the user or system application, which will be the auxiliary shell program. Secondary shell components should not be set as shell components, or they should be combined with other shell components. Instead, you should treat the auxiliary shell components like any other application components (such as Windows accessories or the Transport Control Protocol/Internet Protocol (TCP/IP) utility. After FBA is complete, you can log on to the user account and set key3 to point to the application. If the application component is lost, the default Administrator shell component is displayed.

• Other components. It can contain the Windows Script Engine and Registry Editor to help create key3. You can create a custom application to execute this task.

Set key1

Key1 must be set. In extra registry data at the top of the configuration, add key1 as described earlier and setUSR: Software/Microsoft/Windows NT/CurrentVersion/Winlogon. To view extra registry data resources, you may have to use the following method to enable resources: ClickView, PointingResourcesAnd then clickTarget designer.

After setting, generating, and downloading the configuration to the target and completing the FBA process, the final step is to set a user account for the system shell program. Because you initially set the image to start in the administrator shell, you should be able to access the registry.

Set key3

To set a user account with a unique shell program, you must log on to the user account and add key3 to set the path of the system application. Please note that you cannot log on to the administrator account to change the shell program of the user account. After logging on to the user account, you can use regedit.exe, Windows Script, or other applications to create key3 and set the Application Path.

The following is a wscript example.

'Windows Script to set a user shell
set shell = CreateObject("WScript.shell")

shellpath = InputBox ("Enter the path and name of the EXE application 
to be this user's shell. Example: c:/windows/system32/cmd.exe:") 

if shellpath <> "" then Shell.RegWrite 
"HKCU/Software/Microsoft/Windows NT/CurrentVersion/Winlogon/Shell", shellpath, "REG_SZ"

The following is a cscript example.

'Windows Script to set a user shell
set shell = CreateObject("WScript.shell")

wscript.stdout.WriteLine "Change the Shell for this user."
wscript.stdout.WriteLine
ChangeReg

sub ChangeReg
wscript.stdout.WriteLine "Enter the path and name of the EXE application to be this user's shell."
wscript.stdout.WriteLine "Example: c:/windows/system32/cmd.exe or type QUIT to exit: "

if wscript.stdin.AtEndOfStream  then exit sub
shellpath = wscript.stdin.ReadLine
if ucase(shellpath) = "QUIT" then exit sub

Shell.RegWrite "HKCU/Software/Microsoft/Windows NT/CurrentVersion/Winlogon/Shell", shellpath, "REG_SZ"

wscript.stdout.WriteLine "User will now have a new shell"
wscript.stdout.WriteLine
end sub

After key3 is set, you can log out and log on to the user account and/or administrator account again. When you log on to the user account, the specific shell program of the user account will start. When you log on to the administrator account, the default/Administrator shell starts.

Back to Top notes

By default, the Windows Script Engine is set for wscript. Wscript uses a dialog box to display input and output messages. Cscript only uses command prompts, Which is ideal for headless systems. Only the Administrator account can be changed to cscript. If you decide to use the Windows Script Engine, you must modify the registry data of the Windows Script Engine component for the Microsoft Visual Basic Scripting Edition (VBScript) file. ChangeHkey_classes_root/vbsfile/Shell/Open/commandAnd set% 1Add to value% 11%/wscript.exe, SuchFigure 1.

Figure 1. Change Windows Registry Value of the script engine component

After creating key3, you can log on to the user account again and view the new shell program of the account. When you log on to the administrator account, the default or administrator shell will still start.

If you are using the remote management function, please note that Telnet allows more than one user to log on to the same computer, but Remote Desktop Connection or Microsoft NetMeeting allows only one user to log on to the computer. Remote Desktop Connection controls the desktop and cancels the user from the system. If you intend to use Remote Desktop Connection, your system will not be affected by the administrator login and user account cancellation.

In addition, after key3 is set, you can use fbreseal (included in the cloning component) to re-seal the image for copying. The registry key information of the user account is retained.

Back to Top Summary

Windows XP embedded provides a flexible way to deploy popular Windows XP operating systems to many embedded devices. Since there are two accounts with different shell programs, OEM can generate a system that prevents unexpected user access to the management function. The solution is to define the management shell as the default shell in the system and change the registry key of the user account to point to the auxiliary shell.