PAE, 4GT and AWE

PAE: Physical Address Extension
4GT: 4-gigabyte tuning
AWE: Address Windowing Extensions

• PAE allows the operating system to access and use more than 4 GB of physical memory. PAE also enables several advanced system and processor features, such as hardware-enabled Data Execution Prevention (DEP), Non-Uniform Memory Architecture (NUMA) and the ability to add memory to a system while it is running (hot-add memory), so it can also be used on computers that have less than 4 GB of memory. PAE is supported only on 32-bit versions of Windows; 64-bit versions of Windows do not support PAE.
• 4GT extends the 32-bit user virtual address space from 2 GB to up to 3 GB.
• AWE is a set of APIs that allows a process to allocate non-paged physical memory and then dynamically map portions of this memory into the virtual address space of the process.
• When neither 4GT nor AWE are being used, the amount of physical memory that a single 32-bit process can use is limited by the size of its address space (2 GB). In this case, a PAE-enabled system can still make use of more than 4 GB of RAM to run multiple processes at the same time or to cache file data in memory.
• 4GT can be used with or without PAE. However, some versions of Windows limit the maximum amount of physical memory that can be supported when 4GT is used. On such systems, booting with 4GT enabled causes the operating system to ignore any memory in excess of the limit. For details, see Memory Limits for Windows Releases.
• AWE does not require PAE or 4GT but is often used together with PAE to allocate more than 4 GB of physical memory from a single 32-bit process.

USB Device ENUMERATION PROCESS

( Copy From Microchip AN1003)

The following summarizes the steps involved in theenumeration of a USB device and explains how thedevice goes from Powered to Default, Address and theConfigured state during the enumeration process.

1. User plugs a USB device into a USB port. The hub provides power to the port and the device isin the Powered state.

2. The hub detects the device.

3. The hub uses an interrupt pipe to report the event to the host.

4. Host sends Get_Port_Status request to obtain more information about the device.

5. Hub detects whether device is Low-Speed orFull-Speed operation and sends the information to the host in response to Get_Port_Status.

6. Host sends a Set_Port_Feature request, asking the hub to reset the port.

7. Hub resets the device.

8. Host learns if a Full-Speed device supports High-Speed operation (using Chirp K signal).

9. Host verifies if the device has exited the Reset state using Get_Port_Status.

10. At this point, the device is in the Default state(device is ready to respond to control transfersover the default pipe at Endpoint 0, default address is 00h and the device can draw up to100 mA from the bus).

11. Host sends Get_Descriptor to learn the maximum packet size (Note: eighth byte of the device descriptor is bMaxPacketSize).

12. The host assigns an address by sending a Set_Address request. Device is now in the Address state.
13. Host sends Get_Descriptor to learn more about the device. The host responds by sending the descriptor followed by all other subordinate descriptors.

14. Host assigns and loads a device driver.

15. Host’s device driver selects a configuration bysending a Set_Configuration request. The device is now in the Configured state.

16. Host assigns drivers for interfaces in composite devices.

17. If the hub detects an overcurrent, or if the host requests the hub to remove power, the device will be unpowered by the USB bus. In this case, the device and host cannot communicate and the device is in the Attached state.

18. If the device does not see any activity on the busfor 3 ms, it goes into the Suspend state. The device consumes minimal bus power in thisstate.

Composite USB device

A device that contains more than one interface descriptor is known as a composite USB device. Each interface in a composite USB device is numbered.

http://msdn.microsoft.com/en-us/library/ms794302.aspx

USB Device Stack for Windows XP and Later

The PCI bus driver enumerates the USB host controllers in the system and creates a PDO for each one. In Windows XP (SP1 and later) and Windows Server 2003, the operating system supports USB 2.0 and can enumerate both USB 2.0-compliant and USB 1.1-compliant hardware. If both sorts of controller are present on the same controller card in a version of Windows that supports USB 2.0, the PCI bus driver creates two separate PDOs, one for each controller. Only one PDO is shown in the figure. After creating a PDO for the host controller, the system loads the port driver, usbport.sys, and its accompanying miniports (not shown in the figure). The port driver then creates an FDO for the host controller.
The port driver enumerates the root hub. The usbhub.sys driver enumerates all other USB hubs. The figure only shows one level of hub device objects, but USB allows daisy-chaining of hub devices, so there could potentially be many more hub device objects in the tree. The hub driver detects and enumerates the USB composite keyboard device and creates a PDO for it.
In Windows XP and later versions of the operating system, the generic parent facility is implemented by a separate driver called the USB composite client generic parent driver. For a detailed discussion of this driver, see USB Common Class Generic Parent Driver. When the system detects a composite device, it loads the generic parent driver, which creates an FDO for the device as a whole. Afterwards, the generic parent driver creates separate PDOs for each interface of the composite device. In Windows 2000, these actions are performed by the hub driver. For more information, see USB Device Stack for Windows 2000.
In the example illustrated in the figure, the composite device consists of a HID-compliant keyboard interface and a HID-compliant power keys interface. The hub driver creates a separate PDO for each interface. After that, the HID class driver creates an FDO for each interface.

PnP Device Installation

1. Plug the device into the computer.
2. The device is enumerated. the bus driver notifies the kernel-mode PnP manager that the list of devices on the bus has changed. The Kernel-mode PnP manager sends IRPs(IRP_MN_QUERY_ID, IRP_MN_QUERY_CAPABILITIES) to bus driver to gather information about the new device, such as HadwardID, CompatibleIDs and device capabilities.
3. The kernel_mode PnP manager notifies user-mode PnP manager that there is a device to be installed. The user-mode PnP manager tries to perform a server-side installation(quiet intallation)
4. The user-mode PnP manager creates a new process using rundll32.exe and launches newdev.dll to install the device.
5. newdev.dll calls SteupAPI(device installation functions) and CfgMgr API(PnP configuration manager functions) to carry out its installation tasks. If a device without "in box" drivers is plugged in before the operating system is installed, Device Manager will display the device as "unknown".
6. The class installer and co-installer, if any, can participate in the installation by handling DIF requests.
7. Setup transfers control to kernel mode to load drivers and start the device.
Once Setup has selected the best driver for the device, copied the appropriate driver files, registered any device-specific co-installers, and registered any device interfaces, it transfer control to kernel mode to load the drivers ans start the device.
8. The (Kernel mode?) PnP manager loads appropriate function driver and any optional filter drivers for the device. ...
a. The PnP manager calls DriverEntry routine for any required driver that is not yet loaded.
b. Then the PnP manager calls the AddDevice routine for earch driver, starting with lower-filter drivers, then the function driver, and, lastly, any upper filter driver.
c. The PnP manager assigns resources to the device, if required, and sends IRP_MN_START_DEVICE to the device's drivers.
9. Installer can change device settings or install application SW, in finish-install wizard pages( or finish-install actions in Vista above)

I suppose in step 7, Setup has done the select-copy-register driver thing, device manager could refresh automatically once. (deivice will display "Unknown" to a named device).
and then in step8, PnP manger to load driver in stack and start device, device manger could refresh automatically the 2nd time.

Display JPG in ATL

• Tools: VC2005 (ATL8.0)

• 2 possible ways:
1. using the OleLoadPicture function and the IPicture interface
http://msdn.microsoft.com/en-us/magazine/cc301454.aspx
2. ATL CImage Class
http://msdn.microsoft.com/en-us/library/bwea7by5(VS.80).aspx
CImage calls GDIPlus in the end... Gdiplus.dll is included with Windows XP, which is also included in Win2000SP4.

• How to package the ActiveX ATL in a Web page
1. Use the depends.exe to check dependency
2. Pack VC2005 redistrubution package...
[C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86\ vcredist_x86.exe]
3. ReferenceHow to package MFC controls in a Web page[KB167158]
http://support.microsoft.com/kb/167158/
http://topic.csdn.net/u/20071024/16/f820f776-ff31-4e25-954c-195f2c7e40b0.html

[msvcr80.dll]
FileVersion=8,00,50727,42
hook=mfc80installer

[mfc80installer]
file-win32-x86=http://192.168.1.117/helloactivex/mfc80.cab run=%EXTRACT_DIR%vcredist_x86.exe

opening...

I will move http://computer.mblogger.cn/firing here.