Method and device for accessing hardware equipment in compatible layer environment and electronic equipment

Abstract

The invention discloses a method and device for accessing hardware equipment in a compatible layer environment and electronic equipment, and belongs to the technical field of computers. The method specifically comprises the steps that after an insertion event of hardware equipment is monitored, equipment information of the hardware equipment is acquired; according to a data storage specification of Windows, registry items of the hardware equipment are generated in a simulation registry conforming to an interface behavior specification of Windows; the registry item comprises equipment information of the hardware equipment; determining and loading a driver of the hardware equipment according to the equipment information of the hardware equipment; according to a registry entry of the hardware equipment, providing equipment information of the hardware equipment for the Windows program, so that the Windows program generates an access request for the hardware equipment based on the equipment information; and processing the access request by utilizing the drive of the hardware equipment. According to the method, the problems of identification errors and abnormal operation occurring during operation by means of Wine in the Linux operating system are solved.

Description

Technical Field

[0001] This application belongs to the field of computer science, and specifically relates to a method, apparatus and electronic device for accessing hardware devices in a compatibility layer environment. Background Technology

[0002] Wine (not an emulator) is a compatibility layer software that enables Windows applications to be ported to Linux systems. Because Wine translates Windows API (Application Programming Interface) calls into dynamic POSIX (Portable Operating System Interface) calls, it allows Windows programs to run on operating systems other than Windows.

[0003] Currently, Wine typically simulates the IO (Input / Output) communication mechanism of the Windows system to enable interaction between Windows programs and hardware devices, allowing users to have the same experience as using Windows programs on a real Windows system.

[0004] In implementing the embodiments of this application, the inventors discovered that some hardware devices that can be normally recognized and run stably in Windows systems may experience recognition errors or operational abnormalities when running on a Linux operating system using Wine. For example, a high-speed document scanner that works normally under Windows may fail to function properly when connected to a Linux system running Wine. Summary of the Invention

[0005] The purpose of this application is to provide a method, apparatus, and electronic device for accessing hardware devices in a compatibility layer environment, which can solve the problem of recognition errors or abnormal operation of hardware devices when running on a Linux operating system with the help of Wine.

[0006] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a method for accessing hardware devices in a compatibility layer environment, wherein the compatibility layer environment is an environment running Windows programs under Linux, and the method is applied to compatibility layer software, the method comprising: After detecting the insertion event of a hardware device, the device information of the hardware device is obtained; According to the Windows data storage specification, a registry entry for the hardware device is generated in a simulated registry that conforms to the Windows interface behavior specification; the registry entry includes: device information of the hardware device; Based on the device information of the hardware device, determine and load the driver of the hardware device; Based on the registry entries of the hardware device, the Windows program is provided with device information of the hardware device, so that the Windows program generates an access request for the hardware device based on the device information. The access request is processed using the driver of the hardware device.

[0007] Secondly, embodiments of this application provide a device for accessing hardware devices in a compatibility layer environment, wherein the compatibility layer environment is an environment that runs Windows programs under Linux, and the device is applied to compatibility layer software. The device includes: The information acquisition module is used to acquire device information of the hardware device after detecting the insertion event of the hardware device; The registry generation module is used to generate registry entries for the hardware device in a simulated registry that conforms to the Windows interface behavior specification, according to the Windows data storage specification; the registry entries include: device information of the hardware device; The driver determination and loading module is used to determine and load the driver of the hardware device based on the device information of the hardware device. A module is provided to provide device information of the hardware device to the Windows program based on the registry entries of the hardware device, so that the Windows program can generate an access request for the hardware device based on the device information; The access request processing module is used to process the access request using the driver of the hardware device.

[0008] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0009] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0010] In this embodiment, after detecting the insertion event of a hardware device, the compatibility layer software generates a registry entry for the hardware device in a simulated registry that conforms to the Windows interface behavior specification, according to the Windows data storage specification. Since this registry entry provides standardized device information for Windows programs, the Windows programs can generate access requests based on this standardized device information, allowing the hardware device to run stably in the compatibility layer environment. This effectively solves the identification errors and runtime anomalies that occur when using Wine in the Linux operating system. Therefore, this embodiment improves the compatibility and stability of Windows programs accessing hardware devices in the compatibility layer environment, enabling cross-system Windows programs to interact with hardware devices as smoothly as in the native environment, reducing device access barriers caused by operating system differences.

[0011] Furthermore, in this embodiment, the driver for the hardware device is determined and loaded based on the device information, and the access request is processed using the driver. Since a suitable driver can be accurately determined and loaded based on the device information, and the access request can be effectively processed through this driver, this embodiment can further reduce the probability of hardware device malfunctions in a compatibility layer environment, and reduce device access failures caused by driver incompatibility or processing anomalies. Attached Figure Description

[0012] Figure 1 This is a flowchart illustrating the steps of a method for accessing a hardware device in a compatibility layer environment according to an embodiment of this application; Figure 2 This is a flowchart illustrating a hardware device access method in a compatibility layer environment according to an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a method for accessing a hardware device in a compatibility layer environment according to an embodiment of this application; Figure 4 This is a structural block diagram of an apparatus for accessing a hardware device in a compatibility layer environment according to an embodiment of this application; Figure 5 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0014] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0015] The following description, in conjunction with the accompanying drawings, details the method, apparatus, and electronic device for accessing hardware devices in a compatibility layer environment provided by the embodiments of this application, through specific implementations and application scenarios.

[0016] In this embodiment of the application, in the field of computers, hardware devices refer to the sum of physical components that constitute a computer system and can be physically touched or sensed. They are the material basis for the operation of computer software and the physical carrier for the computer to interact with the external environment and execute computational and control instructions. Hardware devices may include: external devices. An external device is a hardware device connected outside the computer host, used for inputting, outputting, or storing data, and is an important component of the computer system. Examples of hardware devices may include: hard drives, cameras, document scanners, and USB keys (Ukeys).

[0017] Based on communication protocols and interfaces, hardware devices can be categorized as follows: SCSI (Small Computer System Interface) devices, SATA (Serial Advanced Technology Attachment) devices, and USB (Universal Serial Bus) devices. Here, "communication protocol" and "communication interface" are not mutually exclusive but rather complementary, together forming the standard for classifying hardware devices. In many cases, a specific communication interface is adapted to a specific communication protocol.

[0018] A USB Key is a hardware device based on a USB interface, with a built-in smart card chip or microcontroller, used to store user private keys, digital certificates, and identity authentication information.

[0019] To address the technical problem of hardware devices experiencing identification errors or operational anomalies when running on a Linux operating system using Wine, this application provides a method for accessing hardware devices in a compatibility layer environment. The compatibility layer environment is an environment where Windows programs run under Linux. The method is applied to compatibility layer software and specifically includes: after detecting a hardware device insertion event, obtaining the device information of the hardware device; generating a registry entry for the hardware device in a simulated registry conforming to Windows interface behavior specifications according to Windows data storage specifications; the registry entry specifically includes the device information of the hardware device; determining and loading the driver of the hardware device based on the device information; providing the device information of the hardware device to the Windows program based on the registry entry, so that the Windows program generates an access request for the hardware device based on the device information; and processing the access request using the driver of the hardware device.

[0020] In this embodiment, the compatibility layer software, upon detecting a hardware device insertion event, generates a registry entry for the hardware device in a simulated registry conforming to Windows' interface behavior specifications, according to Windows' data storage specifications. Since this registry entry provides standardized device information to Windows programs, the programs can generate access requests based on this standardized information, allowing the hardware device to operate stably in the compatibility layer environment. This effectively solves the identification errors and runtime anomalies that occur when using Wine in the Linux operating system. Therefore, this embodiment improves the compatibility and stability of Windows programs accessing hardware devices in the compatibility layer environment, enabling cross-system Windows programs to interact with hardware devices as smoothly as in the native environment, reducing device access barriers caused by operating system differences.

[0021] Furthermore, in this embodiment, the driver for the hardware device is determined and loaded based on the device information, and the access request is processed using the driver. Since a suitable driver can be accurately determined and loaded based on the device information, and the access request can be effectively processed through this driver, this embodiment can further reduce the probability of hardware device malfunctions in a compatibility layer environment, and reduce device access failures caused by driver incompatibility or processing anomalies.

[0022] In this embodiment of the application, compatibility layer software refers to intermediate layer software that, on the Linux operating system, simulates the APIs and behaviors of the Windows system (such as registry operations and system file structure interactions) to provide an adaptable runtime environment for Windows programs to support their operation on the Linux system.

[0023] The compatibility layer software in this application embodiment can be existing compatibility layer software. After improving the existing compatibility layer software, the improved compatibility layer software can execute the method of this application embodiment to achieve compatibility between Windows programs and hardware devices.

[0024] The compatibility layer software in this application embodiment can also be newly created. The newly created compatibility layer software can execute the methods in this application embodiment, thereby achieving compatibility between Windows programs and hardware devices.

[0025] The compatibility layer software in this application embodiment has the following functions: First, the compatibility layer software in this application embodiment can recognize and load the EXE (Executable File) and DLL (Dynamic Link Library) of Windows programs, and create a Windows-like runtime environment in the Linux environment to support the normal operation of Windows programs in the Linux system.

[0026] The process of identifying and loading executable files and dynamic link libraries for Windows programs: a. File format recognition: First, by analyzing the file header (e.g., the file header of a PE (Portable Executable) file), we can identify whether the input file is a valid Windows executable file.

[0027] b. Resolve dependencies: Locate the DLL files that the PE file depends on through the ImportTable in the PE file.

[0028] c. Dynamic linking: Load dependent DLL files one by one and resolve symbols in the dynamic link symbol table.

[0029] d. Load memory image: Allocate memory for EXE and DLL, map them to appropriate memory locations, and adjust the relocation table to ensure the correct operation of Windows programs.

[0030] Second, the compatibility layer software in this application embodiment can parse the structure of the executable file of a Windows program, identify the dependencies of the Windows program, and determine the location of the executable code.

[0031] (1) Parsing PE files: a. DOS Header (Disk Operating System Header): Check the Magic Number (0x5A4D, i.e., MZ) to determine the validity of the PE file.

[0032] b. PE signature: If a PE signature of PE\0\0 exists, it means that the file is in PE format.

[0033] c. Section table analysis: Code segment: Usually marked as .text (text segment), it contains executable code.

[0034] Data segment: such as .data (data segment) and .rdata (read-only data segment), stores global variables and read-only data.

[0035] Import table: Records external functions and libraries that require dynamic linking.

[0036] (2) Identify the dependencies of Windows programs: a. Import Table: Reads the DLLs to be imported and their function names one by one.

[0037] b. Locate dependency paths: Locate dependency files through environment variables (such as PATH (PathEnvironmentVariable)).

[0038] (3) Determine the location of the executable code: a. Entry point address: The code entry point is determined based on the AddressOfEntryPoint field in the OptionalHeader of the PE file header.

[0039] b. Memory mapping: Linux's MMAP (Memory Map Function) is used to map executable code segments to virtual memory.

[0040] Third, in the embodiments of this application, the compatibility layer software jumps to the entry point of the Windows program, which is usually RtlUserThreadStart() (user thread start function), which is the user space entry point of the Windows program.

[0041] (1) User space entry point for Windows programs: a. The entry point of a Windows program is specified by AddressOfEntryPoint in the PE file and is mapped to Linux virtual memory.

[0042] b. The entry point is the starting point of the Windows user thread. The user thread startup function is responsible for initializing the thread and calling the main function of the Windows program.

[0043] (2) Execution process of compatibility layer software: a. Load and initialize ntdll.dll (NT Layer Dynamic Link Library): The compatibility layer software provides a custom ntdll.dll implementation to replace the native Windows library.

[0044] b. Set up the runtime environment: Initialize the stack, registers, etc., to simulate the Windows thread environment.

[0045] c. Jump to the entry point: After setting appropriate memory permissions using Linux system calls (such as memory protection functions), jump to the user thread startup function via code.

[0046] (3) The compatibility layer software has optimized modules such as user32 module and win32u module, which has improved the display effect of windows and resolved some anomalies.

[0047] The user32 module is primarily responsible for high-level user interface functions, such as creating and managing windows, processing user input messages, and managing menus. The win32u module focuses on low-level graphics processing and display-related functions, such as interacting with the graphics card and implementing drawing primitives, providing low-level support for the presentation of the user interface.

[0048] In one implementation, the following processing steps can be added to the user32 module: Step A1: Create the window of the Windows program according to the window creation request of the Windows program; Step A2: Generate a window settings request based on the window attribute parameter values ​​in the window creation request; Step A3: Configure the window of the Windows program according to the window setting request so that the window of the Windows program conforms to the window attribute parameter values.

[0049] Steps A1 to A3 above can solve window display problems such as Windows program windows not being able to be placed on top or windows not being able to be maximized.

[0050] Step A1 creates a window for the Windows program based on its window creation request, establishing the basic entity of the window. Step A2 extracts the window attribute parameter values ​​(such as whether it needs to be pinned to the top or whether it supports maximization) from the window creation request and generates a specific window settings request to clarify the specific direction of window adjustments. Step A3 then configures the created window according to the generated window settings request, ensuring that the actual state of the window matches the attribute parameter values ​​required by the Windows program, thereby resolving display problems caused by mismatched attribute configurations, such as the window being unable to be pinned to the top or maximized.

[0051] Fourth, the compatibility layer software in this application embodiment uses the ntdll.dll and ntdll.so (NTLayer Shared Object) libraries to handle system calls, converting Windows system calls into Linux system calls.

[0052] (1) The functions of ntdll.dll and ntdll.so: a. ntdll.dll: This is the bridge for Windows user-mode programs to access kernel-mode functions.

[0053] b. ntdll.so: This is a Linux shared library implemented by the compatibility layer software. It simulates the functionality of ntdll.dll and maps Windows system calls to Linux.

[0054] (2) System call conversion mechanism: a. Capture Call: When a Windows program calls a system API, it will eventually go through the system call interface of ntdll.dll.

[0055] b. Mapping to Linux system calls: The ntdll.so implementation in the compatibility layer software translates Windows calls into corresponding Linux calls. For example, when a Windows program requests to open a file via NtOpenFile (the NT Open File Function), the ntdll.so implementation in the compatibility layer recognizes this call and translates it into the corresponding open() (Open Function) call in the Linux system, enabling the Linux system to understand and execute the file open operation. If Linux does not have a direct corresponding function, the compatibility layer software will simulate it through an intermediate layer.

[0056] c. Return result: Convert the return value of the Linux call to Windows format and return it to the Windows program.

[0057] Fourth, the compatibility layer software of this application handles calling conventions, such as stack space allocation and register movement, and enables Windows programs to correctly execute system calls in a Linux environment.

[0058] In computer programming, a calling convention refers to the agreement between the caller and the callee regarding parameter passing, return value handling, and register usage during function calls. It specifies the concrete details of function calls to ensure that functions are correctly called and executed, and that the program can continue execution correctly after the call ends.

[0059] (1) Calling convention conversion: a. Windows uses different calling conventions (such as stdcall or fastcall), while Linux typically uses syscall or cdecl.

[0060] b. The scheduler ensures that the call complies with the requirements of the Linux kernel by adjusting the stack layout and register parameters.

[0061] (2) Stack space allocation: Allocate independent stack space for each thread and adjust the stack top address to suit the needs of Windows programs.

[0062] Threads are the core execution units of Windows programs. When a Windows program starts, it will generate a main thread by default, which is responsible for executing the initial logic (such as creating windows, processing user input, displaying the interface, etc.). If multiple tasks need to be completed at the same time, sub-threads will be created to divide the work.

[0063] (3) Register movement: a. Adjust register values, for example, map Windows-specific registers to equivalent Linux registers.

[0064] b. Handling compatibility between floating-point registers and vector registers.

[0065] Fifth, the compatibility layer software in this application's embodiments modifies the Linux base library based on the Windows execution standard to achieve smooth protocol layer conversion, widely adapting to various types of hardware devices and services, including printers, scanners, network devices, and high-performance hardware devices. Through comprehensive protocol layer conversion, the technical solution of this application provides strong technical support for cross-platform compatibility.

[0066] (1) The core mechanism of protocol layer conversion: a. Analysis of differences between Windows and Linux standards: In-depth study of the differences between Windows API and Linux base libraries to determine the conversion logic at the protocol layer.

[0067] b. Intermediate Abstraction Layer Implementation: A custom intermediate layer is used to encapsulate the Windows API interface, enabling it to be called based on Linux libraries and simulating the behavior required by the Windows environment.

[0068] (2) Dynamic loading and registry simulation: a. Dynamically loading device drivers and dependency libraries: The compatibility layer software in this application embodiment loads the hardware device driver.

[0069] In the first scenario, the hardware device driver is a Windows driver. This is because Windows drivers are written according to the Windows system architecture and interface specifications, which are incompatible with Linux systems. The compatibility layer software loads the Windows driver and utilizes the device interfaces provided by the Linux system, such as the / dev (device) file system or sysfs (system file system), to map the Windows driver's requests to the device port to the actual device port in the Linux system, thereby enabling the Windows driver to call the hardware device in the Linux environment.

[0070] For example, when using a Windows printer driver in a Linux environment, the compatibility layer software pre-establishes a mapping rule between the Windows printer driver's request port and the printer's actual hardware port. After reading the port request (containing printing data and control commands) issued by the Windows printer driver, the compatibility layer software will forward the request directly to the actual hardware port according to this mapping rule, thereby realizing data transmission and command control.

[0071] In the second scenario, the compatibility layer software loads the hardware device driver into the Linux kernel space. In this case, the hardware device driver follows the Linux kernel's interface specifications and operating rules, and can run normally in the kernel, thus enabling control of the hardware device.

[0072] b. Registry Mechanism Extension: In Windows systems, device and service configuration information is typically stored in the registry. The compatibility layer software in this embodiment provides a unified configuration access interface through a registry emulation mechanism, writing device and resource information from the Linux environment into a simulated registry for use by Windows programs.

[0073] (3) Unified device compatibility: a. Port and protocol mapping: The port mapping mechanism converts the ports of Linux devices into the ports required by Windows drivers or Windows programs.

[0074] During port translation, the compatibility layer first obtains the port information of the Linux device, including port type and data transmission format. Then, it repackages and adjusts this port information according to the port specifications followed by Windows drivers or programs. For example, it converts the data structure of the port information into a format compliant with Windows standards. In this way, when Windows drivers or programs access the device, they can directly recognize and use these translated ports, thus achieving port compatibility between Linux devices and Windows programs.

[0075] For network devices, compatibility layer software can map the Linux network stack to the Windows network API. Examples of Linux network stacks can include TCP / IP (Transmission Control Protocol / Internet Protocol), and examples of Windows network APIs can include Winsock (Windows Sockets Interface).

[0076] b. Hardware driver interoperability: The compatibility layer software loads the hardware device driver by parsing the INF file (Information File) and determines the compatibility of the INF file with the hardware device by checking the device information of the hardware device.

[0077] For devices where no native driver is found, the compatibility layer software provides a virtual driver to simulate its basic functions. This virtual driver intercepts access requests from Windows programs, translates Windows API calls into accesses to Linux device files, maps the control commands in the access requests to equivalent Linux kernel instructions, and finally submits the request to the kernel subsystem via a system call. This provides transparent device access capabilities to upper-layer applications without relying on real hardware drivers.

[0078] (4) Cross-platform service support expansion: a. File system adaptation: The compatibility layer software maps the Windows path structure to the Linux path through a path translation mechanism.

[0079] Features that support the Windows file system will run on file systems such as Linux's ext4 (Fourth Extended File system).

[0080] b. Service compatibility implementation: Compatibility layer software extends the support of specific devices and services by simulating the operation of Windows services (such as print services and smart card services) in a Linux environment.

[0081] c. Network protocol stack conversion: The compatibility layer software translates Windows network API calls into Linux network service calls.

[0082] (5) Dynamic monitoring and status management of multiple devices: a. The compatibility layer software implements dynamic monitoring services for hardware devices, tracking device connections, disconnections, or status changes, and updating the device list.

[0083] b. Each hardware device's operation request is processed through a threading mechanism, achieving efficient multi-tasking support.

[0084] c. Use interfaces such as DeviceIoControl (device I / O control functions) to dynamically synchronize device status, and simulate the interaction between the registry and service queue to ensure that the latest status of the hardware device is reflected in the Windows program in a timely manner.

[0085] DeviceIoControl is a Windows API used to pass control commands and data between Windows programs and hardware device drivers, enabling low-level operations on the hardware devices. Specifically, in practical applications, Windows programs need to interact with the hardware device drivers through DeviceIoControl if they want to read device status, configure device parameters, or execute specific device functions.

[0086] The following specific embodiments illustrate the method for accessing hardware devices in a compatibility layer environment according to the present application.

[0087] Reference Figure 1This document illustrates a flowchart of a method for accessing a hardware device in a compatibility layer environment according to an embodiment of this application. Specifically, the compatibility layer environment is an environment where Windows programs run under Linux. The method is applied to compatibility layer software and includes the following steps: Step 101: After detecting the insertion event of the hardware device, obtain the device information of the aforementioned hardware device; Step 102: According to the Windows data storage specification, generate registry entries for the aforementioned hardware device in a simulated registry that conforms to the Windows interface behavior specification; the aforementioned registry entries specifically include: device information of the aforementioned hardware device; Step 103: Based on the device information of the aforementioned hardware device, determine and load the driver for the aforementioned hardware device; Step 104: Provide the Windows program with the device information of the hardware device based on the registry entries of the hardware device, so that the Windows program can generate an access request for the hardware device based on the device information. Step 105: Process the access request using the driver of the aforementioned hardware device.

[0088] In step 101, the udev (user space device manager) daemon process can be used to monitor uevent (device event) events sent by the Linux kernel in real time (such as hot-plug events generated by hardware insertion), thereby detecting the insertion of hardware devices.

[0089] After detecting the insertion event of a hardware device, the device's property file can be accessed in the Linux system's virtual file system according to the device path provided by the user-space device manager, and the device information of the hardware device can be read from the property file.

[0090] In a specific implementation, device information may include: manufacturer information and / or product information.

[0091] For example, vendor information may include: VID (Vendor ID). A VID is a unique identifier assigned to a hardware device manufacturer by the Universal Serial Bus Implementers Forum. Globally, each hardware device manufacturer's VID is unique and cannot be duplicated.

[0092] Product information may include: PID (Product ID). The PID is an identifier assigned by the hardware manufacturer to each product model it produces.

[0093] Of course, those skilled in the art can also use equipment information other than manufacturer information and / or product information, such as product batch information, according to actual application needs.

[0094] In step 102, Windows data storage specifications refer to the rules governing data storage formats, organizational structures, storage locations, and access permissions within the Windows system. Windows interface behavior specifications are unified standards within the Windows system for interface calling methods, parameter passing, return result formats, and exception handling.

[0095] Simulating the registry requires adherence to both Windows data storage specifications and Windows interface behavior specifications. Windows data storage specifications define the storage format (such as strings and binary values), hierarchical structure, and key-value pair organization of device information. Windows interface behavior specifications, on the other hand, constrain the interface call logic for registry key creation, reading, and writing operations, allowing Windows programs to access hardware device information natively.

[0096] In the specific implementation, the acquired device information can first be converted into a data format that conforms to the Windows data storage specification (such as the registry string type), and the corresponding registry path can be determined. Then, in the simulated registry, registry entries are created according to the calling process of the Windows interface behavior specification, and the converted device information is written to the corresponding registry path in the form of key-value pairs.

[0097] In step 103, based on the operating system environment corresponding to the hardware device driver, the hardware device driver can be divided into Windows driver and Linux driver (the two are developed based on different kernel architectures and depend on the interface protocols of their respective systems).

[0098] Scenario 1: Hardware device using Windows driver When a hardware device has a Windows driver and needs to be used in a Linux system, the compatibility layer software simulates the underlying kernel mechanism of driver loading in the Windows system (such as driver service registration and memory address mapping logic), calls its own adapted Linux interface, and loads the Windows driver into the Linux system's memory. Then, it completes the association initialization between the driver and the hardware device (such as establishing a communication link between the driver and the hardware device and configuring device resources), ultimately enabling the Windows driver to respond normally to the hardware device's interaction requests (such as data read / write and function calls), thus achieving compatible operation of the hardware device in non-native systems.

[0099] In this case, the process of determining and loading the driver for the hardware device based on the device information of the hardware device specifically includes the following steps: Step A1: Determine the matching result between the device information of the hardware device and the device information in the device information file; Step A2: The device information file with a successful match is identified as the target device information file corresponding to the hardware device. Step A3: Load the driver file specified in the target device information file as the driver file for the hardware device.

[0100] Given the existence of multiple INF files, the primary task is to verify the compatibility of these files with the hardware device. The compatibility layer software parses each INF file one by one, extracts the device information recorded within, and then compares it with the device information of the hardware device itself. Through matching and verification, the target INF file that completely corresponds to the hardware device information is selected, ensuring that the subsequently loaded driver file can accurately adapt to the hardware and avoid driver loading anomalies caused by driver file mismatches.

[0101] In step A2, if the match is successful, the INF file will be identified as the target device information file.

[0102] In step A3, the compatibility layer software parses the target INF file according to Windows driver loading rules to obtain key information such as the path of the driver file (.sys file) specified by the target INF file. Then, it loads the .sys file into the Windows kernel environment or user-mode driver framework simulated by the compatibility layer software, enabling the hardware device to establish a connection with the driver and function normally.

[0103] The .sys extension is a common file extension in Windows operating systems. It is mainly used to store code and data related to operating system kernel components, hardware device drivers, or system services, and is one of the core file types for ensuring normal system operation and hardware functionality. For example, core files for graphics card drivers and disk controller driver files often have the .sys extension.

[0104] Scenario 2: Hardware device using Linux driver When a hardware device provides a Linux driver and needs to call hardware functions within a compatibility layer environment, the Linux driver first loads the native Linux kernel normally, completing the low-level binding with the hardware device. Then, the compatibility layer software establishes a communication channel between the simulated Windows environment and the Linux driver by calling the Linux system's hardware access interfaces (such as device files in the / dev directory and ioctl system calls). When a Windows program needs to call hardware functions, the compatibility layer software converts the access request into instructions that the Linux driver can recognize, indirectly completing the interaction with the hardware device through the Linux driver, and ultimately realizing the calling of hardware functions within the compatibility layer environment.

[0105] In step 104, the compatibility layer software simulates the structure and access mechanism of the Windows Registry. Device information for the hardware device is recorded in registry entries of the simulated registry according to Windows rules. When a Windows program needs to obtain device information from the hardware device, the compatibility layer calls the simulated registry access function to read the device information from the simulated registry and provide it to the Windows program. The Windows program then uses this information to generate an access request to the hardware device, enabling interaction between Windows and the hardware device.

[0106] In one example, the process by which a Windows program obtains the VID and PID of a hardware device specifically includes: First, call the RegOpenKey function to open the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum This registry key is where hardware device information is stored. The RegOpenKey function allows Windows programs to locate this specified registry location.

[0107] Next, use the RegEnumKeyEx function to enumerate the bus type subkeys under this registry key. For example, this could include bus type subkeys such as USB, with each bus type subkey representing a hardware bus type.

[0108] Then, use the RegOpenKey function to open each enumerated bus type sub-item. After opening, use the RegEnumKeyEx function to enumerate the device instance sub-items under this bus type sub-item. These device instance sub-items correspond to the actual connected hardware devices.

[0109] Next, the RegQueryValueEx function is called to read the data in the device instance sub-item. The sub-item data may include information such as the hardware device's GUID (Globally Unique Identifier), as well as the hardware device's VID and PID.

[0110] Finally, the read GUID is matched with the GUID of the known hardware device. If the match is successful, the VID and PID of the hardware device can be extracted from the data of the device instance sub-item.

[0111] In one example, the process by which a Windows program generates an access request for the aforementioned hardware device based on the device information specifically includes: Step B1: The Windows program obtains the device instance path of the hardware device based on the device information. The device instance path is a globally unique, stable device object identifier assigned by the Windows system to each identified hardware device, which can be directly used by user-mode programs.

[0112] Step B2: Using the obtained device instance path as a parameter, call the CreateFile function to open the hardware device and obtain a device handle with access permissions.

[0113] Step B3: Using the obtained device handle, call functions such as ReadFile or WriteFile to obtain the access request for the aforementioned hardware device.

[0114] In step 105, after receiving the access request sent by the Windows program, the compatibility layer software translates the access request into instructions for the corresponding driver type.

[0115] If a Windows driver is used, the compatibility layer software passes the instructions to its simulated Windows kernel environment (NT kernel component). The simulated kernel environment then calls the already loaded Windows driver. The Windows driver generates hardware operation instructions, which are then translated into a first Linux system call by the compatibility layer software. This first Linux system call is then issued by the Linux kernel to the hardware device for execution.

[0116] If a Linux driver is used, the compatibility layer software will translate the instructions into a second Linux system call, such as a read call to the / dev / xxx device. The second Linux system call is then handled by the Linux kernel, which will call the already bound Linux driver to operate the hardware device.

[0117] After a hardware device completes its operation, it generates an interrupt or status signal, which is then captured by the Linux kernel.

[0118] If a Windows driver is used, the Linux kernel sends interrupt or status signals to the compatibility layer software. The interrupt simulation module in the compatibility layer receives these signals and sets the simulated Windows hardware environment state. Then, the compatibility layer encapsulates the result data according to the Windows API specification and returns it to the Windows program that initially initiated the access request.

[0119] If a Linux driver is used, the Linux driver directly obtains the result and passes it to the compatibility layer software through the system call interface. The compatibility layer then encapsulates the result according to the Windows API specification and returns it to the Windows program.

[0120] In one implementation, if a Linux driver is used, the access request may include: a device handle of the hardware device and a first control command corresponding to Windows; The process of processing the access request using the driver of the hardware device specifically includes: Step C1: Convert the device handle into a file descriptor for the Linux system, and convert the first control command corresponding to Windows into the second control command corresponding to the Linux system; Step C2: Using the Linux driver of the hardware device, construct an operation request based on the file descriptor and send the operation request to the hardware device; the operation request includes: operation instructions and data pointers.

[0121] A file descriptor is a non-negative integer created by the Linux kernel to manage open hardware devices. In the scenario described above, it provides a standardized reference to the hardware device. Once the compatibility layer software converts the device handle into a file descriptor, the hardware device driver can accurately operate on the target hardware based on this file descriptor, such as reading device data and writing instructions to the hardware device. This allows the Linux system to manage and access various hardware devices in a unified way, greatly facilitating driver control and interaction with the hardware.

[0122] The first and second control instructions can be IOCTL (Input-Output Control) instructions. IOCTL is a system call or interface that allows user-space programs to interact with device drivers to control specific operations of hardware devices, such as configuring device parameters and obtaining device status.

[0123] The embodiments of this application enable Windows programs to operate hardware devices on Linux systems with the help of Linux drivers, reuse the rich and mature driver resources in the Linux ecosystem, and reduce dependence on Windows drivers; at the same time, by using standardized interfaces, the system instability caused by driver compatibility is reduced, thereby improving overall operational stability.

[0124] In one alternative implementation of this application, the method may further include: If the device information matches the target device information of the pre-stored target hardware device, the kernel hot patch corresponding to the target hardware device is loaded; the target hardware device is used to characterize the hardware device that Windows programs access abnormally in the compatibility layer environment.

[0125] The kernel hot patch in this application is used to fix abnormal issues that occur when Windows programs access target hardware devices in a compatibility layer environment by changing the processing logic of the Linux system's return data to hardware devices.

[0126] In the process of implementing the embodiments of this application, the inventors discovered that the processing logic of the Linux system for the returned data of hardware devices differs from that of the Windows system. This difference leads to the following: target hardware devices that can be normally identified and run stably in the Windows system malfunction when running on the Linux operating system with the help of Wine.

[0127] The kernel hot patch in this application processes the returned data from the target hardware device according to the Windows system's processing logic for returned data. Because this kernel hot patch addresses the processing of returned data, it can reduce or eliminate the differences in the processing logic between the Linux and Windows systems, improving the consistency of the processing results between them. Therefore, this application can, to some extent, fix the abnormal issues that occur when Windows programs access the target hardware device in a compatibility layer environment. Furthermore, this application can improve the compatibility between the Linux system and the target hardware device.

[0128] Furthermore, since kernel hot patching technology allows for dynamic updates to the kernel code without restarting the operating system, this application embodiment can fix abnormal issues that occur when Windows programs access target hardware devices in a compatibility layer environment without kernel-mode development privileges. Therefore, this application embodiment can improve the flexibility of problem fixing.

[0129] In this embodiment of the application, the process of generating a kernel hot patch may include: updating the code of the target kernel function according to the processing logic of the Windows system for returned data and the processing logic of the Linux system for returned data, to obtain the updated code of the target kernel function; the target kernel function is used to process the returned data of the target hardware device; and generating a kernel hot patch corresponding to the target hardware device according to the updated code of the target kernel function.

[0130] The process of determining the target kernel function may include: Step D1: Obtain the stack information of the compatible application during the process of accessing the target hardware device in the compatibility layer environment; Step D2: Determine the target device logical layer corresponding to the target hardware device; Step D3: Based on the stack information, locate the target kernel function corresponding to the error in the kernel code of the Linux system that is related to the logical layering of the target device.

[0131] In step D1, during the process of the compatible application accessing the target hardware device in the compatibility layer environment, the Linux system kernel generates stack information containing the function call chain.

[0132] Stack information can be obtained by using error backtracking information in kernel logs or system call tracing tools. This stack information may include: the switching point from user mode to kernel mode, the order of driver module calls, and the location where the error occurred.

[0133] In step D2, in the Linux system, the device logic layer can include: block device layer, character device layer, network protocol stack layer, USB kernel layer, and various bus driver layers, etc. These device logic layers constitute a complete call path from user space to hardware driver.

[0134] The process of determining the target device logical layer corresponding to the target hardware device specifically includes: first, determining the communication protocol of the target hardware device; then, matching the communication protocol of the target hardware device with the name of the device logical layer, and the name of the successfully matched device logical layer is the target device logical layer corresponding to the target hardware device.

[0135] Step D3, based on the stack information, involves locating the target kernel function corresponding to the error in the kernel code of the Linux system related to the logical layering of the target device. This process specifically includes: Step D31: Obtain the kernel source code directory related to the logical layering of the target device; Step D32: Extract the error code, the error function name, and the function call chain from the stack information; Step D33: Search for target files containing error codes in the kernel source code directory.

[0136] Step D34: Locate the error function in the object file that matches the error function name; Step D35: Based on the function call chain information, the erroneous function and the functions called by the erroneous function are selected as candidate functions. The candidate functions are analyzed, and based on the analysis results, the target kernel function that triggered the error is selected from the candidate functions.

[0137] The analysis of candidate functions includes the following aspects: Parameter passing check: This checks whether the value, type, and number of the passed parameters meet the function requirements and whether there are any exceptions such as null pointers or out-of-bounds values. If the value, type, and number of the passed parameters all conform to the function definition and there are no exceptions, then the parameter passing is normal, and this candidate function is unlikely to trigger an error due to parameter issues. If the value of the passed parameters does not fall within the expected range, the type is mismatched, or the number is incorrect, it may cause the function to execute abnormally, and this candidate function may be the target kernel function that triggers the error.

[0138] Boundary condition assessment: Check whether the function handles data boundaries, loop boundaries, etc., correctly, and whether there are issues such as array out-of-bounds access or incorrect loop counts. If the function handles data boundaries and loop boundaries correctly and there are no issues such as array out-of-bounds access or incorrect loop counts, the boundary conditions are handled properly, and it is unlikely that these will cause an error. If boundary handling errors are found, such as array access exceeding the defined range or incorrect loop count calculation, an error may occur, and this candidate function may be the target kernel function that triggers the error.

[0139] Resource management assessment: Verify that the function's allocation, use, and release of system resources such as memory and file handles are reasonable, and check for resource leaks or premature releases. If the function's allocation, use, and release of system resources are reasonable, and there are no resource leaks or premature releases, resource management is normal, and errors are unlikely to be caused by resource issues. Once memory leaks, unreleased file handles, or other improper resource management problems are found, the candidate function is very likely the source of the error.

[0140] Error code identification: Locate the error code within the function and determine its cause to see if a specific operation or condition led to its setting. If the error code is not generated within this function, or if the generated error code is irrelevant to the current error scenario, then this candidate function is unlikely to be the direct cause of the error. If the error code is set within the function under specific operations or conditions and is related to the actual error situation, then this candidate function is very likely the function that triggered the error.

[0141] Call relationship analysis: This determines whether the candidate function was correctly called by the erroneous function, and whether the timing and frequency of the call conform to the expected logic. If the candidate function was correctly called by the erroneous function, and the timing and frequency of the call conform to the expected logic, then there is no problem with the call relationship, and it is unlikely to trigger an error. If there are problems with the call relationship, such as incorrect timing or abnormal frequency, it may affect the function execution result and increase the likelihood of it triggering an error.

[0142] Logical branch check: This checks the execution of each logical branch within the function to see if any branch has performed an incorrect operation or failed to handle the task as expected. If all logical branches execute normally without any errors or failures, the logical branches are likely to be without problems and unlikely to cause an error. However, if some logical branches perform incorrect operations or do not handle the task as expected, it may lead to an error, and this candidate function is likely to be the one that triggers the error.

[0143] Global Variable and Shared Resource Access Analysis: This section examines how candidate functions access global variables or shared resources to identify potential issues such as concurrent access conflicts or data inconsistencies. If a candidate function accesses global variables or shared resources correctly, without concurrent access conflicts or data inconsistencies, the access is unlikely to trigger an error. However, if concurrent access conflicts or data inconsistencies occur, errors may arise, and the candidate function may become the source of the error.

[0144] Reference Figure 2 This document illustrates a flowchart of a hardware device access method in a compatibility layer environment according to an embodiment of this application. In this method, the compatibility layer software can respond to an access request from a Windows program for a target hardware device by sending an operation instruction corresponding to the access request to the target hardware device based on the Linux system kernel and the target driver module of the target hardware device, so that the target hardware device generates return data corresponding to the operation instruction.

[0145] The Linux kernel can include a target kernel function, which processes the data returned by the target hardware device and obtains the processing result. The compatibility layer software can register the target kernel function. The target driver module of the target hardware device calls the target kernel function, obtains the processing result, and sends the processing result to the compatibility layer software.

[0146] In a specific implementation, the above operation instruction can be a read / write instruction, in which case the returned data can include: read / write result and read / write status. Alternatively, the above operation instruction can be a device structure query instruction, in which case the returned data includes: query result and query status.

[0147] Read / write results or query results can be collectively referred to as data information. Read / write status or query status can be collectively referred to as status information. This status information is used to characterize the execution status of operation instructions at the target hardware device. Specifically, this status information includes whether the operation was successful, whether there were any errors, and related execution details, helping Unix-like systems, compatibility layer software, or compatible applications to determine the execution status of operation instructions and take appropriate action accordingly.

[0148] The Linux system's logic for processing returned data can be the same as the target kernel function's logic for processing returned data. This application's embodiments can analyze the original code of the target kernel function to obtain the Linux system's logic for processing returned data.

[0149] Alternatively, the process of determining the Linux system's processing logic for the returned data can include: acquiring the first data packet sent by the target hardware device to the Linux system kernel during the process of a compatible application accessing the target hardware device in a compatibility layer environment, and the second data packet sent by the Linux system kernel to the compatibility layer software or compatible application; and determining the Linux system's processing logic for the returned data based on the first and second data packets. In practical applications, the contents of the first and second data packets can be compared to check the first content relationship information between the first and second data packets, and this first content relationship information can be used as the Linux system's processing logic for the returned data.

[0150] The process of determining the Windows system's processing logic for returned data includes: acquiring the third data packet sent from the target hardware device to the Windows system kernel and the fourth data packet sent from the Windows system kernel to the compatible application during the process of the compatible application accessing the target hardware device in the Windows environment; and determining the Windows system's processing logic for the returned data based on the third and fourth data packets. In practical applications, the contents of the third and fourth data packets can be compared to examine the second content relationship information between them, and this second content relationship information can be used as the Windows system's processing logic for the returned data.

[0151] Of course, the Windows system's processing logic for returned data in this embodiment may further include: the Windows system's processing procedure for the third data packet. This processing procedure may be a process of sending an interactive instruction to the target hardware device based on the third data packet to obtain response data returned by the target data packet, and the response data may be a component of the fourth data packet.

[0152] This application embodiment can compare the processing logic of the Windows system for returned data and the processing logic of the Linux system for returned data. If the comparison result is inconsistent, the code of the target kernel function can be updated according to the processing logic of the Windows system for returned data to obtain the updated code of the target kernel function.

[0153] Specifically, a comparison result of inconsistency includes: the first content relationship information indicates different content, while the second content relationship information indicates the same content; or, the first content relationship information indicates the same content, while the second content relationship information indicates different content, and so on.

[0154] Specifically, when the first content relationship information is different and the second content relationship information is the same, updating the code can achieve consistency between the first data packet and the second data packet, thereby improving the consistency of the processing results of the returned data between the Linux system and the Windows system.

[0155] In one example, suppose a read / write command is sent to a SCSI device. The SCSI device returns data including the read / write result and the read / write status. Assuming a read / write status array is used to store the read / write status, the Linux system processes the returned data as follows: if an element in the read / write status array is empty, all data after that element is discarded. The Windows system, however, processes the returned data as follows: regardless of whether an element in the read / write status array is empty, all element values ​​in the read / write status array are retained.

[0156] To address this issue, this application's embodiments achieve consistency in the processing results of returned data between Windows and Linux systems by updating the code. Taking the scenario of sending read / write commands to a SCSI device as an example, the Linux system discards data after the empty element in the read / write status array, while the Windows system retains all elements of the array. Therefore, in the processing logic design of the updated code, the processing logic of the Windows system is adopted, retaining all elements regardless of whether the element value in the read / write status array is empty, thereby unifying the processing results of the two systems.

[0157] Assuming the returned data includes a state structure, reading and writing a state array can be considered a specific form of this structure. When the update code processes the data returned by the target hardware device, if the first element of the state structure is empty, according to the Windows system's logic for processing returned data, all element values ​​within the state structure will be included in the processing result. The first element can represent any element in the state structure.

[0158] The comparison results show inconsistencies, specifically in the different processing procedures for returned data between Linux and Windows systems.

[0159] In a specific example, suppose a device structure query command is sent to a hardware device. The hardware device returns data containing the query results and query status. An array of query results is used to store the hardware device's query results, which may include information such as the number of child nodes attached to the hardware device. For example, a document scanner, as a hardware device, can attach child nodes such as a camera, fingerprint recognition module, signature pad, and microphone.

[0160] The Linux system processes the returned data as follows: if there is an element in the query result array with a value of zero, the entire query result array is used as the final processing result.

[0161] The Windows system processes the returned data as follows: when an element in the query result array has a value of zero, it retrieves child node information interactively. The specific interaction process is as follows: the first round of interaction retrieves the actual number of child nodes; the second round of interaction retrieves the names of each child node.

[0162] In response to this situation, the embodiments of this application adopt the processing logic of the Windows system in the processing logic design of the update code. When the element value of a certain element in the query result array is zero, the child node information is obtained through interactive means.

[0163] Assuming the returned data includes device structure, the query result array is a specific implementation of the device structure. Assuming the second structural element in the device structure represents the child node information of the target hardware device, then when the value of the second structural element in the data is zero, the update code sends an interaction command to the target hardware device according to the Windows system's processing logic for the returned data. This interaction command is used to obtain the child node information of the target hardware device.

[0164] In summary, the embodiments of this application can perform various updates to the target kernel function according to the Windows system's processing logic for returned data, in order to achieve consistency between the processing results of returned data between the Windows system and the Linux system. It is understood that the embodiments of this application do not limit the specific update process of the target kernel function.

[0165] Those skilled in the art can use the necessary patch generation techniques or tools to generate kernel hot patches. This application does not limit the specific process for generating kernel hot patches.

[0166] For example, Kpatch is a patch generation tool that operates at the function level, patching functions by redirecting calls to the original kernel functions to patched versions with fixes. It relies on the ftrace (Function Trace) framework in the Linux kernel to analyze kernel function calls and replace old functions with new ones.

[0167] In one example, the process of generating a kernel hot patch for a target hardware device based on the updated code of the target kernel function specifically includes: compiling the updated code of the target kernel function to obtain a machine code format target file; performing symbol analysis on the target file to obtain a relocation information table recording external dependencies; and linking the target file and the relocation information table to obtain a kernel module file. The kernel module file is specifically the file containing the kernel hot patch.

[0168] The relocation information table includes offset (the instruction location that needs to be corrected), symbol name (the referenced function / variable), type (address calculation method), etc. It is used to guide the linker in the address references in the generated kernel module file, and can also guide the kernel to correctly correct instructions when loading the kernel module file.

[0169] Accordingly, the process of loading the kernel hot patch corresponding to the target hardware device specifically includes: parsing the updated code and relocation information in the kernel module file, mapping the updated code to the kernel address space and completing address correction, generating an executable code entity; replacing the entry instructions of the original code of the target kernel function with jump instructions for jumping to the updated code, realizing runtime function logic switching; when the original code of the target kernel function is called, the jump instructions are executed, automatically redirecting to the updated code. The executable code entity is the runtime code entity after the updated code is loaded into memory, used as the target address of the jump instructions to carry the execution logic of the updated code.

[0170] The method in this application embodiment may further include: in response to an access request from a Windows program to a target hardware device, the compatibility layer software sends an operation instruction corresponding to the access request to the target hardware device by means of the Linux system kernel and the target driver module of the target hardware device, so that the target hardware device generates return data corresponding to the operation instruction.

[0171] Upon receiving an access request conforming to the Windows protocol, the compatibility layer software converts it into a Linux protocol-compliant request. This conversion request is then passed to the target driver module corresponding to the target hardware device via the kernel's system call interface. The target driver module converts the request into executable instructions for the target hardware device and sends them to the device. The data returned by the target hardware device is then relayed back to the compatibility layer software via the target driver module and the kernel, and finally returned to the compatibility application.

[0172] The method in this application embodiment may further include: during the process of the return data of the target hardware device being transmitted back to the compatibility layer software via the target driver module and the kernel, the kernel will use the kernel hot patch corresponding to the target hardware device to process the return data of the target hardware device and obtain the corresponding processing result.

[0173] Among them, the kernel hot patch corresponds to the target kernel function. The kernel hot patch replaces the machine code entry point of the original code of the target kernel function in the kernel with a jump instruction, and the jump target points to the updated code of the target kernel function in the kernel hot patch.

[0174] In one implementation, the compatibility layer software can pre-register the target kernel function; after receiving the returned data, the target driver module of the target hardware device can call the target kernel function, obtain the processing result, and send the processing result to the compatibility layer software.

[0175] The compatibility layer software pre-registers the calling conventions (including function pointers, parameter formats, and call paths) of the target kernel functions in the kernel. After receiving the return data, the target driver module can call the target kernel function and, upon completion of the call, return the processing result to the compatibility layer software according to the call path in the calling convention.

[0176] It is understandable that kernel hot patches can be handled in different ways depending on the target hardware device.

[0177] For example, when the returned data includes status information and the status information includes a status structure, the process by which the kernel hot patch processes the returned data of the target hardware device according to the Windows system's processing logic for returned data specifically includes: when the element value of the first structure element included in the status structure in the status information is empty, the kernel hot patch uses the element values ​​of all structure elements of the status structure as the processing result according to the Windows system's processing logic for returned data.

[0178] For example, when the returned data includes data information and the data information includes device structure, the second structural element in the device structure is used to characterize the child node information included in the target hardware device. The process by which the kernel hot patch processes the returned data from the target hardware device according to the Windows system's processing logic for returned data specifically includes: when the element value of the second structural element included in the device structure in the data information is zero, the kernel hot patch sends an interaction command to the target hardware device according to the Windows system's processing logic for returned data. This interaction command is used to obtain the child node information included in the target hardware device. The child node information may include: the number of child nodes and the name of each child node, etc.

[0179] It should be noted that after receiving the processing result, the compatibility layer software can also convert the processing result into a conversion result that conforms to the Windows protocol and send the conversion result to the compatible application.

[0180] In one example, if the first element of the state structure in the state information is empty, the kernel hot patch, based on the Windows system's processing logic for returned data, uses the values ​​of all elements of the state structure as the processing result. In this case, the compatibility layer software can receive the processing result and send the corresponding conversion result to the compatible application.

[0181] In another example, when the element value of the second structural element included in the device structure of the data information is zero, the kernel hot patch sends an interaction command to the target hardware device according to the Windows system's processing logic for returned data. This interaction command is used to obtain the child node information included in the target hardware device. The kernel hot patch can further process the child node information to obtain a processing result; for example, it can directly use the child node information as the processing result. In this case, the compatibility layer software can receive the above processing result and send the corresponding conversion result to the compatible application.

[0182] The method in this application embodiment may further include: the compatibility layer software establishing a network socket connection with the Windows program and determining the target hardware device corresponding to the Windows program; and using the network socket connection to send the device status and / or device certificate corresponding to the target hardware device to the Windows program.

[0183] Based on network socket connections, the compatibility layer software can identify the target hardware device corresponding to a Windows program. During the operation of the target hardware device, its device state may change, such as during insertion, removal, or operation. The compatibility layer can obtain these device states in real time. Simultaneously, the device itself comes with a device certificate that identifies its identity and permissions. Then, the compatibility layer software uses the established network socket connection to transmit the real-time device state and device certificate to the Windows program.

[0184] Compared to Windows programs simply calling APIs to obtain device status, the network socket connection method offers significant advantages. Firstly, when the target hardware device changes status due to removal, the compatibility layer software can promptly capture this and notify the Windows program via the network connection. This solves the problem of APIs failing to respond promptly to status changes when a device is removed, allowing the Windows program to stay updated on the target hardware device's latest status. Secondly, the transmission of device certificates provides the Windows program with a basis for verifying the device's legitimacy and security, enhancing the security and trustworthiness of the interaction between the hardware device and the Windows program. These two factors combined greatly improve the stability, reliability, and security of Windows programs operating hardware devices under Linux systems using Linux drivers.

[0185] During the network socket connection establishment process, Windows programs can send hardware device information to the compatibility layer software during the handshake. The compatibility layer software can then use this information to determine the target hardware device for the connected Windows program. Alternatively, Windows programs can also send hardware device information to the compatibility layer software after the network socket connection is established.

[0186] The process of determining the device status of the target hardware device specifically includes: Using Windows device input / output control functions, communicate with the target hardware device to obtain the device status of the target hardware device; and / or The device status of the target hardware device is determined based on the device path provided by the user space device manager.

[0187] The device input / output control function can be DeviceIoControl. DeviceIoControl is a core function in the Windows system used for interaction between user-space programs and hardware device drivers. Compatibility layer software or Windows programs call DeviceIoControl, passing in the device handle of the target hardware device, preset control codes (such as specific instructions for querying device status), input parameters, and a buffer to receive status data. The call request is passed to the driver of the target hardware device, which executes the corresponding instructions (such as reading status information from the device registers), writes the device status (such as insertion / removal, running / faulting, etc.) to the output buffer, and finally returns the status data to the caller through the DeviceIoControl function.

[0188] In a Linux system, after a Windows driver sends a request to obtain the device status, the compatibility layer software converts the request into a form that the Linux system can process. Then, the Linux system interacts with the hardware device to obtain the device status, and then feeds it back to the Windows driver through the compatibility layer software.

[0189] In Linux systems, the user-space device manager assigns a unique device path to each hardware device, such as ` / dev / sda`. The device manager locates the corresponding device node using this path, then reads the associated system status file (e.g., the attribute file in the ` / sys / class` directory) or calls the query interface provided by the device manager to obtain the device status. The device path is a specific string in Linux that identifies the location of a hardware device within the file system, while the device node is a special file in the file system that represents the hardware device; it serves as the interface between user space and the hardware device.

[0190] Reference Figure 3 This diagram illustrates a method for accessing a hardware device in a compatibility layer environment according to an embodiment of this application. Figure 3 This demonstrates the complete process of a Ukey device from insertion and recognition to establishing communication with the corresponding Windows program on the client. The method specifically includes the following steps: Phase 1: Device Identification and Driver Loading Step 301: The compatibility layer software identifies the hardware device and obtains the device information of the hardware device; When the Ukey device is plugged into the USB port of an electronic device, the Linux system detects the new device and obtains the device information of the Ukey device.

[0191] Step 302: The compatibility layer software generates a registry entry for the hardware device in a simulated registry that conforms to the Windows interface behavior specification, according to the Windows data storage specification; the registry entry includes: device information of the hardware device; Step 303: The compatibility layer software determines and loads the driver for the hardware device based on the device information of the hardware device; Phase Two: Server-side monitoring and device status management. The server can be deployed on the compatibility layer software side, and the client can be deployed on the Windows application side.

[0192] Step 304: The compatibility layer software starts the monitoring service and uses the monitoring service to query the device status of the hardware devices from the Linux system according to a preset period. Step 305: The compatibility layer software determines whether a new device has been detected. If not, it returns to step 304; otherwise, it proceeds to step 306. Step 306: The compatibility layer software adds the new device to the device list and records the device status of the hardware device in the device list; Phase 3: Client Communication Step 307: The compatibility layer software establishes a network socket connection with the Windows program; Once the compatibility layer software's server starts, it creates a Socket communication interface and waits for client connections. The client can be a Ukey application. This client can establish a network connection with the server via the Socket.

[0193] Step 308: The compatibility layer software uses the network socket connection to send the device status and / or device certificate corresponding to the target hardware device to the Windows program.

[0194] When a client needs to operate on a Ukey, the server sends the Ukey's device certificate to the client via a network socket connection. After obtaining the device certificate, the client can perform secure read and write operations on the Ukey.

[0195] In one optional implementation of this application, the method may further include: creating a window for the Windows program based on a window creation request; generating a window settings request based on window attribute parameter values ​​in the window creation request; and setting the window for the Windows program according to the window settings request so that the window conforms to the window attribute parameter values. By configuring the created window according to the generated window settings request, the actual state of the window is made consistent with the attribute parameter values ​​required by the Windows program, thereby resolving display problems caused by mismatched attribute configurations, such as the window not being able to be pinned or maximized.

[0196] In summary, after detecting the insertion event of a hardware device, the compatibility layer software in this embodiment generates a registry entry for the hardware device in a simulated registry that conforms to the Windows interface behavior specification, according to the Windows data storage specification. Since this registry entry provides standardized device information for Windows programs, the Windows programs can generate access requests based on this standardized device information, allowing the hardware device to run stably in the compatibility layer environment. This effectively solves the identification errors and runtime anomalies that occur when using Wine in the Linux operating system. Therefore, this embodiment improves the compatibility and stability of Windows programs accessing hardware devices in the compatibility layer environment, enabling cross-system Windows programs to interact with hardware devices as smoothly as in the native environment, reducing device access barriers caused by operating system differences.

[0197] Furthermore, this embodiment determines and loads the driver for the hardware device based on the device information, and uses the driver to process the access request. Since a suitable driver can be accurately determined and loaded based on the device information, and the access request can be effectively processed by this driver, this embodiment can further reduce the probability of hardware device malfunctions in a compatibility layer environment, and reduce device access failures caused by driver incompatibility or processing anomalies. It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to this application.

[0198] It should be noted that the method for accessing hardware devices in a compatibility layer environment provided in this application embodiment can be executed by an entity that accesses hardware devices in a compatibility layer environment. Device Or, or accessing hardware devices within this compatibility layer environment. Device The control module in this application is used to execute a method for accessing hardware devices under a compatibility layer environment. This embodiment of the application accesses hardware devices under a compatibility layer environment. Device Taking the method of accessing hardware devices in a compatibility layer environment as an example, this application provides a method for accessing hardware devices in a compatibility layer environment.

[0199] Reference Figure 4 This document illustrates a schematic diagram of a device for accessing hardware devices in a compatibility layer environment according to an embodiment of this application. The compatibility layer environment is an environment where Windows programs run under Linux. The device is applied to compatibility layer software and specifically includes the following modules: The information acquisition module 401 is used to acquire the device information of the hardware device after detecting the insertion event of the hardware device; The registry generation module 402 is used to generate registry entries for the hardware device in a simulated registry that conforms to the Windows interface behavior specification, according to the Windows data storage specification; the registry entries include: device information of the hardware device; The driver determination and loading module 403 is used to determine and load the driver of the hardware device based on the device information of the hardware device. A module 404 is provided to provide device information of the hardware device to the Windows program based on the registry entries of the hardware device, so that the Windows program can generate an access request for the hardware device based on the device information. The access request processing module 405 is used to process the access request using the driver of the hardware device.

[0200] Optionally, the information acquisition module is specifically used to, after detecting the insertion event of a hardware device, access the attribute file of the hardware device in the virtual file system of the Linux system according to the device path provided by the user space device manager, and read the device information of the hardware device in the attribute file.

[0201] Optionally, the driver determination loading module includes: The matching module is used to determine the matching result between the device information of the hardware device and the device information in the device information file; The file determination module is used to determine the target device information file corresponding to the hardware device by identifying the device information file that has been successfully matched. The loading module is used to load the driver file specified in the target device information file as the driver file for the hardware device.

[0202] Optionally, the device further includes: A network communication module is used to establish a network socket connection with the Windows program and to determine the target hardware device corresponding to the Windows program. The sending module is used to send the device status and / or device certificate corresponding to the target hardware device to the Windows program using the network socket connection.

[0203] Optionally, the device further includes: The first device status acquisition module is used to communicate with the target hardware device using Windows device input / output control functions to obtain the device status of the target hardware device; and / or The second device status acquisition module is used to determine the device status of the target hardware device based on the device path provided by the user space device manager.

[0204] Optionally, the device further includes: A hot patch loading module is used to load the kernel hot patch corresponding to the target hardware device when the device information matches the target device information of the pre-stored target hardware device; the target hardware device is used to characterize the hardware device that Windows programs access abnormally in the compatibility layer environment.

[0205] Optionally, the device further includes: A creation module is used to create a window for the Windows program based on the window creation request of the Windows program; The generation module is used to generate a window setting request based on the window attribute parameter values ​​in the window creation request; The settings module is used to set the window of the Windows program according to the window settings request, so that the window of the Windows program conforms to the window attribute parameter values.

[0206] Optionally, the access request includes: a device handle of the hardware device and a first control command corresponding to Windows; The access request processing module includes: The conversion module is used to convert the device handle into a file descriptor for the Linux system and to convert the first control command corresponding to Windows into the second control command corresponding to the Linux system. The request sending module is used to construct an operation request based on the file descriptor using the Linux driver of the hardware device, and send the operation request to the hardware device; the operation request includes: operation instructions and data pointers.

[0207] Accessing hardware devices in a compatibility layer environment as described in this application embodiment Device It can be a device, or a component, integrated circuit, or chip in a terminal. The device can be a mobile electronic device or a non-mobile electronic device. For example, mobile electronic devices can be mobile phones, tablets, laptops, PDAs, in-vehicle electronic devices, wearable devices, ultra-mobile personal computers (UMPCs), netbooks, or personal digital assistants (PDAs), etc., while non-mobile electronic devices can be servers, network attached storage (NAS), personal computers (PCs), televisions (TVs), ATMs, or self-service machines, etc. The embodiments in this application do not impose specific limitations.

[0208] The device accessing the hardware device in the compatibility layer environment of this application embodiment can be a device with an operating system. This operating system can be Android, iOS, or other possible operating systems; this application embodiment does not specifically limit the specific operating system.

[0209] The device for accessing hardware devices in a compatibility layer environment provided in this application embodiment can achieve... Figures 1 to 3 The various processes implemented by the device accessing the hardware device in the compatibility layer environment in the method embodiment will not be described again here to avoid repetition.

[0210] Optionally, embodiments of this application also provide an electronic device, including a processor, a memory, and a program or instructions stored in the memory and executable on the processor. When the program or instructions are executed by the processor, they implement the various processes of the above-described method embodiments for accessing hardware devices in a compatibility layer environment and achieve the same technical effects. To avoid repetition, they will not be described again here.

[0211] It should be noted that the electronic devices in the embodiments of this application include the mobile electronic devices and non-mobile electronic devices described above.

[0212] Figure 5 A schematic diagram of the hardware structure of an electronic device 1100 according to an embodiment of this application.

[0213] Electronic device 1100 has one or more processors 1102, a control module (chipset) 1104 coupled to at least one of the processors 1102, a memory 1106 coupled to the control module 1104, a non-volatile memory / storage device 1108 coupled to the control module 1104, one or more input / output devices 1110 coupled to the control module 1104, and a network interface 1112 coupled to the control module 1104.

[0214] Processor 1102 may include one or more single-core or multi-core processors, and processor 1102 may include any combination of general-purpose processors or special-purpose processors (e.g., graphics processors, application processors, baseband processors, etc.). In some embodiments, electronic device 1100 can serve as a terminal device, server (cluster), or other device as described in the embodiments of this application.

[0215] In some embodiments, electronic device 1100 may include one or more computer-readable media (e.g., memory 1106 or non-volatile memory / storage device 1108) having instructions 1114 and one or more processors 1102 that are combined with the one or more computer-readable media and configured to execute instructions 1114 to implement modules and thus perform the actions described in this disclosure.

[0216] In one embodiment, the control module 1104 may include any suitable interface controller to provide any suitable interface to at least one of the processors 1102 and / or any suitable device or component communicating with the control module 1104.

[0217] The control module 1104 may include a memory controller module to provide an interface to the memory 1106. The memory controller module may be a hardware module, a software module, and / or a firmware module.

[0218] Memory 1106 may be used, for example, to load and store data and / or instructions 1114 for electronic device 1100. In one embodiment, memory 1106 may include any suitable volatile memory, such as suitable DRAM (Dynamic Random Access Memory). In some embodiments, memory 1106 may include double data rate type quad synchronous dynamic random access memory.

[0219] In one embodiment, the control module 1104 may include one or more input / output controllers to provide an interface to the non-volatile memory / storage device 1108 and (one or more) input / output devices 1110.

[0220] For example, non-volatile memory / storage device 1108 may be used to store data and / or instructions 1114. Non-volatile memory / storage device 1108 may include any suitable non-volatile memory (e.g., flash memory) and / or may include any suitable (one or more) non-volatile storage devices (e.g., one or more hard disk drives, one or more optical disk drives, and / or one or more digital universal optical disk drives).

[0221] The non-volatile memory / storage device 1108 may include storage resources that are physically part of a device on which the electronic device 1100 is mounted, or that can be accessed by the device without being part of the device. For example, the non-volatile memory / storage device 1108 may be accessed via a network via one or more input / output devices 1110.

[0222] One or more input / output devices 1110 may provide an interface for electronic device 1100 to communicate with any other suitable device. Input / output devices 1110 may include communication components, audio components, sensor components, etc. Network interface 1112 may provide an interface for electronic device 1100 to communicate via one or more networks. Electronic device 1100 may wirelessly communicate with one or more components of a wireless network according to any of one or more wireless network standards and / or protocols, such as accessing wireless networks based on communication standards, such as WiFi (Wireless Fidelity), 2G (2-Generation wireless telephone technology), 3G (3-Generation wireless telephone technology), 4G (4-Generation wireless telephone technology), 5G (5-Generation wireless telephone technology), etc., or combinations thereof.

[0223] In one embodiment, at least one of the processors 1102 may be logically packaged with one or more controllers (e.g., memory controller modules) of the control module 1104. In one embodiment, at least one of the processors 1102 may be logically packaged with one or more controllers of the control module 1104 to form a system-in-package. In one embodiment, at least one of the processors 1102 may be integrated with the logic of one or more controllers of the control module 1104 on the same die. In one embodiment, at least one of the processors 1102 may be integrated with the logic of one or more controllers of the control module 1104 on the same die to form a system-on-a-chip.

[0224] In various embodiments, electronic device 1100 may be, but is not limited to, a server, desktop computing device, or mobile computing device (e.g., laptop computing device, handheld computing device, touchscreen device, netbook, etc.). In various embodiments, electronic device 1100 may have more or fewer components and / or different architectures. For example, in some embodiments, electronic device 1100 includes one or more cameras, a keyboard, a liquid crystal display screen (including a touchscreen display), a non-volatile memory port, multiple antennas, a graphics chip, an application-specific integrated circuit (ASIC), and a speaker.

[0225] In the aforementioned electronic device 1100, a main control chip may be used as a processor or control module, sensor data, position information, etc. are stored in a memory or non-volatile memory / storage device, the sensor group may be used as an input / output device, and the communication interface may include a network interface.

[0226] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described method embodiment for accessing hardware devices in a compatibility layer environment and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0227] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0228] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0229] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0230] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for accessing hardware devices in a compatibility layer environment, characterized in that, The compatibility layer environment is an environment that runs Windows programs under Linux. The method is applied to compatibility layer software, and the method includes: After detecting the insertion event of a hardware device, the device information of the hardware device is obtained; According to the Windows data storage specification, a registry entry for the hardware device is generated in a simulated registry that conforms to the Windows interface behavior specification; the registry entry includes: device information of the hardware device; Based on the device information of the hardware device, determine and load the driver of the hardware device; Based on the registry entries of the hardware device, the Windows program is provided with device information of the hardware device, so that the Windows program generates an access request for the hardware device based on the device information. The access request is processed using the driver of the hardware device.

2. The method according to claim 1, characterized in that, The step of obtaining the device information of the hardware device after detecting the insertion event of the hardware device includes: After detecting the insertion event of a hardware device, the system accesses the hardware device's property file in the Linux system's virtual file system according to the device path provided by the user-space device manager, and reads the device information of the hardware device from the property file.

3. The method according to claim 1, characterized in that, The step of determining and loading the driver for the hardware device based on the device information of the hardware device includes: Determine the matching result between the device information of the hardware device and the device information in the device information file; The device information file that is successfully matched is identified as the target device information file corresponding to the hardware device. The driver file specified in the target device information file is loaded as the driver file for the hardware device.

4. The method according to claim 1, characterized in that, The method further includes: Establish a network socket connection with the Windows program and determine the target hardware device corresponding to the Windows program; Using the network socket connection, the device status and / or device certificate corresponding to the target hardware device are sent to the Windows program.

5. The method according to claim 4, characterized in that, The method further includes: Using Windows device input / output control functions, communicate with the target hardware device to obtain the device status of the target hardware device; and / or The device status of the target hardware device is determined based on the device path provided by the user space device manager.

6. The method according to claim 1, characterized in that, The method further includes: If the device information matches the target device information of the pre-stored target hardware device, the kernel hot patch corresponding to the target hardware device is loaded; the target hardware device is used to characterize the hardware device that Windows programs access abnormally in the compatibility layer environment.

7. The method according to claim 1, characterized in that, The method further includes: Create the window of the Windows program according to the window creation request of the Windows program; A window settings request is generated based on the window attribute parameter values ​​in the window creation request; Based on the window settings request, the window of the Windows program is configured to conform to the window attribute parameter values.

8. The method according to any one of claims 1 to 7, characterized in that, The access request includes: the device handle of the hardware device and the first control command corresponding to Windows; The process of handling the access request using the driver of the hardware device includes: The device handle is converted into a file descriptor for the Linux system, and the first control command corresponding to Windows is converted into the second control command corresponding to the Linux system. Using the Linux driver of the hardware device, an operation request is constructed based on the file descriptor and sent to the hardware device; the operation request includes: operation instructions and data pointers.

9. A device for accessing hardware devices in a compatibility layer environment, characterized in that, The compatibility layer environment is an environment for running Windows programs under Linux. The device is applied to the compatibility layer software and includes: The information acquisition module is used to acquire device information of the hardware device after detecting the insertion event of the hardware device; The registry generation module is used to generate registry entries for the hardware device in a simulated registry that conforms to the Windows interface behavior specification, according to the Windows data storage specification; the registry entries include: device information of the hardware device; The driver determination and loading module is used to determine and load the driver of the hardware device based on the device information of the hardware device. A module is provided to provide device information of the hardware device to the Windows program based on the registry entries of the hardware device, so that the Windows program can generate an access request for the hardware device based on the device information; The access request processing module is used to process the access request using the driver of the hardware device.

10. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method as described in claims 1-8.

11. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the method as described in claims 1-8.

Images