Introduction to MinLogon
Microsoft® Windows® XP Embedded with Service Pack 1
Minimal Logon (MinLogon) is a hybrid version of the Windows Logon component (WinLogon) that ships with both Windows XP Embedded and Windows XP Professional. WinLogon is a utility that provides logon and authentication support for users to the local system and/or network domain. It consists of an executable file, a dynamic-link library (DLL), and associated services. WinLogon is not available for Windows 95, Windows 98 or Windows Millennium Edition (Windows Me).
MinLogon is particular to Windows XP Embedded as it is geared toward the needs of embedded developers, and so is not available or supported on Windows XP Professional systems. Using MinLogon in a Windows XP Embedded runtime allows you to reduce boot time, shutdown time, and footprint. However, there are some points to keep in mind when using these techniques. (3 printed pages)
The MinLogon baseline configuration uses a simpler logon process than WinLogon that always logs on the user as the system user. You can use this configuration if your application will not require the user to log on to the system by using a local machine or domain account. The MinLogon configuration is typically smaller than WinLogon because it has fewer component dependencies. However, the MinLogon configuration includes full Microsoft® Win32® support, meaning that applications can link to kernel32, gdi32, user32, and advapi32 libraries.
The MinLogon Helper Macro component that ships with Microsoft Windows® XP Embedded with Service Pack 1 will generate a footprint around 15 megabytes (MB). This component can serve as a foundation on which to build your Windows XP Embedded runtime images. You can find the MinLogon Helper macro under the Test & Development category in the component database.
In general, MinLogon is a good choice for devices that are stand-alone and require a basic Transmission Control Protocol/Internet Protocol (TCP/IP) implementation, such as stand-alone Internet or Informational Kiosks. TCP/IP functionality—which is required for Internet access— In addition, TCP/IP is easy to implement in a MinLogon configuration, and there is less hassle with regards to user-specific account login if a stand-alone system is unexpectedly restarted.
MinLogon can reduce boot time and shutdown time by as much as 10 to 15 seconds on average.
MinLogon can also reduce footprint in configurations where user-level authentication is not required. WinLogon requires at least one user account to be present on the local system, and therefore brings in the required component dependencies needed for local authentication of that user.
However, MinLogon does not reduce footprint in all cases. MinLogon cannot reduce the footprint size of your runtime image if you specify the Explorer Shell component as your default system shell. The Explorer Shell has a direct dependency on the WinLogon component; including WinLogon in your configuration will include all the required subsystem components needed to support user level authentication. If you wish to use a user interface familiar to most users and do not have a requirement for an extremely small footprint—or you and do not have the time or ability to create a custom shell—then the Explorer shell will fit your needs. Otherwise, creating a custom shell will help reduce your image size substantially.
If you choose the Explorer Shell and then replace WinLogon with MinLogon, this results in the footprint savings of only a few megabytes—sharply reducing the benefit of using MinLogon in the first place. It is often the dependencies of the rich Explorer Shell and WinLogon that create larger run-time images. As a result, developers who desire to reduce footprint further and do not require the additional functionality provided by the Explorer Shell should consider using a custom shell application for their design when using MinLogon.
It is important to understand that MinLogon will never prompt a user for login credentials such as a user name or password. In addition, MinLogon does not include support for an Administrator account and has no concept of user accounts or privileges to the local machine's file system or resources. MinLogon also does not have a concept of global users or accounts and cannot be joined to a domain. Embedded designs that require domain participation support should use WinLogon.
With MinLogon, users have unlimited power over the system, much like the Administrator account has in typical Windows XP Professional installations. Users will be able to delete or modify the files, settings, and services of the system as they want. However, this does not mean that MinLogon completely lacks security mechanisms; rather, it means that security features that were inherited and enabled by default under a WinLogon configuration must be incorporated into a MinLogon design if security is desired. Developers using MinLogon in their embedded designs must be conscious of this fact, and proactively take measures to block access to exposed areas of the operating system.
Conversely, a locked down MinLogon system could be considered more secure than a locked-down WinLogon system because there is no "back door" such as an Administrator or Guest account to hack into. But beware that once all the doors are locked, there is no back door for even the creator of the runtime image to enter.
Using MinLogon can aid you in optimizing the performance of Windows XP Embedded runtimes. However, there are security concerns that users must address to help attain a more reliable Windows XP Embedded platform.
For more information about the MinLogon component, see Minlogon Sample Macro.
For more information about Windows XP Embedded, see the Windows XP Embedded home page.
For online documentation and context-sensitive Help included with Windows XP Embedded with Service Pack 1, see the Windows XP Embedded product documentation.