How can I enable CD Burning in Windows Server 2003?

Windows Server 2003 has the CD burning drivers disabled by default. The IMAPI CD-Burning COM Service required by this peripheral device is disabled, so to make it work we need to enable it.
Note: With some third-party software, you may be able to burn CDs without starting the IMAPI CD-Burning COM Service. BTW, some people say that it is recommended you leave this service disabled if you want to speed up the Nero Burning ROM startup. I haven't tested this myself so I cannot say for sure.
Lamer Note: Yes, you DO have to have a CD burner installed or else this tweak will be useless for you. It DOES NOT turn a standard CD Drive into a CD-R or CD-RW...
To have CD burning capabilities on Windows Server 2003 follow the next steps:

1. Go to the Services applet in Administrative Tools (or click Start, then Run, and type "services.msc" (without quotes) and click OK).
2. Find the "IMAPI CD-burning COM" service, right-click and select Properties, select "Automatic" instead of "Disabled" in the startup type box.

3. Click Apply.
4. Right-click the "IMAPI CD-burning COM" service and select Start.

5. Click OK.

You can also modify start state and start it from a Command Prompt console by using the following command:
sc config imapiservice start= auto and sc start imapiservice or net start imapiservice

How can I disable the Welcome Screen in Windows XP Pro?

 To turn the Welcome Screen on or off:
You must have a computer administrator account on a computer that is a member of a workgroup or is a stand-alone computer to turn on or turn off the Use the Welcome screen feature. Logging on at the Welcome screen is not available on computers that are members of a network domain.

1. Open User Accounts in Control Panel.

2. Click Change the way users log on or off.

Do one of the following:
· To specify that users log on to the computer using the Welcome screen, select the Use the Welcome screen check box. A user logs on to the computer by clicking his or her user account name on the Welcome screen. If a password is assigned to the account, the user is prompted to type it.

· To specify that users log on to the computer without using the Welcome screen, clear the Use the Welcome screen check box. The Welcome screen will no longer appear when you start the computer. To log on to the computer, type your user name (and password, if you have one) in the standard Log On to Windows dialog box.

Note: To open User Accounts, click Start, click Control Panel, and then double-click User Accounts. Fast User Switching is available only when the Welcome screen is turned on.

Note: To disable the Welcome screen you can also open the Registry editor and go to

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\WinLogon

In the right pane, remove the entry for Gina.DLL.

Class Loaders

Class loaders are the gatekeepers of the JVM, controlling what bytecode may be loaded and what should be rejected. As such they have a number of responsibilities:

1. To separate name spaces, thus preventing intentional and unintentional code corruption and limiting name clash problems to class files from one source.

2. To protect the boundaries of the core Java class packages (trusted classes) by refusing to load classes into these restricted packages.

3. Starting in Java 2, establish the protection domain (set of permissions) for a loaded class. This is the basis for run-time authorization checking for access to resources.

4. To enforce a search order that will prevent core and local classes from being replaced by classes from less trusted sources.

The class loader has another, useful, side effect. By controlling how the JVM loads code, all platform-specific file I/O is channelled through one part of the JVM, thus making porting the JVM to different platforms a much simpler task. Let’s look a little more closely at these responsibilities and why they are necessary.

First, Java code can be loaded from a number of different sources. Some of the more common sources are:

• The trusted core classes that ship with the JVM (java.lang.*, java.applet.* etc.)

• Any installed JVM extensions 146 Java 2 Network Security

• Classes stored in the local file system (usually found using the CLASSPATH system environment variable)

• Classes retrieved from external sources such as from a Web server Clearly, we would not want to overwrite a trusted JVM class with an identically named class from a Web server since this would undermine the entire Java security model. For instance, the SecurityManager class is responsible for a large part of the JVM run-time security and is a trusted local class; consider

what would happen to security if the SecurityManager could be replaced by a class loaded from a remote site. The class loader must therefore ensure that trusted local classes are loaded in preference to remote classes where a name clash occurs.

Secondly, where classes are loaded from Web servers, it is possible that there could be a deliberate or unintentional collision of names (although the Sun Java naming conventions exist to prevent unintentional name collisions). If two versions of a class exist and are used by different applets from different

Web sites, then the JVM, through the auspices of the class loader, must ensure that the two classes can coexist without any possibility of confusion occurring.

The class loader must protect the boundaries of the trusted class packages.The core Java class libraries that ship with the JVM reside in a series of packages. Within the Java programming language, it is possible to give special access privileges to classes that reside in the same package; thus, a class which is part of the java.lang package, for instance, has access to methods and fields within other classes in the java.lang package which are not accessible to classes outside of this package.

If it were possible for a programmer to add his or her own classes to the java.lang package, then those classes would also have privileged access to the core classes. This would be an exposure of the JVM and consequently must not be allowed. The class loader must therefore ensure that classes cannot be dynamically added to the various core language packages.

The JVM may have many class loaders operating at any point in time, each of which is responsible for locating and loading classes from different sources.