A highly optimized Java runtime environment targeting a wide range of consumer products, including pagers, cellular phones, screen phones, digital set-top boxes, and car navigation systems.

PersonalJava is a Java environment based on the Java virtual machine1 (JVM) and a set of APIs similar to a JDK 1.1 environment. It includes the Touchable Look and Feel (also called Truffle), a graphic toolkit that is optimized for consumer devices with a touch sensitive screen. PersonalJava will be included in J2ME in the upcoming Personal Profile, which is built on CDC.

When a window is visible on the screen it undergoes various stages such as CreateWindow, ShowWindow, etc. Once the window is displayed on the screen it must now make itself ready to take keyboard and mouse input from the user. Windows maintains a message queue for each windows program currently running under windows. When an input occurs, the OS translates this event into a message that it places into the windows message queue. A program receives messages from the message queue by executing a block of code known as the message loop.  While (GetMessage(&msg, NULL, 0, 0)){            TranslateMessage(&msg);            DispatchMessage(&msg);}  The GetMessage call passes to windows a pointer to the message and these fields of the message are filled by windows.  The TranslateMessage call passes the msg structure back to windows for some keyboard translation. The DispatchMessage call passes the message to windows which sends the message to appropriate windows procedure for processing the message. So this means that windows call the window procedure

Standard Safe Mode can be accessed by pressing F5 when the "Starting Windows 9x" message is displayed on the screen.

GDI is an acronym for Graphics Device Interface. The GDI allows you to draw on your windows. It is a device independent output model in the sense that the graphics code that you write for drawing will work on any video output which has a Windows driver.  In order to avoid one window interfering with another while drawing output on the screen GDI uses a mechanism called as device context to avoid this conflict. So when a window draws on a screen, printer or any other output device, it doesn't output pixels directly on the device. Instead it draws to a logical surface represented by a "device context" (DC). A DC is a data structure that has all information that GDI needs to know.  Before a Windows program draws anything on the screen it acquires a DC handle from the GDI and then passes this handle back to the GDI each time it calls the GDI output function. In MFC a DC encapsulates the GDI functions that a program uses to generate output. MFC's CDC class wraps a Windows device context and the GDI functions into one package. CPaintDC and CClientDC are subclasses of CDC and represent the different types of device contexts that windows applications use. E.g. CDC* pDC = GetDC(); //do some drawing Release (pDC);

Property sheets are tabbed dialog boxes containing pages that the user can switch with mouse clicks. They are a part of common library of windows just like dialog and other controls. E.g. when a user adds a schedules task it walks him through a wizard which is nothing but a property sheet. The functionality of property sheets is encapsulated in MFC classes of CPropertySheet and CPropertyPage. CPropertyPage represents a page in a property sheet and is a subclass of CDialog. Like dialog boxes property sheets can be modal or modeless. Use CPropertySheet::DoModal for modal and CPropertySheet::Create for a modeless property sheet.  There are four broad steps in creating a property page: 1. For each property page create a dialog template.   2. For the created dialog associate a class that derives from CPropertyPage.   3. Derive a property sheet class from CPropertySheet and create an object for each above created property pages.   4. Add the property page objects to the created property sheet using AddPage.   5. Call the doModal function of the property sheet to display it on the screen.