Author: Mike Hall Source: Microsoft Windows CE .NET file system is a flexible modular design, which allows custom file systems, filters, and a variety of different types of block devices. File systems and all file-related APIs are managed by the FileSys.exe process. This module implements the object storage and storage manager (we will discuss object storage a little) and unify all file systems into a single system below. In Windows CE .NET, all files and file systems exist in a single namespace from "/" as the root start. All files are identified from the unique path starting from the hierarchy tree. This is similar to the desktop computer version of Windows, just without the drive letter. In Windows CE, the driver is used as the file clamp. Therefore, the new memory card added to the system will be loaded into the root of the tree, and its path is similar to "/ storage card". Filesys.exe consists of the following components:
• ROM file system • Storage Manager • Object storage object storage is a memory, controlled by FileSys.exe. Object storage includes RAM system registry, RAM file system, and attribute database. They are optional components of the FileSys.exe module. The RAM file system and attribute database are completely optional and can not exist at certain systems. For each Windows CE device, the registry existing in some form is required. It is always residing in object storage until 4.0 version of Windows CE. Using Windows CE .NET, it can be used as a file system (e.g., a disk) that exists outside. Subsequently, we will understand how the registry and file system generates contact. RAM-based file system is typically connected to the root of the unified file system presenting to the application. That is, the file "/myfile.txt" is located in the root of the unified system and the root of the RAM file system. The ROM file system is connected to the "/ windows" folder in the Unified File System. This means that all files in the ROM can be accessed as read-only files in the / windows folder. Storage Manager is a new feature of Windows CE .NET. As indicated by the name, it is responsible for managing storage devices in the system, as well as file systems used to access them. Storage Manager handles 4 main items:
• Store drivers. They are the device driver of physical storage media. They are sometimes referred to as "block drivers" because they provide access to the random address block for data storage. • Partition driver. They provide management for multiple partitions on a single storage device. Windows CE .NET allows the physical disk to include multiple partitions, and each partition can be formatted as different file systems. The partition driver is actually a converter that stores the driver. It discloses the same interface as the storage driver and converts the block address of the partition to the real address of the storage device block. Then it passes the call to the storage driver. • File system driver. These drivers will organize data on the storage device as files and folders. Several different systems are included in Windows CE .NET, including UDFS for CD and DVD, and FATFS (including FAT32 support). In version 4.2, there is a new system called transaction security FAT file system (TFAT). (We may discuss it in future articles; Similarly, if you are interested, please tell us.) • File System Filter. File System Filter is used to process calls to file systems. Since then, file systems can get these calls. This allows some special processes to file access to monitor data encryption, compression, and use statistics. As the proverb said, it is better to see it, and the figure below illustrates the relationship between the various components of the file system. Figure 1. Windows CE file system overview
For this structure, an important thing to note is that the file system filter is operating under the storage manager and cannot be applied to the ROM file system or RAM file system in object storage. At this point, Microsoft does not provide a filtering mechanism for the screening of these systems. Therefore, in this article we will focus on the contents of the right side above. In order to make you see more clearly, the following figure enlarges this area.
Figure 2. Storage manager and related components
As can be seen in the above figure, not all file system drivers use physical devices, even if they are used, may not use partition drivers. This provides huge flexibility. For example, responsible for providing network redirements for network sharing access Use Winsock communicate with remote servers through the network, and it does not have a physical disk on the Windows CE device. Since we can see what most items are, and how they are interrelated, we will discuss how the system loads all. When the operating system starts, NK.exe will load Filesys.exe directly from the ROM file system. Then, FILESYS.EXE initializes the registry from the default registry within the ROM file system. (Here, there is a problem like "first with chicken or first egg" when using the configuration unit registry, because the registry is in the file on the disk, and the file system has not been put. In the subsequent article introduction When the unit registry, we will introduce how the operating system solves this problem.) Then, FileSys.exe will read the registry key to start a variety of applications. First listed in the registry is usually Device.exe, ie equipment manager. Device Manager loads the driver from the HKEY_LOCAL_MACHINE / DRIVER / Builtin item. Normally, any built-in disk device (eg, hard disk) is listed under this item, so the block driver will be loaded. Block driver advertises a specific device class identifier Block_Driver_guid {a4E7EDDA-E575-4252-9D6B-4195D48BB865}. The Storage Manager built into FileSys.exe notifies the device manager to register to receive a notification of the block driver loading and uninstall. Then, the Storage Manager opens the block driver and queries the configuration file name. Each block device type has a profile related to it. Profile is a registry key to specify partition drivers and default file systems for specific types of devices. (We will introduce the details of the registry key of the profile.) The Storage Manager reads the information about the partition driver of the device and loads the appropriate driver. (Microsoft provides a partition driver called "MSPAR" for standard hard disk partitioning through partition tables in the main start record of the disk. Of course, you can create your own partitions casually if you need it. Using it.) Once the partition driver is loaded, then the Storage Manager will request a partition on the partition driver enumeration disk and identify the file system on each partition. The partition driver reads information about the partition and file system from the main start record (MBR), and provides information to the storage manager, then the storage manager uses this information to load the file system driver for each partition, and Put the file system into the root of the unified file system. Although this seems to have many steps, it allows you to flexibly support network redirector FATFS and DVD ROM in the same framework. After understanding how Filesys.exe loads the steps of various components, we will introduce the role of the File System Driver and File System Driver Manager (FSDMGR) in more detail. FSDMGR is part of the Storage Manager (which is part of the device manager in the previous version), which is responsible for providing a service to the file system driver. Because the file system will not need to know whether the data comes from the partition on the disk, or directly from the disk, FSDMGR is packaged for the file system driver to provide an interface for the high or low end of the driver. The following figure shows how this works. Figure 3. Storage Manager
Storage Manager calls the file system driver (FSD), and FSD retrieves data from the device using the FSDMGR_ API. If it is a CD (no partition), the device communicates with the block driver via FSDMGR. If it is a hard disk with multiple partitions, then it uses the FSDMGR_ API in the same way. But then FSDMGR will transfer the work to the appropriate partition driver. We have discussed how to interact and interoperate how the storage manager, FSDMGR, FSD, partition driver, and block drivers are interactive. Let us go back to discuss how they are loaded and examine the details of the configuration files in the registry. As mentioned earlier, the configuration file is just a set of registry values, used to define block devices and how to use it in the system. The configuration file is below the following: HKEY_LOCAL_MACHINE / SYSTEM / StorageManager / Profiles Each configuration file is an item located below the basic configuration file item, which is identified by this configuration file name. For example, if there is a hard disk on the Windows CE .NET device, and it does use a hard disk configuration file, the configuration file is located in HKEY_LOCAL_MACHINE / System / StorageManager / Profiles / Hard Disk. All configuration file information is included in the named value below this configuration file item. The following table lists various values and its purpose. Table 1. Profile Registry Item Value Type Description Folder REG_SZ Displays the folder name to the user in the Windows Explorer. For multiple instances, an integer will be automatically added. (For example, Storage Card, Storage Card2, etc.) FileSystem REG_SZ is used as the name of the default file system for disk. (If you use a partition driver, it is usually not used.) PartitionDriver REG_SZ lists the partition drivers to use if the default driver is not suitable. If the string is empty, no partition driver is loaded. If this value does not appear, use the default partition driver. AutoFormat REG_DWORD If the disk is not formatted, automatically perform formatting autopart reg_dword If the disk is not partition, it automatically partitions it, and one of the partitions occupies the maximum number of available disk space. Automount Reg_dword When the storage device driver is loaded, the file system is automatically loaded. Name REG_SZ is displayed in the Configuration File Name in the Control Panel UI. MountFlags REG_DWORD is used to determine how to load the file system. (For more information, see the following table.)
Need special attention to the mountflags value. It is a bit mask of the value in the table below. Table 2. Sign of MountFlags registry key
Sign Description 1 Hide file system. 2 You can include a configuration unit registry. 4 is loaded as the root of the file system ("/"). 8 Hide the ROM file system. (Only used with [4].)
Tag file system as hidden can prevent it from being discovered by any standard files and folder enumerations. (For example, FindFirstFile, etc.) The Storage Manager completes this action independently, so that the device driver and application can detect if a specific system is using the storage manager. (Due to the older version of the operating system without it, some drivers may need to be compatible with the old LOADFSD (EX) mechanism for loading file systems.) Although findfirstfile can be used to enumerate any hidden system, If you know the name of the file system, you can use it anywhere using the file path. The following example shows how to detect whether the storage manager is using a system. Bool isstorageManagerrunning ()
{
DWord Attr = getFileAttributes (_t ("// storemgr"); if ((attr! = -1) && (attr & file_attribute_temporary))
Return True;
Return False;
}
The next indicator file system of MountFlags can contain a registry based on the configuration unit. This allows FileSys.exe to manage the "first chicken or first egg" previously mentioned. (Because you need to register to load the access to the component you need to configure the unit file on the disk ...) We will introduce how to use this bit in the subsequent document registry. The latter two is related, when you want to use the external file system as the root of the unified file system, you need to use them. It can be recalling that the root of the general unified system is the RAM file system. This is very effective for the handheld device of the battery, but the equipment that is sometimes powered by the AC power supply, because the RAM content will be lost each time it is closed. The load file system as a root flag allows you to avoid this problem by connecting external storage as the root, because this, file /mydatafile.txt will reside in the root of the external storage device. Hide the ROM file system hides the ROM file system data file (but does not perform the appropriate EXE and DLL) so that you update all the files in the ROM. This allows you to use a very small operating system image in flash memory, and placing most executables on the disk, only load them only when needed. (It's a very similar desktop computer system.) If any of the values of a specific configuration file does not exist, the Storage Manager will use the default value in the HKEY_LOCAL_MACHINE / System / StorageManager / PROFILES item. The default value that can be rewritten is located in Common.REG. You should rewrite your Platform.Reg or Project.REG. (Remember, there should not change the common.reg!) The following table shows the default value in Common.Reg.
Value default value Folder Loc_Store_Default_folder (for the identifier of a string in the device. String in English), is usually "Storage Card" in English.) FileSystem Fatfs PartitionDriver Mspart.dll Autoformat 0 AutoPart 0 Automount 1 MountFlags 0
Small knot Windows CE file system architecture is flexible and scalable and support:
• Multiple block devices. • Each block device supports multiple partitions. • Each partition supports different file systems. • Load the external device file system as the root system. The registry is the key to the process of loading and running a file system with the correct (or expected) behavior. The registry based on the configuration unit does help us. In order to make you no longer generate fear, we will use some real examples in subsequent articles to examine the configuration unit registry. But now, we have to end the discussions this month.
