Eboot code process [转] eboot code process ---- by nasiry reprint, please indicate that ebonot has gone many times, there has been no finishing throughout the code process. This is still a matter of doing it: First of all, it is usually a compilation code: starting by the system reset caused by the system to trigger the condition: Take 2440 code as an example directly into the FW.s file. The main operation is to set the processor frequency (PLL), set the memory parameters, and note that although many interrupt vectors are implemented in the form, these code will not be executed. (Refer to the "eBoot Compile Compiler to determine the interrupt vector and its realization") and there will be some other means to implement the function of the interrupt vector. Since the part of the file is multiplexed with the HAL, the called function name will be the same as the kernel start function, but the implementation is completely different. At the end of this section, an OEMADDRESSTABLE address pointer to the next function is saved to perform the memory. The following is also an example of 2440BSP. According to the requirements of the WindowsCe system, it is necessary to image the memory space will be operated to 512M space after 0x8000 000 0000, where low 256m is buffered, high 256m is without buffering. The non-buffered area is usually the driving access device, which can guarantee interference of the hardware from the buffer. In addition to moving memory space according to OEMADDRESSTABLE, you can also make other shadows according to program requirements, usually, all of which are currently moving in the original address space in the original address space for easy use. Alternatively, the 0x0 position is imaged to memory so that the medium short vector installation can be performed by this part to implement the interrupt service program. (The above-contrast is not required, just for the preparation of the program, the same image of the use and system can make it unhappy to build a set of files, and if necessary, you can save eboot in memory, so that memory space Planning is relatively easy to do). These works have been completed, and the EBOOT entrance function provided by Windowsce is entered. That is, bootloadermain. This function is located in Wince420 / Public / Common / Oak / Drivers / Ethdbg / Blcommon / BLCommon.c file. The directory file is the Eboot framework provided by Microsoft, although this is not a part of the implementation, it is also analyzed. The content of this part is very interesting, the first execution statement is as follows if (! Kerr_kernergy) {halt (blerr_kernergy);} This incoming parameter is defined in this way: romhdr * volatile const ptoc = (romhdr *) - 1; According to the content of the program, this function will be a dead cycle, but in fact, this dead cycle will not be executed, that is, ptoc = (romhdr *) - 1 does not really play . Check the value of PTOC before the first use of PTOC, as follows: PTOC = 0x8c04d694. That is to say, PTOC is no longer -1 before being changed, and PTOC is defined as const, and there is no way to change. It seems that this pointer is only passive during the compiler. Hand feet. The content corresponding to this address in eboot.map is actually bootpart.obj content.
I feel that there is no way, so that people are tipping. After carefully comparing eBoot.exe and eboot.nb0, eboot.exe has increased after the Romimage process, and the structure has changed a lot, and a series of original. The content of the PTOC is to belong to this after the original .eboot.exe. Part of the part of the content. Since the image chain structure involved in Windowsce, the contents of this section cannot be continued. This part is skipped. Will look back in it later. The debug interface is then initialized in bootloadermain, and the implementation of this function by OEMDebuginit is the initialization of the serial port by the specific hardware decision, and then the debug interface is issued by the debug interface. Then, in Oemplatforminit (), the hardware resource you want to use is initialized to the hardware resources you want to use, usually: storage devices (flash, hard drive, etc.), transfer interface (Ethernet card, USB-RNDIS, wireless network card, CF-LAN, etc. ), The system clock is prepared for the following OS mirror transmission, OS image storage, reading, etc. will be prepared. After preparing, you can call OempredownLoad () to transfer OS preparation, and a series of functions are usually implemented in this function, such as the setting of the device, the formatting of the storage device, the designation of the NIC IP, and so on. The standard operations supported by WindowsCE are just two, one is jump, one is download, respectively, corresponding to the entry point of the OS mirror and jump into the OS, all mentioned the features mentioned earlier implementation. Below we look at the branches of these two standard operations: The first is the downloaded branch, first through OEMREADDATA in the downloaded branch, it is the data called the magic number, which is used to compare Confirm whether the content of this transmission is the image data of Windowsce, and then continue to further obtain the value of the data and the number of the data to be received, the image of the mirror start address, the length, etc. have these information, which is naturally Receive the image, then check the data. The reception of the next mirror information is recirculated until all mirror information is received. Jason128 published
> 2004-12-14 0:28:39
[full text]
[comment]
[Quote]
[recommend]
[file]
[Push your friends]
2004-12-14
[转] Windowsce directory parses Windowsce directory analysis ---Windowsce.Net 4.20 --------------- by nasiry reprint, please explain, and inform me that Windows Ce is huge, Although WindowsCE helps this huge directory structure, there is still a lot of directory, and there are no specific purposes in Windowsce HELP. The following will make a simple introduction to Windows Catalog. 1.SDK exists in Platform, Private, SDK, OTHERS, and PUBLICs in the root of Windowsce.Net 4.2. SDK is the most simple directory structure SDK / BIN / I386 is the tool set, compiler, etc. needed to develop, and I will not be embarrassed here. The SDK directory contains tools that are used by Platform Builder However, it does not contain the tools that are used to build the image The toolscontained by the SDK directory are:.. .. Processor compilersThis directory contains the cross compilers and assemblers for supportedplatforms. .. Development toolsThis directory contains the tools such as, Error Lookup, GuidGen, and Linkand Nmake ... miscellaneous utilitesThis directory contains the utilities, such as Zoomin, the contents and Windiff. 2.other catalog more complex, such as ATL has , The MFC's header file, the running library, etc. Develop the reservoir needed to be required and part of the code. One of the file directories is more important to the development system, that is, CETK's client Others / Wcetk, which can customize your own Windows CE .NET TEST KIT client via files in this directory.
The Others directory contains all the Windows CE runtime libraries andheaders, components for .NET Compact Frameworks, and Samples for ATLand MFC The Others directory contains the following subdirectories:. .. ATLThis directory contains ATL headers, libraries and source code fordebugging The library debug. symbols are also included ... DOTNETThis directory contains the .NET processor specific binaries and portable.NET Compact Framework files ... MFCThis directory contains MFC Headers, Libraries and Source Code fordebugging. The library debug symbols are also included ... SAMPLESThis directory contains the MFC and ATL sample applications ... WCETKThis directory contains the Windows CE Test Kit (CETK) processorspecific binaries. CETK provides tests for each class of devices. Within theCETK, you can choose the appropriate test to perform on your device driverand the tool Remotely Runs The Tests On Your Target Device. 3. The legendary BSP is stored, which provides resources such as hardware abstraction layers, bootloader, soc drivers for various development boards, which can be seen The resources in this directory are hardware-related. Generally speaking, each folder is corresponding to one SDB in this directory. The following is based on SMDK2410 as an example of the contents of the Platform directory structure. | Platform | --SMDK2410 ---- | -Cesysgen | --DRIVERS ------ | --Display | | --DRVLIB | | --KEYBD | | --PWRBTN | | --SERIAL | | --TOUCHP | | USB | | --WAVCLICK | | --wavedev | --eboot -------- | - ARM | | --BIN | - Files ---------- | - InTrns | -Gwe --------------BUILDEXE | | --NLEDDRV | - Inc | | --kernel ------- | --BUILDEXE ----- | --kern | | | --Kernkitl | | - kernkitlprof | | --hal | | --profiler | --NAND * | --UTILITIES * Among them, NAND and UTILITIES are unique to the 2410 BSP, NAND contains NANDFLASH as Start the startup code of the media, the contents of Utilities are executable files containing debugging information - Samsung's test program (which file can be used with ADS).
Cesysgen generally only has a file called makefile, usually the file pointing (_winceroot) /public/common/cesysgen/cesgenplatform.mak is also a public Platform generated file, which provides support for WindowsCE projects. The content under the DRIVER directory is also very straightforward, that is, various SOC devices and onboard equipment drivers. For example: Display is the driver of the LCD controller. Keybd is the keyboard driver. Rewindering, therefore discovered that the file can be found in the above file when the file is used to the unknown function. (Bootloader's source file is complete, interested men and women can be studied) Files The following is a debris warehouse, which may have the application file required by the BSP and the information file required to generate the system. If you want to know the entry point of the BSP, adjust the mirror, understand the information such as static high memory allocation, can be seen here, the intltrns subdirectory defines some strings, these strings are used to replace CEPB generation when generating the system. The logging used by the registry. GWE is part of GWES, which is the file below NLLDDRV is the driver of the LED tips. As for the Buildexe, it is the file required to generate GWES.exe, in fact, in fact, because of the empty GWS inside the CSP. The interface provided by LIB has been complete. INC is the gathering place of the header file, this will not be said. KERNEL: This directory structure is the key to the entire BSP, and the kernel is born here. The three folder-kern-kernkitl - kernkitlprof in the buildexe directory generates the three versions of Kernel Only / kernel With Kitl Transport / Kernel With Kitl and profiler, the first version is the most basic kernel is used as For the release, the second provides the KITL transfer interface to debug the system, while KernkitLprof provides a transport interface to provide a special performance timer as a measurement system performance. The PROFILER directory is the code of the performance timer. The following is the code of the core hardware abstraction layer. Basic Platform folder is this look, compared to the privat and public directory that have not been said later, these two folders are still relatively simple. We have something else in the back. 4.Public This folder is one of the most terrible directory structures I have seen in my life. All in all this, there is something, a word "miscellaneous", it is difficult to say something. Let's take a look at the structure of the first grade subdirectory. | public- | --wceshellfe * | --SHELLSDK * | --SHELL * | --Wceappsfe | --viewers | --sqlce | --speech | - Servers | --scrpit | --ie | --RDP | --NETCF | --IABASE | - HLBASE | - DirectX | - DCOM | --Datasync | - CommonCommon's things below, now we won't say it first.
I still say it from top to bottom (sweating ...) 4.1 About Shell Wceshellfe, shellsdk, shell's things in these three directories are shell related (don't ask me what is shell, it is what you see every day. The most familiar you still don't know how to exist in it). The SHELL provides Standshell and Aygshell, StandShell is the standard Windowsceshell looks similar to TablePC, where Aygshell is designed to Pocket PC, these two You can choose in the CEPB IDE. As for WCESHELLFE, it is mainly a variety of WindowsShell components: CTLPNL is the component of the control panel, with this you can do your own control, unhappy? Ftpupdate provides programs for upgrading Firemire through FTP, and the role is also to give you the cat's drawing tiger Lang and InputMeth 4 are input method. This I don't know, I don't talk about Taskman. I am more interesting. I am afraid that many people will need this thing, using this shell Generate an empty desktop, no icon, no icon, no blue desktop, but this cannot be generated through the IDE option, and the help is also can't get it, you need to modify sysgen.bat. As for those File, Inc, LIB below this directory, the same name of the same name mentioned above, I will no longer say. SHELLSDK is relatively simple, it is also the HEAD and LIB you want to use by developing shell applications. Nothing to say. Modules and Components Relative to the Far-East Enabledshell, Such As, Task Manager And Control Panel Components 4.2 Wceappsfe Legend This is Word and Outlook, I didn't get it, it is not clear. Since others say I said, I will have it. 4.3 Viewers Listening to the name, know what is doing, that is, the pair of viewers that Windowsce taken, such as what PDF, Excel, Word, but not Source is just lib, so there is nothing big meaning of. 4.4 SQLCE This is the hometown of SQLCE, but the same is the same, still not to change, no more written, the same boring. 4.5 SPEECH This directory is MS SAPI5.0, including TTS and voice recognition, free! However, only Japanese TTS other languages are not supported by Chinese and English. The same is not open code, by the way, there is a voice directory in File, that is the vocal file, if you want to listen to other sounds, you have to change it yourself. If you know where there are these VCE files, please tell me. 4.6 Servers This directory is mainly WindowsCE web services. Last time I remember someone asked me how to get the remote management interface of the road (web shell), let's find answers here. 4.7 Scrpit IE This is not to say that the Internet Explorer used every day has Java-VB Script support. Where IE can be customized. 4.8 RDP This directory provides remote desktop support (I understand Trojans for Windows Ce), including remote software clients and server. There is a third-party software inside, and I don't know very well.
4.9 Netcfdot Net Compact Framework. In fact, the directory is empty, in the end of these .NET files there? Look at Makefile, you can know that the resources used here are from the previously speaking% Winceroot% / Others / DotNet below. 4.10 IABASE4.11 HLBase These two together, the purpose of these two directories is not to use the IDE of the PB, but in the command line mode, there are a lot of .bat files, some The default configuration, the wizard in this and PB IDE is consistent. The difference between the two directories is that a band is displayed, which determines that there are many related things that are configured: such as GWES, so separate two directories, use different sysgen.bat files. These two catalogs have been combined in CE5.0.
Internet Appliance Base ConfigurationHeadless Base Configuration 4.12 DirectXDirectX is DirectX, and look at the directory structure ├─CESYSGENSysgen directory ├─OAK│ ├─FILES│ │ ├─INTLFILE│ │ └─INTLTRNS│ ├─INC│ ├─LIB│ └─VOIP │ ─voipmedia_ref│ ├─voipprov│ │ ├─file│ │ ├─LDAP│ │ ├─Manual│ │ ├─Manual_Core│ │ ├─test│ │ └─Xmlhelper│ └─Voipui│ ├─App│ │ └─ RES│ ├LPER│ ├─IME│ ├ ─ │ └─State └ --sdk ├ - in - l └ --samples ├─D3D │ ├─Boids │ ├─SIMPLE │ └ - Tutorials │ ├─TUT01_CREATEDEVICE │ ├ ─TUT02_VERTICES │ ├─TUT03_MATRICES │ ├─TUT04_LIGHTS │ └─TUT05_TEXTURES ├─DDRAW │ ├─INCLUDE │ └─SRC │ ├─DDEX1 │ ├─DDEX2 │ ├─DDEX3 │ ├─DDEX4 │ ├─DDUTIL │ ├─DONUTS │ └ --MOSquito ├ - DDVD │ ├─anxjtest │ ├─DVDPlay │ └ --dvdsample ├ --DSHOW │ ├─BaseClasses │ │ ─Headed │ │ └─Headless │ ├─Filters │ │ │ │ │ │ ZRGB24 │ │ └-inftee │ └─Players │ ├ ─ CePlayit │ ├─DDXCLMV │ ├─Hlplayit │ └ - PlayWnd ├ - DSOUND │ ├ --captureecho │ └ --DSPLAY ├─DXMISC │ ├─DDCAPS │ └ -dxView ├─mixer │ └ - TMIX ├─stb │ └─stbihost ├─voip │ └ --voipdemo │ ├─Resources │ └ - Source └ --wmp └─ceplayer └─res 4.13 DCOM This directory provides DCOM / COM support, but unfortunately no source, just 2 binary link library.
It is worth noting that the SAMPLE directory below the SDK directory is provided, such as regular tools, such as regr32, etc. 4.14 DatasyncDevice-Side Communication Components. 5 public / common / oak / driver Don't think that things in this directory are all driven as their name, in fact, there are many drivers and Windows components below this directory, we are in Windowsce IDE The source code for the selected characteristics is here, and this provides a lot of development templates for us to write code, and individuals think that this directory is our key to customize your Windowce, featured Windows start here. By the way, the name of Oak has been plaguing me for many years. It is not known that the brothers called "Tu Leopard" have been understood before, OAK is OEM Adaptation Kit. Let's take a look at what you have below. ├ --1394│ ├─Drivers│ │ ├─Client│ │ │ │ │ ├─AVC_Stream│ │ │ └─AVC_VCR│ │ └─Virtual│ │ ─1394DCAM│ │ ├─AVC_Unit│ │ └─AVC_VVCR │ ├ - in │ └─test│ ├ - DRIVER│ │ --1394Diag│ │ ├ - 1394VDEV│ │ └─Common│ ├ --inc│ └ └ │ └ - Topomap1394 Drive. ├ --ACM│ ├ -ACMDWRAP│ ├─GSM610│ ├─MSFILTER│ └ - PCMCONV├ - Battdrvr│ └ - Test│ ├─Getbat│ └─SetStubbatacm is an Audio Compression Manager is an audio compression manager, the directory below The G.711 (A-Law and MU-LAW coding), GSM 610, G.722.1, and Siren, is white, which is the audio encoder, and is more useful when making VoIPs for transmission purposes. The GSM610 is in the same name directory, and several ACMs are in the MSFilter directory. PCMCONV STMS is PCM Converter. CATTDRVR Battery Driver. ├─Block│ ├─ATADISK│ ├─ATAPI│ ├─MSFLASHFMD│ │ ─ec│ │ ├ - │ │ ─sdnpci│ │ │ ─sdnpcid│ │ │ └─Sdnpcik│ │ └─Trata│ │ ─Stratad│ │ └─stratak│ ├─ramdisk│ │ ├ --Driver│ │ └─LoaderDriver Code Structure│ └─sdmmcblock directory below is all BLOCK drivers provided by WindowsCE. A hard disk / optical drive, flash, and drivers of RamDisk and SD Card / MMC Card including PCCard interfaces. ATAPI is the ATA controller driver of the PCI bus, although only one directory content is a lot of this contains ALI 1543, Promise 20262, Intel 82371ata controller / Nanqiao chip driver. Atadisk is the drive of the PCMCIA ATA card. There is also an SD / NANDFLASH / MMC card of the PCI bus interface, as well as the Norflash driver of the plane interface. RamDisk is an example of using a memory analog storage system.
├ --Bluetooth│ ├ --Drivers│ │ ├─wcestreamt│ │ └─Wendyser│ ├─Profiles│ │ └ --HID│ │ ├─BASE│ │ ├─Parser│ │ └ │ │ ─sample│ │ ├ --ASUI │ │ ─BTCP│ │ ─BTDC4.15 Common│ │ ─BTDiaaler│ │ ├─BTDIALP│ │ -btecho│ │ ─BTENUM│ │ ─BTfilter│ │ ├─BTHEADSET│ │ ─BtaudioGw│ │ │ ─Bthsagw_ce│ │ ─BthsAGW_MDD│ │ │ ─HeadSetctl│ │ │ ─INC│ │ │ │ │ │ │ └─Talk│ │ ├─Bthlink│ │ ├-bthnscreate│ │ ├-btloader │ │ ─BTMODEM│ │ ─Btpair│ │ ├─BTSVC│ │ ├─Comtest│ │ ─TUNPORT│ │ ─FCTEST│ │ ├─GW│ │ ├-HcITEST│ │ ├─L2Capapi│ │ ├─L2Capdev │ │ ─Opttest│ │ ├─Phoneui│ │ ├─Printui│ │ ├─sca│ │ ─SDPComMon│ │ ─sdpprint│ │ ├─SDPSearch│ │ ├─Socktest│ │ └─SSA│ └ - TRANSPORTS│ ├─Ambicom│ ├─BCSP│ ├─SC│ ├─UART│ ├─Univ│ ├─USB│ └ --wss│ └ - inc This directory is about Bluetooth support, I have never seen it, it is not messy. said. ├─calibrui This directory is an example of a touch screen calibration. ├ --ceddk│ ├ --DDK_BUS│ ├ --DDK_DMA│ ├ --DDK_IO│ ├ --DDK_MAP│ ├─DDK_Time│ ├ - DLL│ └ - Test│ ├ --isaenum│ └ --PCIENUM Due to the hardware architecture of the embedded system, it is customized DDK needs to implement a generally operated hardware abstraction layer when DDK is required for other developers to use these general operations to control mounting devices, which typically include bus, DMA, IO, timer, etc. Resources, with this directory of an interface of a set of X86 DDK. ├ --Cerdisp│ ├ --Cerdisp│ ├─Cerhost│ └ - └c 远程 远 的 的 例 的. This remote display is the one in the WindowsCE characteristic. ├ - Display│ ├─Aablt│ ├─Ti│ ├─DDGPE│ ├─Dispperf│ ├─Emul│ ├─Emulstub│ ├─GPE│ ├─Gperotate│ ├─MQ200│ ├─NOPDisp│ ├─ PERM3│ ├LERM3_CFG│ ├─RFLAT│ ├─SWG│ ├─TVIA5000│ └─Vgaflat Display section is more, AABLT is an example of anti-aliasing, DDGPE is an example of GPE driver with DDRAW, Dispperf is a test A code of the driving efficiency, can be used in your own program. SWG is the source code of Microsoft Software Graphics Library, and I don't know if I haven't read it. Both MUL are all simulated graphics processing source code, as well as the source code of GPE, source code with rotational power.
The procedures you can say in the Display directory are not drivers, and should be considered some source code of the Windowsce GWES display section Although the complete code is not provided but can see the Windows Ce of the Windows Ce. The basic structure is still very research value, more, this and Winnt architecture is so similar: PNODISP is an example of a relatively special display driver, which meets the reuse of GDI but does not actually show, there is Perm3 啥I didn't want to understand it. RFLAT is under the display driver based on gperotate, you want to rotate your screen and don't want to change your hardware. As for Vgaflat is the driver used on the simulator. These drivers mentioned are the fastest display driver template. If you need to write a display driver, you can copy these code to keep the architecture and reinforce it, you can see Microsoft is doing these directory structures. It is still very thoughtful for everyone. These drivers are used on VESA BIOS 2.0 compatible graphics cards to say that the simulator can use these drivers. If you want to practice the display driver, there is no hardware support, you can use these driver tests. The rest of the remaining is a few specific graphics cards, and Perm3 is a relatively special driver, which is the only display driver that supports D3D in these drives. Although Microsoft recommends using these drivers as a reference to write code, I still recommend that you will re-implement the display driver of the XXFLAT mentioned above. ├THDBG│ ├─3C90X│ ├─AM79C970│ ├─Blcommon│ ├ --bootpart│ ├ --cs8900│ ├ - Dec21140│ --DP83815│ ├ - EBOOT│ ├─Edbgsamp│ ├-kitleth│ ├─NE2000│ ├─ RNE_MDD│ ├─RTL8139│ ├─SMC9000│ ├─SMSC100│ ├ --vbdgstub│ ├─Vbridge│ └ --VminiethDBG There is a lot of things, which is more comparative. Blcommon, bootpart, eboot is part of the components needed to write bootloader. We can see that the ebonot below Platform calls a lot of other functions, those functions are generated here, do not understand bootloader? The code will then look at the code together to see the results soon. Blcommon is the main proxidation code of Bootloader, bootpart is the code of the Bootloader HDD or Flash, mainly in the file system level, such as partition, what is included in eBoot is the implementation of network protocols such as TFTP and DHCP, but not Contains HAL code. KitLeth is unrelated to the hardware of the Ethernet Transport, including DHCP and UDP protocol. EDBGSAMP should be the implementation of TCP / IP Transport, the purpose is to implement debugging information channel through Ethernet card, and I have not verified this. 3C90X AM79C970 CS8900 DEC21140 DP83815 NE2000 RTL8139 SMC9000 SMSC100 is a drive code for chips, bootloader can use them as Ethernet and Kitl HAL but must distinguish these "drivers" with Windows drivers, these drivers are only available for use As the HAL used under the operating system, not the network card driver of the system network portion. RNE_MDD KitLeth VBDGSTUB VBRIDGE VMINI is about Kitl code, KitLeth is the Ethernet transmission implementation of Kitl, VBridge and VMINI are virtual bridges and NIC, which is the purpose of establishing Kitl Ethernet Transport while Windows can share Ethernet Transmission.
Vdbgstub is the simplest implementation of Vbirdge (unspeakable). RNE_MDD is MDD support for R-NDIS. Can be used with common / oak / drivers / rndisfn / net2890.├ - FSD│ ├─Encfilt│ ├─fatutil│ │ ├─main│ │ ├─NOUI│ │ └ ─ ││ ├─FSDSPY│ └─RegpartFSD Needless to say This is the file system driver, this is the upper driver independent of the specific hardware code. Fatutil provides a range of support, such as formatting, disk scanning such programs. Encrypted paths are provided in EncFill, and it is to be encrypted. FSDSPY is estimated to detect file systems, specific usage methods and uses are unknown. Regpart is an example of a partition driver, and the role is also a template. After building your own Partition driver, you can operate like calling mspart.dll. ├─GDCFG This is Generic Device Configuration is the code related to the PCI bus, and the code is approximately the purpose of bus equipment usually manages and control. Due to the lack of knowledge, I don't know what to do. ├─GiisrGeneric installable isr example. ├─Helper rumor is the code for registering the configured PCI device, and I don't know. ├─jpn ├ ─imejpp│ ├─commoncode│ ├ - Dicmake│ │ └ --bin│ └─IMeui These two directory are all related, or do not understand. ├─Irmac│ ├─INC│ ├─Irsir│ └─UTils infrared port driver. ├-keybd│ ├─DeviceLayoutS│ │ ├─PS2_at│ │ │ │ ├-00000411│ │ │ ─00000412│ │ │ └─00010411│ │ └─Remap│ │ └─NumpAdRMP│ ├─DLL │ │ ├─KBD8042JPN1│ │ ├─KBD8042JPN2│ │ ├─KBD8042KOR│ │ ├─KBD8042US│ │ ├─KBDNOPJPN1│ │ ├─KBDNOPJPN2│ │ ├─KBDNOPKOR│ │ └─KBDNOPUS│ ├─HIDIOCTL│ ├─INPUTLANGS│ │ ├-0409│ │ ├─0411│ │ └─0412│ ├─IST│ ├─Laymgr│ ├─NOP│ │ ├─PDD│ │ └─PDDLIST│ ├S2_8042│ └─Test keyboard driver and its test procedure. ├─lmemdebug This directory can use user code to perform memory detection, usually used to test memory leaks and debugging, interested in refer to the contents of the private / WinceOS / CoreOS / Core / LMEM directory. ├─MessageDialogboxcuStomize This is the famous MessageBox, you want your own messagebox? Easy, you can change this guy. ├ --mmtimer multimedia clock. ├ - RepisuionDis Usermode I / O Driver. Usage is unknown. ├ --Netcard│ ├ --DC21X4│ ├ --DP83815│ ├ - NE2000│ ├ --NE2000ISR│ ├ --Netmui│ ├─Rndismini│ │ ├─Host│ ├─SMSC100FD│ └─XIRCOM.CE2 This directory is the NIC driver. NE2000ISR corresponds to a plugin such that NE2000 local driver can work in IISR mode. Netmui is said to be a network multi-user support, it doesn't seem to have a support method.
Rndismini is the small-port driver of RNDIS, which is equivalent to a MDD that implements Microsoft Remote Ndis Specification. This program can be used to implement rNDis, and the RnDisfn directory is equivalent to PDD, Host Directory below this program with the PCI-USB interface under the RNDISFN directory. The following thing is the installation information file required on the PC when using RNDISFN as a PDD, and the other required RNDIS-USB Kit can be under Microsoft's website. ├─NETSAMP│ ├─ASYNCMAC│ ├─Autoras│ │ ├─DLL│ │ └─test│ ├─Connmc│ ├─Thman│ ├─ in ─ ─ipconfig│ ├ ─ p at │ └─EditsAmp│ ├─IPv6Tun │ ─Disconfig│ ├─NDISPWR│ ├─NetStat│ ├─Passthru│ ├─PEGTERM│ │ ─App│ │ └ -Termctrl│ ├ --Ping│ ├─RasDial│ ├-Rasentry│ ├─RASSERVER│ ├─RNAPP │ ├ROUTE│ ├─TapiHelp│ ├─Tracert│ ├─WZCTool│ └─ZCLOG This directory includes some examples and tools of the entire range of all levels from top to bottom, ping netstat route tracert ipconfig One is a network tool that everyone is familiar with. Other, I am not very clear. ├─NETUI This directory is the UI relating to the network, such as the network option inside the control panel, the connection icon appears in the status bar, and more. ├─OOomuioomui is out of memory user interface ... What is displayed when memory overflow? Just here. By the way, all directories ended in UI are part of customizable UI. ├ --Parallel There is a parallel port module-driven code, and an example of using the module to generate parallel-port drivers. ├─PCIBUS This directory is the code related to the PCI bus, and I don't know if I don't know. ├ --PCMCIA│ ─i82365│ ├─MDD│ ├─test│ │ ├─DevTuple│ │ └ --TupletSt│ ├─Ti1250│ └ - Ti1250ISR, MDD is the module driver of PCMCIA, and the other I82365 and Ti1250 are using modules Examples of driving construction drivers, Ti1250ISR is driven by Ti1250 driver IISR.├pm│ ├─Battery│ ├─MDD│ ├─PDD│ │ - DEFAULT│ │ └─PDA│ ├─PMstubs│ └ - Test│ ├─ Devsample│ ─Get│ ├─Getd│ ├─Mon│ ├─REQ│ ├─Set│ └ -Setdpm is Power Management, which contains battery-driven. PM Device module driver, Test is also an example of using module drivers. The PDD directory is the platform-related driver code. ├─printer│ ├ --PCL│ ├─Prner│ └ --Prnport looks like a printer related drive, the specific content is unknown. CAINUM ELECTOR MEGER registry enumerator, the content in this directory can generate a regenum .dll, the link library is loaded by the device manager and determines how to use the information of the registry to load the driver, so there is a need to order the link library in many cases (different load modifications determined by hardware), so that it can be correct Load driver. ├ --Rndisfn│ └ --NET2890 uses 2890 to establish an example of R-NDIS. ├─SamptspitAPI implementation sample.
├Serial│ ├─2890_ser│ ├ --com16550│ ├ --com_card│ ├─Com_mdd│ ├─Com_MDD2│ ├─ISR16550│ ├─Ser16550│ ├ --ser_card│ └ --ser_card2 This directory is a serial driver example, 2890_ser is to use the USB port to imitate the behavior of ordinary serial ports, which can be connected to the desktop PC via RAS, which is the most popular usage. Many ARM series processor BSP is implemented as a serial-unimoden for USB Function. In the form of the desktop, the desktop can be found in the activeSync directory, just need to modify the driver installation information file, so this drive is for the implementation of ActiveSync, if you need to implement the USB to RNDIS, the driver is not referred to. It is the code in this directory but the corresponding code under RNDIS, further if you need to use the device for your custom features
