Ukey compatible method, device and terminal based on wine optical drive subsystem

Abstract

The application discloses a UKEY compatible method and device based on a Wine optical drive subsystem and a terminal, and belongs to the technical field of computers. The method comprises the following steps: when the UKEY device is accessed, a cdrom module acquires hardware information, creates a configuration item in a Wine registry, and writes an identification key value; a SetupAPI intercepts an enumeration call and reads the identification key value to splice a standard device identification, and creates a virtual device instance; when an application initiates an IO to the instance, device identity query is triggered, the identification key value is acquired and returned, and a disk device interface is registered for the instance to establish an access entrance; a mountmgr forwards read-write IO requests to the cdrom module, matches the device, and returns a hardware response to the application through the access entrance. Through Wine multi-module processing of hardware collection, virtual device generation, PnP identity verification and instruction transmission, the compatibility of Linux environment Windows software to physical UKEY is realized.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a UKEY-compatible method, apparatus and terminal based on the Wine CD-ROM drive subsystem. Background Technology

[0002] Wine is an open-source compatibility tool that runs on systems such as Linux and macOS, enabling native execution of Windows applications by translating system commands. However, its compatibility with Windows-specific hardware is weak, with serious compatibility issues arising from U-key encryption devices commonly used in tax, banking, and government scenarios. In Windows, U-keys are recognized as USB storage devices and used for data exchange, but Wine natively does not support the recognition and adaptation of such devices. This results in the inability to properly recognize U-key devices when running Windows government and tax software via Wine in a Linux environment.

[0003] Currently, there are three solutions for using a USB key in a Linux environment with Wine. The first is to set up a Windows virtual machine and directly connect the USB key to the system within the virtual machine. The second is to use a USB / IP tool to forward USB hardware data, redirecting the USB key to the Wine program. The third is to abandon the existing Windows client and develop dedicated business software adapted for the Linux system. All three solutions bypass Wine's own device adaptation framework and cannot achieve seamless compatibility of the USB key natively within Wine.

[0004] However, existing technical solutions all suffer from problems such as high resource consumption, complex deployment, insufficient stability, or huge development costs, and none of them can solve the core obstacle of device recognition and interaction within Wine. Summary of the Invention

[0005] This invention provides a UKEY compatibility method, device, and terminal based on the Wine optical drive subsystem to solve the technical problems of Wine's native lack of support for USB storage UKEY devices, resulting in high resource consumption, complex deployment, poor stability, and high development costs.

[0006] In a first aspect, embodiments of the present invention provide a UKEY-compatible method based on a Wine optical drive subsystem, comprising: When a physical UKEY device is connected to a Linux host, Wine's cdrom module is triggered to traverse the block devices, obtain the hardware information of each block device through recursive directory, locate the target UKEY device, create a configuration item for the target UKEY device in the Wine registry, and write an identifier key value based on the hardware information. When a Windows application calls the SetupAPI interface to enumerate storage devices, the call is intercepted and the UKEY processing branch is entered. The identifier key value in the configuration item is read, the identifier key value is concatenated to generate the USBSTOR standard device identifier, and a UKEY virtual device instance is created. When a Windows application initiates a read / write IO request to a UKEY virtual device instance, the mountmgr component triggers a device identity query based on the read / write IO request, obtains and returns the identifier key value of the configuration item, and registers the standard disk device interface for the UKEY virtual device instance to establish the device access entry for the instance. The mountmgr component forwards the received read / write I / O requests to Wine's cdrom module. The cdrom module matches the UKEY device based on the identifier key value in the configuration items and sends the hardware response of the UKEY device back to the Windows application through the device access entry.

[0007] Secondly, embodiments of the present invention also provide a UKEY-compatible device based on a Wine optical drive subsystem, comprising: A module is created to trigger Wine's cdrom module to traverse block devices when a physical UKEY device is connected to a Linux host. The module obtains the hardware information of each block device through recursive directory, locates the target UKEY device, creates a configuration item for the target UKEY device in the Wine registry, and writes an identifier key value based on the hardware information. The generation module is used to intercept the call and enter the UKEY processing branch when the Windows application calls the SetupAPI interface to enumerate storage devices, read the identifier key value in the configuration item, concatenate the identifier key value to generate the USBSTOR standard device identifier, and create a UKEY virtual device instance; The query module is used to trigger device identity query based on read / write IO requests when Windows applications initiate read / write IO requests to the UKEY virtual device instance. It retrieves and returns the identifier key value of the configuration item and registers the standard disk device interface for the UKEY virtual device instance to establish the device access entry of the instance. The access module is used by the mountmgr component to forward received read / write I / O requests to Wine's cdrom module. The cdrom module matches the UKEY device according to the identifier key value in the configuration item and sends the hardware response of the UKEY device back to the Windows application through the device access entry.

[0008] Thirdly, embodiments of the present invention also provide a terminal, including: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the UKEY compatible method based on the Wine optical drive subsystem provided in the above embodiments.

[0009] The UKEY compatibility method, device, and terminal based on the Wine optical drive subsystem provided in this invention embodiment, when a physical UKEY device is connected to a Linux host, triggers Wine's cdrom module to traverse block devices, obtain hardware information of each block device through recursive directory, locate the target UKEY device, create a configuration item for the target UKEY device in the Wine registry, and write an identifier key value based on the hardware information; when a Windows application calls the SetupAPI interface to enumerate storage devices, the call is intercepted and the UKEY processing branch is entered, the identifier key value in the configuration item is read, the identifier key value is concatenated to generate a USBSTOR standard device identifier, and a UKEY virtual device instance is created; when the Windows application initiates a read / write IO request to the UKEY virtual device instance, the mountmgr component triggers a device identity query based on the read / write IO request, obtains the identifier key value of the configuration item and returns it, and registers a standard disk device interface for the UKEY virtual device instance to establish a device access entry for the instance; the mountmgr component forwards the received read / write IO request to Wine's cdrom module, the cdrom module matches the UKEY device according to the identifier key value in the configuration item, and sends the hardware response of the UKEY device back to the Windows application through the device access entry. By modifying the Wine CD-ROM subsystem, storing hardware identifiers in the registry, and extending the SetupAPI and mountmgr device processing logic, we can achieve simulated identification and bidirectional data interaction of physical UKEY devices in the LinuxWine environment. Attached Figure Description

[0010] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an improper limitation of the invention.

[0011] Figure 1 This is a flowchart of the UKEY compatibility method based on the Wine optical drive subsystem provided in Embodiment 1 of the present invention; Figure 2 This is a flowchart of the UKEY compatibility method based on the Wine optical drive subsystem provided in Embodiment 2 of the present invention; Figure 3 This is a structural diagram of the UKEY compatible device based on the Wine optical drive subsystem provided in Embodiment 3 of the present invention; Figure 4 This is a structural diagram of the terminal provided in Embodiment 4 of the present invention. Detailed Implementation

[0012] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0013] Example 1 Figure 1 This is a flowchart of a UKEY compatibility method based on the Wine optical drive subsystem provided in Embodiment 1 of the present invention. This embodiment is applicable to scenarios where Windows tax and e-government software using a UKEY device is run via Wine in a Linux system, and specifically includes the following steps: Step 110: When the physical UKEY device is connected to the Linux host, Wine's cdrom module is triggered to traverse the block devices, obtain the hardware information of each block device through recursive directory, locate the target UKEY device, create a configuration item for the target UKEY device in the Wine registry, and write the identifier key value based on the hardware information.

[0014] UKEY is a USB storage hardware device with a built-in security encryption chip, commonly used in tax control and government login scenarios. It relies on the Windows USBSTOR storage protocol to complete device enumeration and certificate reading / writing, and the native Linux Wine environment cannot directly recognize and adapt to it. Wine is a compatibility layer program that runs on the Linux system, allowing direct execution of Windows applications without a virtual machine, but it natively lacks the virtual device mapping and bus emulation capabilities for USB encryption hardware. The cdrom module is a component of Wine's built-in optical drive subsystem, natively responsible for simulating optical disc block device reading and writing.

[0015] The existing Wine lacks mechanisms for USB hot-plug monitoring, hardware information collection, and device registry persistence, making it impossible to retain UKEY hardware identity parameters. This prevents upper-layer Windows applications from generating legitimate USBSTOR virtual devices. For example, when a physical UKEY is inserted into the Linux host's USB port, triggering a kernel USB hot-plug event, Wine's mountmgr component captures the hot-plug signal using the pre-registered udisksDBus device callback function, thereby triggering the cdrom module to start the block device scanning process. The cdrom module recursively traverses all block device directory entries under the Linux system's / sys / block directory, tracing back up the sysfs device tree layer by layer, and sequentially reads the complete set of original hardware information corresponding to each device, including VID (idVendor), PID (idProduct), device model, bus path busnum, and hardware manufacturer. Then, it uses the combination of VID and PID as a unique retrieval identifier to query the Wine registry, compares whether the current hardware has been registered, and filters duplicate devices to avoid duplicate configuration entries. If there is no matching UKEY device entry in the registry, a dedicated device node is created layer by layer under the fixed root path HKLM\Software\Wine\UKeyDevice in the Wine registry, and all hardware information collected this time, such as VID, PID, device model, bus path, and manufacturer, is persistently written into the node as a device identifier key value, completing the local storage of the UKEY hardware identity information. By using mountmgr to monitor hot-plugging and coordinating with the cdrom module to scan the sysfs device tree, fully automated collection of physical U-key hardware information and unique device filtering on the Linux side are achieved. The U-key hardware identity parameters are persistently stored in the Wine registry to form standardized identifier keys, providing unified data support for upper-layer virtual device creation and lower-layer hardware matching.

[0016] Step 120: When the Windows application calls the SetupAPI interface to enumerate storage devices, intercept the call and enter the UKEY processing branch, read the identifier key value in the configuration item, concatenate the identifier key value to generate the USBSTOR standard device identifier, and create a UKEY virtual device instance.

[0017] SetupAPI is a standard device enumeration interface provided by the Windows system. Business software relies on this interface to query and read information about storage hardware devices within the system. It is the core entry point for tax control and government-related UKEY software to identify hardware. The USBSTOR standard device identifier is a unique identification string for storage devices defined by the Windows bus specification. It contains the device manufacturer, product, and instance hash code. The system will only recognize the format identifier to determine that the hardware is a legitimate USB storage disk.

[0018] Wine's native SetupAPI logic does not support USBSTOR encrypted hardware emulation, making it unable to generate compliant device identification. Windows applications enumerating storage devices will directly ignore the physical U-key, causing the software to fail to recognize the hardware. For example, when tax and government-related Windows business software calls SetupAPI standard interfaces such as SetupDiCreateDeviceInfo and SETUPDI_EnumerateMatchingInterfaces to enumerate local storage disk devices, Wine intercepts and redirects the SetupAPI calls, actively jumping to a pre-added U-key-specific processing branch. This branch reads the pre-stored identifier key value in the Wine registry, extracting the complete set of hardware parameters stored within the key value, including VID, PID, hardware manufacturer, device model, and USB bus path (devpath). First, the first 8 characters of the hardware manufacturer name and the first 16 characters of the device model are extracted, and spaces in the strings are uniformly replaced with underscores to generate short manufacturer names and short product names. These are then concatenated according to the fixed template "USBSTOR\Disk&VEN_short manufacturer&PROD_short product&REV_5.00" to obtain the USBSTOR device ID. Then concatenate the bus path, VID, and PID into a complete input string, and iterate through all characters to execute. Iterative hashing is performed to obtain a 32-bit hash value, which is then formatted as an "InstanceID" using a 4-bit hexadecimal hash format (00000). The USBSTOR device ID is concatenated with the InstanceID to obtain the complete USBSTOR standard device identifier. Subsequently, the device creation function is called with the standard device identifier as input. During the creation process, Wine's default ROOT device naming rules are bypassed. The generated virtual device object is registered with the GUID_DEVINTERFACE_DISK standard disk class interface, and a corresponding formatted instance symbolic link is generated and stored in the system device list, completing the creation of the UKEY virtual device instance. If multiple UKEY hardware configuration entries exist in the registry, the system will iterate through all device parameters during batch enumeration, independently generating non-conflicting USBSTOR standard identifiers and independent virtual device instances. Multiple physical UKEYs can be simultaneously recognized by Windows applications. Optionally, taking two UKEY devices as an example, the registry stores two sets of VID, PID, manufacturer, and product parameters respectively. The system will calculate independent hash InstanceIDs separately to generate two complete device identifiers and exclusive symbolic links. Device managers and tax declaration software can simultaneously enumerate and identify the two independent UKEY virtual disks.

[0019] By intercepting SetupAPI device enumeration calls and adding a dedicated UKEY processing branch, a USBSTOR device identity identifier conforming to the Windows bus specification is generated based on registry hardware parameters, completing the standardized conversion of underlying hardware parameters to a Windows-recognizable device identity. This bypasses Wine's native device naming restrictions, generating batch UKEY virtual device instances with independent symbolic links, enabling Windows business software to correctly enumerate and recognize physical UKEY hardware connected under Linux.

[0020] Step 130: When the Windows application initiates a read / write IO request to the UKEY virtual device instance, the mountmgr component triggers a device identity query based on the read / write IO request, obtains and returns the identifier key value of the configuration item, and registers the standard disk device interface for the UKEY virtual device instance to establish the device access entry for the instance.

[0021] The native Wine mountmgr driver lacks PnP identity query processing logic and standard disk interface registration capabilities, and cannot respond to device identity verification requests from Windows applications. Virtual UKEY devices will be denied read and write access by upper-layer business software due to the lack of a legitimate disk access entry point.

[0022] For example, after the UKEY virtual device instance is created, when Windows business software such as tax and government affairs initiates certificate read / write or data interaction read / write IO requests for the UKEY virtual device instance, the Windows system kernel PnP manager will synchronously send an IRP_MN_QUERY_ID device identity query IRP data packet to the mountmgr driver. In this embodiment, the harddisk driver logic is extended in advance in the mountmgr driver, and a dedicated IRP_MJ_PNP main dispatch function harddisk_pnp is registered. After receiving the PnP query request sent by the kernel, the dispatch function locates the configuration item of the corresponding UKEY device in the Wine registry, reads the pre-stored complete set of identification key values, and extracts device identity parameters such as DeviceID, InstanceID, and hardware compatibility ID. Then, the read hardware parameters are converted into a wide string format specified by the Windows system and filled into the return data structure corresponding to the IRP query request to complete the PnP device identity query response. Meanwhile, during the disk device initialization and creation process of the UKEY virtual device instance, the GUID_DEVINTERFACE_DISK standard disk device interface is automatically registered and enabled, generating a unified device access entry that can be recognized and called by Windows applications. The interface will accept all device enumeration and read / write IO requests forwarded by the upper-layer SetupAPI throughout the process. When the virtual device is destroyed or the physical UKEY is removed, the system resources occupied by the interface are automatically released. After processing, the mountmgr component will forward all upper-layer read / write IO requests down to the underlying cdrom subsystem to complete hardware interaction.

[0023] By extending the IRP_MJ_PNP dispatch function of mountmgr to respond to kernel PnP identity queries, and returning compliant device identity data to the system based on registry identifier keys, the complete Windows Plug and Play protocol is completed. Automatic registration of standard disk device interfaces provides a unified system access point for virtual UKEYs, establishing a request transmission link between upper-layer Windows applications and the underlying CD-ROM hardware interaction module.

[0024] In step 140, the mountmgr component forwards the received read / write IO requests to Wine's cdrom module. The cdrom module matches the UKEY device according to the identifier key value in the configuration item and sends the hardware response of the UKEY device back to the Windows application through the device access entry.

[0025] mountmgr is an internal disk management driver component of Wine. It is responsible for managing the virtual disk device interface, distributing read and write I / O requests from upper-layer applications, and serves as an intermediate forwarding hub connecting the Windows application layer and the underlying hardware interaction module.

[0026] Native Wine lacks cross-module forwarding of read / write I / O requests, Linux underlying SCSI hardware channel matching, and disconnection fault tolerance mechanisms. Upper-layer Windows read / write commands cannot be sent to the actual U-key hardware, and hardware response data cannot be sent back to the application. For example, when the mountmgr component receives certificate read / write and data interaction I / O requests from a Windows application, it forwards all I / O requests to Wine's built-in cdrom module. Upon receiving the I / O request, the cdrom module reads the VID and PID hardware parameters stored in the registry configuration key, traverses the Linux system's USB bus device list, matches the / dev / sgSCSI generic device node that perfectly corresponds to the VID and PID, and extracts and caches the corresponding file descriptor. The cdrom module continuously monitors the status of the cached device file descriptors using a polling mechanism. If it detects abnormal scenarios such as U-key removal or USB communication failure, it immediately releases the invalid device file descriptor and automatically triggers a hardware re-matching and reconnection process. When the device file descriptor is valid and available, the cdrom module encapsulates the Windows storage IOCTL and SCSI pass-through read / write I / O requests forwarded by mountmgr into native Linux SCSI pass-through commands, and sends them to the physical UKEY hardware through the cached sg device file descriptor to complete the read / write interaction. After processing the commands, the physical UKEY generates hardware response data, which is transmitted back layer by layer along the original transmission link. First, it is delivered upwards by the cdrom module to the mountmgr component, and then completely transmitted back to the Windows business application that initiated the read / write request through the standard disk device access entry pre-registered by mountmgr. Optionally, taking the entire process of the Kylin system tax control UKEY as an example, after the tax software initiates certificate read / write I / O, mountmgr completes the PnP identity response and forwards the I / O to the cdrom module. The cdrom matches the underlying sg hardware channel and sends SCSI commands to read / write the UKEY. The certificate data returned by the hardware is transmitted back layer by layer to the tax declaration software, fully realizing end-to-end business interaction.

[0027] In this embodiment, when a physical UKEY device is connected to a Linux host, Wine's cdrom module is triggered to traverse block devices, obtain hardware information for each block device through recursive directory access, locate the target UKEY device, create a configuration item for the target UKEY device in the Wine registry, and write an identifier key value based on the hardware information. When a Windows application calls the SetupAPI interface to enumerate storage devices, the call is intercepted and the UKEY processing branch is entered. The identifier key value in the configuration item is read, concatenated to generate a USBSTOR standard device identifier, and a UKEY virtual device instance is created. When the Windows application initiates a read / write IO request to the UKEY virtual device instance, the mountmgr component triggers a device identity query based on the read / write IO request, obtains the identifier key value of the configuration item and returns it, and registers a standard disk device interface for the UKEY virtual device instance to establish a device access entry for the instance. The mountmgr component forwards the received read / write IO request to Wine's cdrom module. The cdrom module matches the UKEY device based on the identifier key value in the configuration item and sends the hardware response of the UKEY device back to the Windows application through the device access entry. By modifying the Wine CD-ROM subsystem, storing hardware identifiers in the registry, and extending the SetupAPI and mountmgr device processing logic, we can achieve simulated identification and bidirectional data interaction of physical UKEY devices in the LinuxWine environment.

[0028] Example 2 Figure 2 This is a flowchart of a UKEY compatibility method based on the Wine optical drive subsystem provided in Embodiment 2 of the present invention. This embodiment is an optimization based on the above embodiment. When the physical UKEY device is connected to the Linux host, the Wine cdrom module is triggered to traverse the block devices, obtain the hardware information of each block device through recursive directory, locate the target UKEY device, create a configuration item for the target UKEY device in the Wine registry, and write the identifier key value based on the hardware information. After this step, the method further includes: when the physical UKEY device is unplugged from the Linux host, deleting the corresponding identifier key value in the registry.

[0029] See Figure 2 The UKEY compatibility method based on the Wine optical drive subsystem includes: Step 210: When the physical UKEY device is connected to the Linux host, Wine's cdrom module is triggered to traverse the block devices, obtain the hardware information of each block device through recursive directory, locate the target UKEY device, create a configuration item for the target UKEY device in the Wine registry, and write an identification key value based on the hardware information. When the physical UKEY device is unplugged from the Linux host, the corresponding identification key value in the registry is deleted.

[0030] For example, when a registered physical UKEY is removed from the Linux host's USB port, the mountmgr component captures the hot-plug event of the USB device removal reported by the kernel through the udisksDBus callback. This triggers the cdrom module to traverse the / sys / block block device directory and backtrack through the sysfs device tree, reading the VID and PID hardware information of all remaining block devices in the current system. The hardware parameters obtained from this scan are compared one by one with the VID and PID identifier keys stored in all device configuration entries under the Wine registry path HKLM\Software\Wine\UKeyDevice. If the VID and PID of a configuration entry in the registry cannot be matched with the corresponding physical device in the current system's hardware list, it is determined that the corresponding UKEY has been removed offline. Subsequently, the hierarchical device node corresponding to the VID and PID in the registry is located, and all identifier keys such as device model, bus path, and manufacturer stored under the node are completely deleted, clearing the invalid hardware registration information to prevent the subsequent SetupAPI from generating non-existent UKEY virtual device instances based on invalid registry data when enumerating devices.

[0031] Step 220: When the Windows application calls the SetupAPI interface to enumerate storage devices, intercept the call and enter the UKEY processing branch, read the identifier key value in the configuration item, concatenate the identifier key value to generate the USBSTOR standard device identifier, and create a UKEY virtual device instance.

[0032] Step 230: When the Windows application initiates a read / write IO request to the UKEY virtual device instance, the mountmgr component triggers a device identity query based on the read / write IO request, obtains and returns the identifier key value of the configuration item, and registers the standard disk device interface for the UKEY virtual device instance to establish the device access entry for the instance.

[0033] In step 240, the mountmgr component forwards the received read / write IO requests to Wine's cdrom module. The cdrom module matches the UKEY device according to the identifier key value in the configuration item and sends the hardware response of the UKEY device back to the Windows application through the device access entry.

[0034] In this embodiment, when a physical U-Key device is connected to a Linux host, Wine's cdrom module is triggered to traverse the block devices, recursively retrieve the hardware information of each block device through the directory, locate the target U-Key device, create a configuration item for the target U-Key device in the Wine registry, and write an identifier key value based on the hardware information. When the physical U-Key device is unplugged from the Linux host, the corresponding identifier key value in the registry is deleted. When a Windows application calls the SetupAPI interface to enumerate storage devices, the call is intercepted and the U-Key processing branch is entered. The identifier key value in the configuration item is read, and the identifier key value is concatenated to generate a USBSTOR standard device. The `mountmgr` component identifies and creates a UKEY virtual device instance. When a Windows application initiates a read / write I / O request to the UKEY virtual device instance, the `mountmgr` component triggers a device identity query based on the read / write I / O request, retrieves the identifier key value from the configuration item, returns it, and registers a standard disk device interface for the UKEY virtual device instance to establish a device access entry for the instance. The `mountmgr` component forwards the received read / write I / O request to Wine's CD-ROM module. The CD-ROM module matches the UKEY device based on the identifier key value in the configuration item and sends the UKEY device's hardware response back to the Windows application through the device access entry. Using this method, the registry is synchronously managed throughout the entire lifecycle of the physical UKEY insertion and removal, real-time cleanup of residual identifier data from offline hardware, prevention of upper-layer applications from enumerating invalid virtual devices, and ensuring that device information is consistent with the physical hardware in real time.

[0035] Example 3 Figure 3 This is a schematic diagram of the structure of the UKEY compatible device based on the Wine optical drive subsystem provided in Embodiment 3 of the present invention, as shown below. Figure 3 As shown, the device includes: Create module 310, which is used to trigger Wine's cdrom module to traverse block devices when a physical UKEY device is connected to a Linux host. It obtains the hardware information of each block device through recursive directory, locates the target UKEY device, creates a configuration item for the target UKEY device in the Wine registry, and writes an identifier key value based on the hardware information. The generation module 320 is used to intercept the call and enter the UKEY processing branch when the Windows application calls the SetupAPI interface to enumerate storage devices, read the identifier key value in the configuration item, concatenate the identifier key value to generate the USBSTOR standard device identifier, and create a UKEY virtual device instance; The query module 330 is used to trigger a device identity query based on the read / write IO request when a Windows application initiates a read / write IO request to the UKEY virtual device instance, obtain the identifier key value of the configuration item and return it, and register the standard disk device interface for the UKEY virtual device instance to establish the device access entry of the instance. Access module 340 is used by the mountmgr component to forward received read / write IO requests to Wine's cdrom module. The cdrom module matches the UKEY device according to the identifier key value in the configuration item and sends the hardware response of the UKEY device back to the Windows application through the device access entry.

[0036] The UKEY-compatible device based on the Wine optical drive subsystem provided in this embodiment, when connected to a Linux host via a physical UKEY device, triggers Wine's cdrom module to traverse block devices, obtains hardware information of each block device through recursive directory, locates the target UKEY device, creates a configuration item for the target UKEY device in the Wine registry, and writes an identifier key value based on the hardware information. When a Windows application calls the SetupAPI interface to enumerate storage devices, the call is intercepted and the UKEY processing branch is entered. The identifier key value in the configuration item is read, concatenated to generate a USBSTOR standard device identifier, and a UKEY virtual device instance is created. When the Windows application initiates a read / write IO request to the UKEY virtual device instance, the mountmgr component triggers a device identity query based on the read / write IO request, obtains the identifier key value of the configuration item and returns it, and registers a standard disk device interface for the UKEY virtual device instance to establish a device access entry for the instance. The mountmgr component forwards the received read / write IO request to Wine's cdrom module. The cdrom module matches the UKEY device based on the identifier key value in the configuration item and sends the hardware response of the UKEY device back to the Windows application through the device access entry. By modifying the Wine CD-ROM subsystem, storing hardware identifiers in the registry, and extending the SetupAPI and mountmgr device processing logic, we can achieve simulated identification and bidirectional data interaction of physical UKEY devices in the LinuxWine environment.

[0037] Based on the above embodiments, the creation module includes: The directory entry traversal unit is used to listen for Linux kernel USB hot-plug events through Wine's mountmgr component, triggering the cdrom module to traverse all block device directory entries under the / sys / block directory of the Linux system. The target device location unit is used to trace back the sysfs device tree layer by layer based on the block device directory entry, read the hardware information of each block device, and locate the target UKEY device. The hardware information includes VID, PID, device model, bus path, and hardware manufacturer. The registration judgment unit is used to retrieve the Wine registry using the VID and PID of the target UKEY device to determine whether the target UKEY device has been registered. The key value writing unit is used to create a target UKEY device node hierarchically in the root path of the Wine registry when the target UKEY device is not registered, and write an identification key value based on hardware information.

[0038] Based on the above embodiments, the generation module includes: The identification key value reading unit is used to read the identification key value in the configuration item. The identification key value includes VID, PID, device model, bus path and hardware manufacturer. The manufacturer truncation unit is used to truncate the first 8 characters of the hardware manufacturer's name and replace spaces in the truncation result with underscores to obtain a short manufacturer's name; The model name extraction unit is used to extract the first 16 characters of the device model name and replace spaces in the extraction result with underscores to obtain a short product name. The identifier splicing unit is used to generate a USBSTOR device identifier by splicing the short manufacturer name and the short product name according to a preset template. The hash value calculation unit is used to sequentially concatenate the bus path, VID and PID into an input string, traverse each character of the input string, and calculate the hash value according to the recursive formula. A standard device identifier generation unit is used to format the hash value into an instance identifier, connect the USBSTOR device identifier with the instance identifier, and generate the USBSTOR standard device identifier; The rule bypass unit is used to call the device creation function with the USBSTOR standard device identifier to generate a virtual device object and bypass Wine's default ROOT naming rules during the creation process; The instance creation unit is used to register the disk class interface for the virtual device object and generate a symbolic link in the corresponding instance identifier format to create a UKEY virtual device instance.

[0039] Based on the above embodiments, the query module includes: The pre-registration unit is used to pre-register the IRP_MJ_PNP main dispatch function in the mountmgr driver; The device parameter reading unit is used to send a query request to the driver of the mountmgr when the Windows application initiates a read / write IO request to the UKEY virtual device instance. After receiving the query request, the IRP_MJ_PNP main dispatch function reads the device identity parameters from the identifier key value of the preset configuration item. The return unit is used to convert the read device identity parameters into Windows format and fill them into the return data structure of the query request.

[0040] Based on the above embodiments, the access module includes: The receiving unit is used by the mountmgr component to forward the received read / write IO request to Wine's cdrom module. After receiving the read / write IO request, the cdrom module reads the VID and PID from the identifier key value in the configuration item. The descriptor acquisition unit is used to traverse the USB bus device list using the read VID and PID, match the SCSI general device node with the same VID and PID, obtain the corresponding device file descriptor and cache it; The matching and reconnection unit is used to continuously monitor the status of the device file descriptor through the poll mechanism. When the device is detected to be unplugged or communication fails, the device file descriptor is automatically released and the rematching and reconnection process is triggered. The return unit is used to encapsulate the read / write I / O request into a SCSI pass-through instruction when the device file descriptor is valid, send it to the UKEY device through the device file descriptor, and return the response data read from the UKEY device to the Windows application through the device access entry.

[0041] The UKEY compatible device based on the Wine optical drive subsystem provided in this embodiment of the invention can execute the UKEY compatible method based on the Wine optical drive subsystem provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of executing the method.

[0042] Example 4 Figure 4 This is a schematic diagram of the structure of a terminal provided in Embodiment 4 of the present invention. Figure 4 A block diagram is shown that is suitable for implementing an exemplary terminal 12 of the present invention. Figure 4 The terminal 12 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0043] like Figure 4As shown, terminal 12 is presented in the form of a general-purpose computing terminal. The components of terminal 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).

[0044] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0045] Terminal 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by terminal 12, including volatile and non-volatile media, removable and non-removable media.

[0046] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache 32. Terminal 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (… Figure 4 Not shown; usually referred to as a "hard drive"). Although Figure 4 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0047] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.

[0048] Terminal 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing terminal, display 24, etc.), and with one or more terminals that enable a user to interact with terminal 12, and / or with any terminal (e.g., network card, modem, etc.) that enables terminal 12 to communicate with one or more other computing terminals. This communication can be performed via input / output (I / O) interface 22. Furthermore, terminal 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 20. As shown, network adapter 20 communicates with other modules of terminal 12 via bus 18. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with terminal 12, including but not limited to: microcode, terminal drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0049] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the UKEY compatible method based on the Wine optical drive subsystem provided in this embodiment of the invention.

[0050] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A UKEY-compatible method based on a Wine optical drive subsystem, characterized in that, include: When a physical UKEY device is connected to a Linux host, Wine's cdrom module is triggered to traverse the block devices, obtain the hardware information of each block device through recursive directory, locate the target UKEY device, create a configuration item for the target UKEY device in the Wine registry, and write an identifier key value based on the hardware information. When a Windows application calls the SetupAPI interface to enumerate storage devices, the call is intercepted and the UKEY processing branch is entered. The identifier key value in the configuration item is read, the identifier key value is concatenated to generate the USBSTOR standard device identifier, and a UKEY virtual device instance is created. When a Windows application initiates a read / write IO request to a UKEY virtual device instance, the mountmgr component triggers a device identity query based on the read / write IO request, obtains and returns the identifier key value of the configuration item, and registers the standard disk device interface for the UKEY virtual device instance to establish the device access entry for the instance. The mountmgr component forwards the received read / write I / O requests to Wine's cdrom module. The cdrom module matches the UKEY device based on the identifier key value in the configuration items and sends the hardware response of the UKEY device back to the Windows application through the device access entry.

2. The method according to claim 1, characterized in that, The CD-ROM module that triggers Wine traverses the block devices, obtains the hardware information of each block device through recursive directory, and locates the target UKEY device, including: Wine's mountmgr component listens for Linux kernel USB hot-plug events, triggering the cdrom module to traverse all block device directory entries under the / sys / block directory of the Linux system. Based on the block device directory entries, the sysfs device tree is traced upwards layer by layer to read the hardware information of each block device and locate the target UKEY device. The hardware information includes VID, PID, device model, bus path and hardware manufacturer.

3. The method according to claim 2, characterized in that, The step of creating a configuration entry for the target UKEY device in the Wine registry and writing an identifier key value based on hardware information includes: Use the VID and PID of the target UKEY device to search the Wine registry to determine whether the target UKEY device has been registered; When the target UKEY device is not registered, a target UKEY device node is created hierarchically in the Wine registry root path, and an identification key value is written based on the hardware information.

4. The method according to claim 2, characterized in that, The process of reading the identifier key value from the configuration item and concatenating the identifier key value to generate the USBSTOR standard device identifier includes: Read the identifier key value from the configuration item. The identifier key value includes VID, PID, device model, bus path, and hardware manufacturer. Extract the first 8 characters of the hardware manufacturer's name and replace spaces with underscores in the extracted result to obtain a short manufacturer's name; Extract the first 16 characters of the device model name and replace spaces with underscores in the extracted result to obtain a short product name; Based on the short manufacturer name and the short product name, a USBSTOR device identifier is generated by concatenating them according to a preset template. The bus path, VID, and PID are concatenated sequentially to form an input string. The hash value is calculated by iterating through each character of the input string using a recursive formula. The hash value is formatted as an instance identifier, and the USBSTOR device identifier is concatenated with the instance identifier to generate the USBSTOR standard device identifier.

5. The method according to claim 1, characterized in that, The step of concatenating the identifier key values ​​to generate the USBSTOR standard device identifier and creating a UKEY virtual device instance includes: The device creation function is called using the USBSTOR standard device identifier to generate a virtual device object, and Wine's default ROOT naming rules are bypassed during the creation process; Register a disk class interface for the virtual device object and generate a symbolic link in the corresponding instance identifier format to create a UKEY virtual device instance.

6. The method according to claim 1, characterized in that, When a Windows application initiates a read / write IO request to the UKEY virtual device instance, the mountmgr component triggers a device identity query based on the read / write IO request, retrieves the identifier key value of the configuration item, and returns it, including: The IRP_MJ_PNP main dispatch function is pre-registered in the mountmgr driver; When a Windows application initiates a read / write IO request to the UKEY virtual device instance, the Linux system kernel PnP manager sends a query request to the mountmgr driver. After receiving the query request, the IRP_MJ_PNP main dispatch function reads the device identity parameter from the identifier key value of the preset configuration item. The read device identity parameters are converted into Windows format and populated into the returned data structure of the query request.

7. The method according to claim 1, characterized in that, The mountmgr component forwards received read / write I / O requests to Wine's cdrom module. The cdrom module matches the UKEY device based on the identifier key value in the configuration items and sends the hardware response of the UKEY device back to the Windows application through the device access entry, including: The mountmgr component forwards the received read / write I / O requests to Wine's cdrom module. After receiving the read / write I / O requests, the cdrom module reads the VID and PID from the identifier key value in the configuration item. Using the read VID and PID, traverse the USB bus device list, match the SCSI generic device node with the same VID and PID, obtain the corresponding device file descriptor and cache it; The status of the device file descriptor is continuously monitored through the poll mechanism. When the device is detected to be unplugged or communication fails, the device file descriptor is automatically released and a rematch and reconnection process is triggered. When the device file descriptor is valid, the read / write I / O request is encapsulated as a SCSI pass-through command, which is sent to the UKEY device through the device file descriptor. The response data read from the UKEY device is then sent back to the Windows application through the device access entry.

8. The method according to claim 1, characterized in that, When the physical UKEY device is connected to the Linux host, Wine's cdrom module is triggered to traverse the block devices, obtain the hardware information of each block device through recursive directory, locate the target UKEY device, create a configuration item for the target UKEY device in the Wine registry, and write the identifier key value based on the hardware information. Following this step, the process also includes: When the physical U-key device is removed from the Linux host, the corresponding identifier key value is deleted from the registry.

9. A UKEY-compatible device based on a Wine optical drive subsystem, characterized in that, include: A module is created to trigger Wine's cdrom module to traverse block devices when a physical UKEY device is connected to a Linux host. The module obtains the hardware information of each block device through recursive directory, locates the target UKEY device, creates a configuration item for the target UKEY device in the Wine registry, and writes an identifier key value based on the hardware information. The generation module is used to intercept the call and enter the UKEY processing branch when the Windows application calls the SetupAPI interface to enumerate storage devices, read the identifier key value in the configuration item, concatenate the identifier key value to generate the USBSTOR standard device identifier, and create a UKEY virtual device instance; The query module is used to trigger device identity query based on read / write IO requests when Windows applications initiate read / write IO requests to the UKEY virtual device instance. It retrieves and returns the identifier key value of the configuration item and registers the standard disk device interface for the UKEY virtual device instance to establish the device access entry of the instance. The access module is used by the mountmgr component to forward received read / write I / O requests to Wine's cdrom module. The cdrom module matches the UKEY device according to the identifier key value in the configuration item and sends the hardware response of the UKEY device back to the Windows application through the device access entry.

10. A terminal, characterized in that, The terminal includes: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the UKEY compatible method based on the Wine CD-ROM subsystem as described in any one of claims 1-8.

Images