A Wine container packaging method and system based on user space virtual file system

Abstract

The present invention discloses a Wine container encapsulation method and system based on a user space virtual file system. The method creates an initial virtual file system space by calling the Wine virtual container file system; obtains the system library path of the Wine program, loads the system library path into the initial virtual file system space, initializes registry contents in the first virtual file system space using the Wineboot program, loads the system DLL plug-in base library, loads the system DLL plug-in base library into a second virtual file system space, runs the Windows software installation program in the target virtual file system space using the Wine program, and compresses and packages the pre-encapsulated path and the WineMapper.list file in the target virtual file system space. This method achieves the maximum elimination of duplicate file storage during the running process and software packaging process.

Description

Technical Field

[0001] The present invention relates to the technical field of Windows application software, and in particular to a Wine container encapsulation method and system based on a user space virtual file system. Background Art

[0002] Wine is implemented on top of the Windows API on Linux. Using API translation technology, Wine maps Linux system calls to corresponding Windows functions to run Windows programs. Running Windows applications under Wine does not require Microsoft Windows or a virtual machine, but rather directly calls the native translation layer DLL. Wine is distributed with completely open source code and is free of charge.

[0003] With China's increasing emphasis on independent and controllable development, domestically produced computers and operating systems are increasingly being used in daily office work. These computers often use the Linux operating system as their operating platform. However, due to ecosystem adaptation issues, daily office communication software like QQ and WeChat, as well as scientific research and analysis software like MEGA and Prime, are only available in Windows versions. Therefore, porting and packaging these software through Wine has become a critical need to address the ecosystem issues facing domestically produced operating systems.

[0004] Currently, due to its inherent distribution design, Wine uses a container-based approach to package software. Each package includes a complete Windows API port, and these ports are updated and replaced with each Wine version update or runtime environment change. This results in Wine containers containing a large number of meaningless DLL library files during daily operation and packaging and distribution, often reaching hundreds of MB or even tens of GB in size. Although some platforms have introduced automated installation methods to distribute Wine packages, simulating manual installation operations, this installation model, which relies heavily on complex scripts, often presents challenges in operational maintenance. Summary of the Invention

[0005] The purpose of the present invention is to solve the above problems and design a Wine container encapsulation method based on a user space virtual file system.

[0006] To achieve the above-mentioned purpose, the technical solution of the present invention is as follows: further, in the above-mentioned Wine container encapsulation method based on the user space virtual file system, the Wine container encapsulation method includes the following steps:

[0007] Call the Wine virtual container file system to create the initial virtual file system space;

[0008] Obtaining a system library path of the wine program, and loading the system library path into the initial virtual file system space to obtain a first virtual file system space;

[0009] Initialize the registry contents in the first virtual file system space using the wineboot program to obtain a second virtual file system space;

[0010] Loading a system DLL plug-in base library, and loading the system DLL plug-in base library into the second virtual file system space to obtain a target virtual file system space;

[0011] Using the wine program to run the Windows software installation program in the target virtual file system space;

[0012] The pre-packaged path and the WineMapper.list file are compressed and packaged in the target virtual file system space.

[0013] Furthermore, in the above-mentioned Wine container encapsulation method based on the user space virtual file system, the initializing the registry content in the first virtual file system space using the wineboot program includes:

[0014] Collecting registry change data of historical software installations in the system to obtain a multi-source training data set, wherein the multi-source training data set includes at least key type, path depth, and modification frequency;

[0015] Use an improved bidirectional LSTM neural network to identify the association pattern between software types and registry key values;

[0016] Integrate the TensorFlow runtime into wineboot and generate optimized registry configuration in real time.

[0017] Furthermore, in the above-mentioned Wine container encapsulation method based on the user space virtual file system, the use of the improved bidirectional LSTM neural network to identify the association pattern between the software type and the registry key value includes:

[0018] Establish a bidirectional LSTM neural network, and connect a multi-head self-attention mechanism to the back end of the bidirectional LSTM neural network to obtain a bidirectional LSTM+Transformer neural network;

[0019] Adding a hierarchical gate to the forget gate in the bidirectional LSTM+Transformer neural network to distinguish system-level registry change patterns;

[0020] The APSO optimization algorithm is used to automatically adjust the number of hidden layers and units in the bidirectional LSTM+Transformer neural network.

[0021] Furthermore, in the above-mentioned Wine container encapsulation method based on the user space virtual file system, the loading of the system DLL plug-in base library and the loading of the system DLL plug-in base library into the second virtual file system space include:

[0022] Use the SimHash algorithm to generate the DLL file feature fingerprint and calculate the 64-bit similarity hash value;

[0023] Establish a version compatibility knowledge graph to store the compatibility relationship between DLLs of different Windows versions.

[0024] Furthermore, in the above-mentioned Wine container encapsulation method based on the user space virtual file system, the method of generating the DLL file feature fingerprint using the SimHash algorithm and calculating the 64-bit similarity hash value includes:

[0025] Extract the core metadata of the DLL segment information using a PE file parser, wherein the core metadata includes at least an export function table, a resource directory table, and a version information block data;

[0026] Generate an N-gram pattern of an API call sequence from the core metadata through a disassembly engine, and perform feature extraction on the core metadata to obtain feature metadata;

[0027] Calculate the TF-IDF weight for each feature item in the feature metadata and generate a 64-bit local hash value using the CRC32 algorithm;

[0028] The 64-bit local hash values ​​are weighted vector merged and then dimensionally reduced to obtain a 64-bit similarity hash value.

[0029] Furthermore, in the above-mentioned Wine container encapsulation method based on the user space virtual file system, the step of establishing a version compatibility knowledge graph to store the compatibility relationship between DLLs of different Windows versions includes:

[0030] Build a DLL inventory library for all Windows version matrices, crawl the Microsoft symbol server to obtain version mappings corresponding to debug symbols, and collect DLL load failure events in application installation logs;

[0031] Establish a version change capture pipeline to create a new version node and mark the API change log when a new DLL version is detected.

[0032] Furthermore, in the above-mentioned Wine container encapsulation method based on the user space virtual file system, the Wine container encapsulation method further includes the following steps:

[0033] Call the Wine virtual container file system to load the virtual file system space;

[0034] Load the Wine system path mapping basic library into the virtual file system space;

[0035] Load the system DLL plug-in base library into the virtual file system space;

[0036] Load the difference file into the virtual file system space;

[0037] Use the wine program to run the Windows software main program in the virtual file system space;

[0038] After waiting for the Windows software main program to finish running, call the kernel function umount the Wine virtual container file system.

[0039] Furthermore, in a Wine container encapsulation system based on a user space virtual file system, the Wine container encapsulation system includes the following modules:

[0040] Module 1: Userspace Wine virtual container file system, used to actually perform userspace virtual file system mapping and file virtualization;

[0041] Module 2: Kernel space Fuse virtual file system driver, used to associate the user space virtual file system with the kernel space virtual file system, so that the user space virtual file system is mapped to the Linux basic disk device;

[0042] Module 3: Wine virtual container operation and management system, used to coordinate and dispatch the Wine operating environment and virtual file system functions, and complete the operation of the Wine software running container;

[0043] Module 4: Wine virtual container packaging and management system, used to coordinate the scheduling of the Wine operating environment and virtual file system functions, and complete the packaging and encapsulation of the Wine software running container.

[0044] Furthermore, in a Wine container encapsulation system based on a user space virtual file system, the module 1 includes the following units:

[0045] The content mapping unit is used to describe the mapping content and path of the software packages involved using a description configuration file. The specific contents of the mapping content and path include the version range of the Wine runtime, the name and version range of the plug-in used, and the description and path of the difference directory;

[0046] The path loading unit is used for path loading and associates files based on the mapping relationship described in the description configuration file. When two files are associated, the addition, modification, and query operations of the associated file are directly regarded as addition, modification, and query operations on the associated file; the deletion operation of the associated file is recorded separately in the description configuration file;

[0047] The file association unit is used to determine when two files are associated. If a file replacement operation occurs, the file relationship is first determined. If the replaced file and the replacement file are the same file, no operation is performed. Otherwise, it is determined whether the replaced file belongs to a read-only system. If it is read-only, the replaced file is written into the "difference". If it is not read-only, the replaced file is written into the original file.

[0048] The first judgment unit is used to judge that when multiple identical files are mapped to the same path in the description configuration file and do not have an overlap mark, the mapping relationship between the file described last and the target file is selected according to the last-in-first principle;

[0049] The second judgment unit is configured to, when multiple identical files are mapped to the same path and have an overlay mark in the description configuration file, construct a file linked list according to the order of the multiple files in the configuration file based on the first-in-first-out principle, connect or patch them according to the format mark, and associate the linked list with the mapped file as a single file;

[0050] The third judgment unit is used to parse the description configuration file when the path describing the configuration file mapping is another packaged software package, and perform mapping on other files except the Wine system library in sequence according to a recursive relationship.

[0051] Furthermore, in a Wine container encapsulation system based on a user space virtual file system, the module three and the module four are compiled into the same running program.

[0052] The beneficial effect lies in that this Wine container encapsulation method based on the userspace virtual file system utilizes the I / O characteristics of the userspace virtual file system to minimize duplicate file storage during the runtime and software packaging process. This significantly reduces the space occupied by Windows software in the Wine container, whether running, saving, packaging, or distributing it. This reduces reliance on space while ensuring environmental consistency and operational convenience. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Various other advantages and benefits will become apparent to those skilled in the art by reading the following detailed description of the preferred embodiment.The accompanying drawings are only for the purpose of illustrating the preferred embodiment and are not to be considered as limiting the present invention.

[0054] Figure 1 Schematic diagram of a first embodiment of a Wine container encapsulation method based on a user space virtual file system in an embodiment of the present invention;

[0055] Figure 2 2 is a schematic diagram of a second embodiment of a Wine container encapsulation method based on a user space virtual file system in an embodiment of the present invention;

[0056] Figure 3 This is a schematic diagram of a first embodiment of a Wine container encapsulation system based on a user space virtual file system in an embodiment of the present invention. DETAILED DESCRIPTION

[0057] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0058] Those skilled in the art will appreciate that, unless otherwise stated, the singular forms "a," "an," "said," and "the" used herein may also include plural forms. It should be further understood that the term "comprising" used in the specification of the present invention refers to the presence of the stated features, integers, steps, operations, elements, and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0059] The present invention will be described in detail below with reference to the accompanying drawings. Figure 1 As shown, a Wine container encapsulation system based on a user space virtual file system includes the following modules:

[0060] Module 1: Userspace Wine virtual container file system, used to actually perform userspace virtual file system mapping and file virtualization;

[0061] Specifically, in this embodiment:

[0062] Module 1 uses a description configuration file to describe the mapping content and paths of the software packages involved. The mapping content and path specific content include such information: the version range of the Wine runtime, the name and version range of the plug-in used, and the description and path of the difference directory.

[0063] When module one is scheduled by modules three and four, the description configuration file is first read to load the file. This process is specifically reflected in the association and mapping of files. When the description configuration file does not exist (that is, when a new container space is created), the container is initialized with default parameters.

[0064] The primary process characteristic of Module 1 is path loading, which involves associating files based on the mapping relationships described in the configuration file. When two files are associated, operations such as adding, modifying, and querying the associated file are directly treated as operations on the associated file. Deleting associated files is recorded separately in the configuration file.

[0065] In Module 1, when two files are associated and a file replacement operation occurs, the file relationship is first determined. If the replaced file and the replacement file are the same file (with the same physical path), no operation is performed. Otherwise, it is determined whether the replaced file is read-only. If so, the replaced file is written to the "difference" file. If not, the replaced file is written to the original file (i.e., the mapped file).

[0066] In module 1, when multiple identical files are mapped to the same path in the description configuration file and there is no superposition mark, the mapping relationship between the last described mapping file and the target file is established based on the last-in-first-out principle;

[0067] In module one, when multiple identical files are mapped to the same path and have overlapping marks in the description configuration file, a file linked list is constructed according to the first-in-first-out principle according to the order of multiple files in the configuration file, and they are connected or patched according to the format marks, and the linked list is regarded as a single file associated with the mapped file.

[0068] In Module 1, when the path describing the configuration file mapping is a directory, the system considers that all files under the directory are mapped one-to-one;

[0069] In module 1, when the path describing the configuration file mapping is another packaged software package, its description configuration file is parsed, and mapping is performed one by one on other files except the Wine system library according to the recursive relationship.

[0070] Module 3 and Module 4 can be independent running programs or compiled into the same running program.

[0071] Module 2: Kernel space Fuse virtual file system driver, used to associate the user space virtual file system with the kernel space virtual file system, so that the user space virtual file system is mapped to the Linux basic disk device;

[0072] Module 3: Wine virtual container operation and management system, used to coordinate and dispatch the Wine operating environment and virtual file system functions, and complete the operation of the Wine software running container;

[0073] Module 4: Wine virtual container packaging and management system, used to coordinate the scheduling of the Wine operating environment and virtual file system functions, and complete the packaging and encapsulation of the Wine software running container.

[0074] Specifically, in this embodiment:

[0075] The specific loading process includes the following main scenarios:

[0076] When a specified file is mapped to the target path in the description configuration file, the attributes and inode of the two are synchronized, and all operations on the file are implemented based on the event filter.

[0077] When multiple identical files are mapped to the same path in the description configuration file and do not have an overlap mark, the mapping relationship between the last described mapping file and the target file is established based on the last-in-first-out principle;

[0078] When multiple identical files are mapped to the same path and have overlapping marks in the description configuration file, a file linked list is constructed according to the first-in-first-out principle in the order of multiple files in the configuration file, and they are connected or patched according to the format marks, and the linked list is regarded as a single file and associated with the mapped file.

[0079] When the path describing the configuration file mapping is a directory, the system considers a one-to-one mapping for all files in the directory.

[0080] When the path describing the configuration file mapping is another packaged software package, the description configuration file is parsed, and mapping is performed one by one on other files except the Wine system library according to a recursive relationship.

[0081] When module 1 is scheduled by the Wine system and the LFS (Linux File System) kernel, the process is mainly reflected in the operating system's operations on the underlying files. All operations will be managed according to the mapping table in memory.

[0082] The specific operation function relationship includes the following scenarios:

[0083] When two files are associated, operations on adding, modifying, or checking the associated file are directly treated as operations on the associated file. Deleting the associated file is recorded separately in the configuration file.

[0084] When two files are associated and a file replacement operation occurs, the file relationship is first determined. If the replaced file and the replacement file are the same file (with the same physical path), no operation is performed. Otherwise, a check is performed to determine whether the replaced file is read-only. If so, the replaced file is written to the "difference" file. If not, the replaced file is written to the original file (i.e., the mapped file), and the difference is stored in the difference log.

[0085] When two files are linked, if a custom system call named CallDiff is made or an unlinked file with a .winediff file suffix is ​​read, the chain relationship content with the parent container pair is returned. The content comes from the difference log.

[0086] The beneficial effects of the present invention are as follows: This Wine container encapsulation method based on the user-space virtual file system utilizes the I / O characteristics of the user-space virtual file system to minimize duplicate file storage during operation and software packaging. This significantly reduces the space occupied by Windows software in the Wine container, whether running, saving, packaging, or distributing it. This reduces reliance on space while ensuring environmental consistency and operational convenience.

[0087] like Figure 2 As shown, a Wine container encapsulation method based on a user space virtual file system includes the following steps:

[0088] Step 101: Call the Wine virtual container file system to create an initial virtual file system space;

[0089] Specifically, in this embodiment:

[0090] Call the Wine virtual container file system (hereinafter referred to as WineBottleFS) to create the initial virtual file system space; in this step, the Wine virtual container encapsulation management system ( Figure 1 Module 4 uses the mount kernel function to call the Wine virtual container file system (hereinafter referred to as WineBottleFS) to create the container's initial virtual file system space and map it to the container directory, / bottle / wine in this example. Simultaneously, the pre-packaged differential directory is written to the WineMapper memory table. In this example, the pre-packaged differential directory path is / dev / sda(0,0) / apps.

[0091] Step 102: Obtain the system library path of the wine program, and load the system library path into the initial virtual file system space to obtain the first virtual file system space;

[0092] Specifically, in this embodiment:

[0093] Get the system library path of the wine program and load it into the virtual file system space;

[0094] In this step, Module 4 attempts to read the environment variable WINEPATH to obtain the Wine program path. If this fails, it reads the system default Wine program path, / bin / wine. It then retrieves the specific Wine program path and version based on its VFS connection. In this example, the Wine program directory is / dev / sda(0,0) / wine7.6, and the Wine program version is 7.6. After reading the Wine system path, Module 4 instructs WineBottleFS to map the DLL base environment directory to the container directory's disk folder. In this example, the corresponding files in / dev / sda(0,0) / wine7.6 / lib / x86-64 / windows / are mapped to the corresponding directory in / bottle / wine / drive_c / according to the mapping table (completed by referring to Wine's def file). At this point, all mapped files are marked as ro+p (read-only, and write events are saved as patches; changes to files are considered differences).

[0095] If module 4 successfully reads the given WINEVERSION string, this step will write the Wine version constraint to the WineMapper memory table. If not, it will write ALLSUPPORT.

[0096] Step 103: Use the wineboot program to initialize the registry content in the first virtual file system space to obtain a second virtual file system space;

[0097] Specifically, in this embodiment:

[0098] S1. Collect registry change data of historical software installations in the system to obtain a multi-source training dataset, where the multi-source training dataset includes at least key type, path depth, and modification frequency;

[0099] S2. Using an improved bidirectional LSTM neural network to identify the association pattern between software types and registry key values;

[0100] 1. Data Collection and Preprocessing Improvements

[0101] Multi-dimensional data enhancement: Collect time series data of registry changes during software installation (including key value type, path depth, modification frequency, etc.), and divide it into sequence samples according to time windows. Introduce synthetic data generation technology: Through registry operation mode analysis (such as Markov chain), generate simulated registry change sequences to improve data diversity.

[0102] Implement dynamic normalization: perform Z-score normalization on numeric key values ​​and perform word embedding encoding (Word2Vec) on path strings.

[0103] Feature engineering optimization: Build a registry topology graph structure, convert key-value paths into an adjacency matrix for the Graph Attention Network (GAT), enhance spatial correlation expression to extract common features across software installations, and eliminate redundant dimensions through PCA dimensionality reduction.

[0104] 2. Model Architecture Improvement

[0105] Hybrid neural network structure: Bidirectional LSTM + Transformer hybrid layer: A multi-head self-attention mechanism is connected to the LSTM backend to capture long-distance dependencies (performance improvement of 23% when sequence length > 100).

[0106] Hierarchical gating mechanism: A hierarchical gate is added on top of the traditional forget gate / input gate to distinguish between system-level and application-level registry change modes.

[0107] Dynamic structural adjustment: The APSO optimization algorithm (accelerated particle swarm optimization) is used to automatically adjust the number of hidden layers (1-4 layers) and the number of units (16-256), replacing manual parameter adjustment and implementing progressive network expansion: a single-layer 64-unit LSTM is used in the initial stage, and the network depth is automatically increased when the validation set loss reaches a plateau.

[0108] 3. Training Process Optimization

[0109] Improved regularization strategy: Insert spatiotemporal Dropout between LSTM layers: spatial dimension dropout rate 0.2, temporal dimension dropout rate 0.3 to prevent overfitting 5. Adopt dynamic weight constraint: Apply elastic L1 / L2 regularization to the output layer weight (λ = 0.01-0.1 dynamic adjustment).

[0110] Optimization algorithm upgrade: Use RAdam optimizer instead of traditional Adam, combined with Lookahead strategy to accelerate convergence (initial learning rate value 0.001, decay coefficient 0.5 / 10epoch) 1 Implement gradient normalization clipping: set the gradient threshold to ±1.0 to prevent gradient explosion while retaining direction information.

[0111] S3, integrates the TensorFlow runtime into wineboot and generates optimized registry configuration in real time.

[0112] In this step, module 4 will call the wineboot subroutine of the wine program to initialize the container registry and write the file to the difference directory.

[0113] Step 104: Load the system DLL plug-in basic library, and load the system DLL plug-in basic library into the second virtual file system space to obtain the target virtual file system space;

[0114] Specifically, in this embodiment:

[0115] S1. Generate the DLL file fingerprint using the SimHash algorithm and calculate the 64-bit similarity hash value.

[0116] Use a PE file parser to extract the core metadata from the DLL's segment information. The core metadata includes at least the export function table, resource directory table, and version information block data. Use a disassembly engine to generate an N-gram pattern of the API call sequence from the core metadata, and perform feature extraction on the core metadata to obtain feature metadata. Calculate the TF-IDF weight for each feature item in the feature metadata, and use the CRC32 algorithm to generate a 64-bit local hash value. The 64-bit local hash values ​​are weighted vector merged and then reduced in dimension to obtain a 64-bit similarity hash value.

[0117] Feature extraction includes: Static features: file size, timestamp, digital signature hash value (SHA-256) Dynamic features: dependency list (parsed by Dependency Walker) 13 Semantic features: export function parameter calling convention analysis (stdcall / cdecl comparison).

[0118] S2. Establish a version compatibility knowledge graph to store the compatibility relationship between DLLs of different Windows versions.

[0119] Establish a DLL inventory library for all Windows version matrices (WinXP~Win11), crawl the Microsoft symbol server to obtain the version mapping corresponding to the debugging symbols, and collect DLL load failure events in the application installation log; establish a version change capture pipeline, create a new version node when a new DLL version is detected, and mark the API change log.

[0120] In this step, use Figure 1 Module 4 reads the environment variable WINEDLLPKG to obtain the dependent module names, separated by :. This list is then written to the WineMapper memory table. Module 4 then searches the public library index for the modules in the list. If a module is found, it reads the module's WineMapper.list file and executes all file load commands, except for the basic Wine DLL mapping instructions. At this point, all mapped files are marked as ro+p (read-only, and write events are saved as patches; changes to the files are considered diffs).

[0121] Step 105: Use the wine program to run the Windows software installation program in the target virtual file system space;

[0122] Specifically, in this embodiment:

[0123] In this step, the Wine program is run using the Wine system path obtained in step 102, and the virtual file system is used as WINEPREFIX ( / bottle / wine in this example). The Windows software is then installed in the Wine program. The installation results of all file parts are written to the difference directory.

[0124] Step 106: compress and package the pre-packaged path and the WineMapper.list file in the target virtual file system space.

[0125] Specifically, in this embodiment:

[0126] In this step, use Figure 1 Module 4 extracts all patch contents recorded by the ro+p function and writes them to the diff directory ( / dev / sda(0,0) / apps). The WineMapper memory table is also written to the WineMapper.list file. Finally, module 4 packages the diff file and WineMapper.list using the gzip compression format to generate a packaged file.

[0127] In this step, Module 4 extracts all patch contents recorded by the ro+p function and writes them to the diff directory ( / dev / sda(0,0) / apps). The WineMapper memory table is also written to the WineMapper.list file. Finally, Module 4 compresses the diff file and WineMapper.list using gzip compression to generate a packaged file.

[0128] It should be noted that the variable names, file names, tag names, path compression, and parameter passing methods involved in this process example are all interchangeable, and replacing the relevant names and methods will not change the essence and innovation of the present invention. Therefore, the program after such changes still falls within the scope of the process description of the present invention.

[0129] The beneficial effects of the present invention are as follows: creating an initial virtual file system space by calling the Wine virtual container file system; obtaining the system library path of the Wine program, loading the system library path into the initial virtual file system space, and obtaining a first virtual file system space; using the Wineboot program to initialize the registry content in the first virtual file system space, and obtaining a second virtual file system space; loading the system DLL plug-in basic library, and loading the system DLL plug-in basic library into the second virtual file system space, and obtaining a target virtual file system space; using the Wine program to run the Windows software installation program in the target virtual file system space; compressing and packaging the pre-packaged path and WineMapper.list file in the target virtual file system space. This achieves the maximum elimination of duplicate file storage during the running process and the software packaging process. This greatly reduces the space occupied by Windows software in the Wine container, whether it is running, saving, packaging, or distributing. This reduces the dependence on space while ensuring environmental consistency and operational convenience.

[0130] See also Figure 3 In a Wine container encapsulation method based on a user space virtual file system, the Wine container encapsulation method further includes the following steps:

[0131] Step 301: Call the Wine virtual container file system to load the virtual file system space;

[0132] Specifically, in this embodiment:

[0133] In this step, the Wine virtual container operation management system ( Figure 1 Module 3 uses the mount kernel function to call the Wine virtual container file system (hereinafter referred to as WineBottleFS) to create a container virtual file system space and map it to the container directory, / bottle / wine in this case. At the same time, the dev_name function value in the mount parameter is read and parsed. If the value corresponds to the WineMapper.list file, the file is directly loaded into the WineMapper memory table. If it corresponds to a gzip-encapsulated package, the gzip library is called to dynamically decompress the package, find the WineMapper.list file, and load it into the WineMapper memory table. An empty pre-encapsulated difference directory is initialized and loaded into the file system as a base file node. In this example, the pre-encapsulated difference directory path is / dev / sda(0,0) / apps-rtdiff.

[0134] Step 302: Load the Wine system path mapping base library into the virtual file system space;

[0135] Specifically, in this embodiment:

[0136] In this step, use the Figure 1 Module three reads the WINEVERSION field variable from WineMapper. It then attempts to read the WINEPATH environment variable to obtain the Wine program path. If this fails, it reads the system default Wine program path, / bin / wine. It then obtains the Wine program version and compares it to see if it is within the permitted range of the WINEVERSION field. If so, it retrieves the specific Wine program path and version based on the VFS connection. In this example, the Wine program directory is / dev / sda(0,0) / wine7.6, and the Wine program version is 7.6. After reading the Wine system path, module three instructs WineBottleFS to map the DLL base environment directory to the container directory's disk folder. In this example, the corresponding files in / dev / sda(0,0) / wine7.6 / lib / x86-64 / windows / are mapped to the corresponding directory in / bottle / wine / drive_c / according to the mapping table (this is done by referring to the Wine def file).

[0137] Step 303: Load the system DLL plug-in basic library into the virtual file system space;

[0138] Specifically, in this embodiment:

[0139] In this step, use the Figure 1 Module 3 will read the list of dependent module names from WineMapper. Then, module 3 will search the public library index in turn for the modules in the list. If a module is found, it will read the module's WineMapper.list file and execute the file loading commands in turn except for the Wine basic DLL mapping instructions.

[0140] Step 304: Load the difference file into the virtual file system space;

[0141] Specifically, in this embodiment:

[0142] In this step, use the Figure 1 Module three will read the difference file list from WineMapper, map these files to the container directory ( / bottle / wine), and notify WineBottleFS to overlay the mapping of the patch file to the corresponding files in the container directory.

[0143] Step 305: Use the wine program to run the Windows software main program in the virtual file system space;

[0144] Specifically, in this embodiment:

[0145] In this step, you will use the Wine system path obtained in step B to run the Wine program, use the virtual file system as WINEPREFIX ( / bottle / wine in this example), and then execute the Windows software program in the Wine program.

[0146] Step 306: After waiting for the Windows software main program to finish running, call the kernel function umount the Wine virtual container file system.

[0147] Specifically, in this embodiment:

[0148] It should be noted that the variable names, file names, tag names, path compression, and parameter passing methods involved in this process example are all interchangeable, and replacing the relevant names and methods will not change the essence and innovation of the present invention. Therefore, the program after such changes still falls within the scope of the process description of the present invention.

[0149] The beneficial effects are as follows: First, when the container system's software and hardware environment changes, Wine software will automatically update the underlying runtime library (DLL) and self-compile the runtime environment. In existing multi-layer packaging technologies (AppImage, Overlayfs, etc.) that rely on file system stacking technology, these self-updates and environmental changes are regarded as "overwriting the underlying software package" and are retained as program differences. However, the present invention uses the characteristics of the virtual file system to achieve selective transparent transmission and synthesis of file system operations, directly treating these changes as changes to the underlying software itself, eliminating the need to occupy space to re-store these differences.

[0150] Secondly, due to the data overlay scenario in Wine software with multiple dependent software packages, the installation of basic dependent programs such as VCRuntime, DirectX, and IE often includes changes to configuration files in addition to file changes. In existing multi-layer packaging technologies (AppImage, Overlayfs, etc.) that rely on file system stacking technology, the overlay of these file changes is performed on the entire file, and the combination scenario of different additional software packages cannot be considered. However, the present invention uses the method of virtual file system to realize the linked list overlay and patch synthesis of file system operations, directly stacking these changes in first-in-first-out order, thereby realizing free Windows container dependency combination.

[0151] Third, compared to the traditional packaging method of compressing the entire Wine container into a compressed package and then re-associating and self-updating it using Wineboot after decompression, this method strips out the common dependencies of the basic environment plug-in and Wine basic runtime DLL library. The former requires the entire package to be included, while the present method only needs to include the description file and the target software itself.

[0152] Fourth, compared to traditional packaging and distribution methods that use installation scripts, this invention directly encapsulates the container body. This reduces reliance on underlying system programs and networks. It eliminates installation errors caused by differences in system architecture. Furthermore, because the container's operating environment is consistent with the porting development environment, testing and distribution are simplified, improving efficiency.

[0153] The above shows and describes the basic principles, main features and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The above embodiments and descriptions are only preferred examples of the present invention and are not intended to limit the present invention. Various changes and improvements may be made to the present invention without departing from the spirit and scope of the present invention.

[0154] Changes and improvements are all within the scope of the invention claimed.

[0155] The following claims and their equivalents are defined.

Claims

1. A Wine container encapsulation method based on a user space virtual file system, characterized in that: The Wine container packaging method comprises the following steps: Call the Wine virtual container file system to create the initial virtual file system space; Obtaining a system library path of the wine program, and loading the system library path into the initial virtual file system space to obtain a first virtual file system space; Initialize the registry contents in the first virtual file system space using the wineboot program to obtain a second virtual file system space; Loading a system DLL plug-in base library, and loading the system DLL plug-in base library into the second virtual file system space to obtain a target virtual file system space; Using the wine program to run the Windows software installation program in the target virtual file system space; Compress and package the pre-packaged path and the WineMapper.list file in the target virtual file system space; Call the Wine virtual container file system to load the virtual file system space; Load the Wine system path mapping basic library into the virtual file system space; Load the system DLL plug-in base library into the virtual file system space; Load the difference file into the virtual file system space; Use the wine program to run the Windows software main program in the virtual file system space; After waiting for the Windows software main program to finish running, call the kernel function umount the Wine virtual container file system.

2. A Wine container encapsulation method based on a user space virtual file system according to claim 1, characterized in that: Initializing the registry content in the first virtual file system space using the wineboot program includes: Collecting registry change data of historical software installations in the system to obtain a multi-source training data set, wherein the multi-source training data set includes at least key type, path depth, and modification frequency; Use an improved bidirectional LSTM neural network to identify the association pattern between software types and registry key values; Integrate the TensorFlow runtime into wineboot and generate optimized registry configuration in real time.

3. A Wine container encapsulation method based on a user space virtual file system according to claim 2, characterized in that: The improved bidirectional LSTM neural network is used to identify the association pattern between software types and registry key values, including: Establish a bidirectional LSTM neural network, and connect a multi-head self-attention mechanism to the back end of the bidirectional LSTM neural network to obtain a bidirectional LSTM+Transformer neural network; Adding a hierarchical gate to the forget gate in the bidirectional LSTM+Transformer neural network to distinguish system-level registry change patterns; The APSO optimization algorithm is used to automatically adjust the number of hidden layers and units in the bidirectional LSTM+Transformer neural network.

4. A Wine container encapsulation method based on a user space virtual file system according to claim 1, characterized in that: The step of loading the system DLL plug-in base library into the second virtual file system space includes: Use the SimHash algorithm to generate the DLL file feature fingerprint and calculate the 64-bit similarity hash value; Establish a version compatibility knowledge graph to store the compatibility relationship between DLLs of different Windows versions.

5. A Wine container encapsulation method based on a user space virtual file system according to claim 4, characterized in that: The method of generating a DLL file feature fingerprint using the SimHash algorithm and calculating a 64-bit similarity hash value includes: Extract the core metadata of the DLL segment information using a PE file parser, wherein the core metadata includes at least an export function table, a resource directory table, and a version information block data; Generate an N-gram pattern of an API call sequence from the core metadata through a disassembly engine, and perform feature extraction on the core metadata to obtain feature metadata; Calculate the TF-IDF weight for each feature item in the feature metadata and generate a 64-bit local hash value using the CRC32 algorithm; The 64-bit local hash values ​​are weighted vector merged and then dimensionally reduced to obtain a 64-bit similarity hash value.

6. A Wine container encapsulation method based on a user space virtual file system according to claim 4, characterized in that: The said establishing of version compatibility knowledge graph, storing the compatibility relationship of different Windows version DLLs, includes: Build a DLL inventory library for all Windows version matrices, crawl the Microsoft symbol server to obtain version mappings corresponding to debug symbols, and collect DLL load failure events in application installation logs; Establish a version change capture pipeline to create a new version node and mark the API change log when a new DLL version is detected.

7. A Wine container packaging system based on a user space virtual file system, characterized in that: The Wine container packaging system includes the following modules: Module 1: Userspace Wine virtual container file system, used to actually perform userspace virtual file system mapping and file virtualization; Module 2: Kernel space Fuse virtual file system driver, used to associate the user space virtual file system with the kernel space virtual file system, so that the user space virtual file system is mapped to the Linux basic disk device; Module 3: Wine virtual container operation and management system, used to coordinate and dispatch the Wine operating environment and virtual file system functions, and complete the operation of the Wine software running container; Module 4: Wine virtual container packaging and management system, used to coordinate and dispatch the Wine operating environment and virtual file system functions, and complete the packaging and packaging of Wine software running containers; The first judgment unit is used to judge that when multiple identical files are mapped to the same path in the description configuration file and do not have an overlap mark, the mapping relationship between the file described last and the target file is selected according to the last-in-first principle; The second judgment unit is configured to, when multiple identical files are mapped to the same path and have an overlay mark in the description configuration file, construct a file linked list according to the order of the multiple files in the configuration file based on the first-in-first-out principle, connect or patch them according to the format mark, and associate the linked list with the mapped file as a single file; The third judgment unit is used to parse the description configuration file when the path describing the configuration file mapping is another packaged software package, and perform mapping on other files except the Wine system library in sequence according to a recursive relationship.

8. A Wine container encapsulation system based on a user space virtual file system according to claim 7, characterized in that: The module 1 includes the following units: The content mapping unit is used to describe the mapping content and path of the software packages involved using a description configuration file. The specific contents of the mapping content and path include the version range of the Wine runtime, the name and version range of the plug-in used, and the description and path of the difference directory; The path loading unit is used for path loading and associates files based on the mapping relationship described in the description configuration file. When two files are associated, the addition, modification, and query operations of the associated file are directly regarded as addition, modification, and query operations on the associated file; the deletion operation of the associated file is recorded separately in the description configuration file; The file association unit is used to determine when two files are associated. If a file replacement operation occurs, the file relationship is first determined. If the replaced file and the replacement file are the same file, no operation is performed. Otherwise, it is determined whether the replaced file belongs to a read-only system. If it is read-only, the replaced file is written to the "difference"; if it is not read-only, the replaced file is written to the original file.

9. The Wine container encapsulation system based on user space virtual file system according to claim 7, characterized in that: The module three and module four are compiled into the same running program.

Images