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

Abstract

The invention discloses a Wine container packaging method and system based on a user space virtual file system. An initial virtual file system space is created by calling a Wine virtual container file system; obtaining a system library path of a wineboot program, loading the system library path into the initial virtual file system space, using the wineboot program to initialize registry content in the first virtual file system space, loading a system DLL plug-in basic library, loading the system DLL plug-in basic library into a second virtual file system space, and loading the system DLL plug-in basic library into the second virtual file system space. Running an installation program of the Windows software in the target virtual file system space by using a wind program; and compressing and packaging the pre-packaged path and the WineMapper.list file in the space of the target virtual file system. Repeated storage of files is abandoned to the maximum extent in the running process and the 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 Windows API on Linux. Wine uses API conversion technology to run Windows programs by mapping Linux system calls to corresponding Windows functions. Running Windows applications under Wine does not require Microsoft Windows system or virtual machines, but directly calls the local conversion layer DLL. Wine is released with completely open source code and is distributed free of charge.

[0003] Domestic computers often use the Linux operating system as their operating platform, but daily office communication software such as QQ and WeChat and scientific research analysis software such as MEGA and Prime have only released Windows versions due to ecological adaptation reasons. Therefore, porting and packaging these software through Wine has become one of the important needs to solve the ecological problems of domestic operating systems.

[0004] Currently, due to the distribution design of the Wine software itself, it uses a container-independent way to package the software, that is, each software package contains a complete Windows API porting implementation, and these implementations will be updated and replaced every time the Wine version is updated or the operating environment changes. This causes the Wine running container to contain a large number of meaningless DLL library files during daily operation and packaging distribution, and the size of these files is often as high as hundreds of MB or even tens of GB. Although some platforms have launched a way to distribute Wine software packages by simulating manual installation operations and automating the installation process, the problems caused by this installation mode that relies heavily on complex operation scripts are usually difficult to operate and maintain. Summary of the invention

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

[0006] To achieve the above object, the technical solution of the present invention is that, further, in the above-mentioned Wine container encapsulation method based on user space virtual file system, the Wine container encapsulation 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; Using the wineboot program to initialize the registry content in the first virtual file system space to obtain a second virtual file system space; Loading a system DLL plug-in basic library, and loading the system DLL plug-in basic 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; The pre-packaged path and the WineMapper.list file are compressed and packaged in the target virtual file system space.

[0007] Further, in the above Wine container encapsulation method based on user space virtual file system, the using of wineboot program to initialize registry content in the first virtual file system space 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 value type, path depth, and modification frequency; Use the improved bidirectional LSTM neural network to identify the association pattern between software types and registry key values; Integrate TensorFlow runtime into wineboot to generate optimized registry configuration in real time.

[0008] Furthermore, in the above-mentioned Wine container encapsulation method based on user space virtual file system, the use of improved bidirectional LSTM neural network to identify the association pattern between software type and registry key value includes: 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 the system-level registry change mode; The APSO optimization algorithm is used to automatically adjust the number of hidden layers and units in the bidirectional LSTM+Transformer neural network.

[0009] Further, in the above-mentioned Wine container encapsulation method based on user space virtual file system, the loading of the system DLL plug-in basic library and the loading of the system DLL plug-in basic library into the second virtual file system space include: 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.

[0010] Furthermore, in the above-mentioned Wine container encapsulation method based on user space virtual file system, the method of generating DLL file feature fingerprint by using SimHash algorithm and calculating 64-bit similarity hash value includes: Extract the core metadata by extracting the segment information of the DLL using a PE file parser, wherein the core metadata includes at least an export function table, a resource directory table, and version information block data; The core metadata is used to generate an N-gram pattern of an API call sequence through a disassembly engine, and features are extracted from 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.

[0011] Furthermore, in the above-mentioned Wine container encapsulation method based on user space virtual file system, the step of establishing a version compatibility knowledge graph and storing the compatibility relationship between DLLs of different Windows versions 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.

[0012] Furthermore, in the above-mentioned Wine container encapsulation method based on user space virtual file system, the Wine container encapsulation method further includes the following steps: Call the Wine virtual container file system to load the virtual file system space; Load the Wine system path mapping base 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.

[0013] Furthermore, in a Wine container encapsulation system based on a user space virtual file system, the Wine container encapsulation system includes the following modules: Module 1: User space Wine virtual container file system, used to actually perform user space 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 management system, which is 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 management system, used to coordinate the scheduling of Wine operating environment and virtual file system functions, and complete the packaging and packaging of Wine software running containers.

[0014] Further, in a Wine container encapsulation system based on a user space virtual file system, 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 by 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. It associates files according to 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 the addition, modification and query operations of 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 into the "difference". If it is not read-only, the replaced file is written into the original file; 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 last described mapping file and the target file is selected according to the last-in-first principle; The second judgment unit is used for, when there are multiple identical files mapped to the same path in the description configuration file and with an overlay mark, to build a file linked list according to the order of the multiple files in the configuration file according to the first-in-first-out principle, to connect or patch stack according to the format mark, and to 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.

[0015] 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.

[0016] The beneficial effect is that, through the Wine container encapsulation method based on the user space virtual file system, the IO characteristics of the user space virtual file system are utilized to achieve the maximum elimination of duplicate file storage during the operation process and software packaging process. This greatly reduces the space occupied by Windows software in the Wine container, whether it is running, saving, packaging, or distributing. It reduces the dependence on space while ensuring environmental consistency and operation convenience. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the following detailed description of the preferred embodiment.The drawings are only for the purpose of illustrating the preferred embodiments and are not to be construed as limiting the invention.

[0018] Figure 1 It is a 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; Figure 2 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; Figure 3 The first embodiment schematic diagram of a Wine container encapsulation system based on a user space virtual file system in an embodiment of the present invention. DETAILED DESCRIPTION

[0019] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with 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.

[0020] 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 features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or groups thereof.

[0021] The present invention will be described in detail below in conjunction with the accompanying drawings. Figure 1 As shown, a Wine container encapsulation system based on a user space virtual file system includes the following modules: Module 1: User space Wine virtual container file system, used to actually perform user space virtual file system mapping and file virtualization; Specifically, in this embodiment: Module 1 uses a description configuration file to describe the mapping content and path of the software packages involved. The specific content of the mapping content and path includes such information as 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.

[0022] When module one is scheduled by module three and module four, the description configuration file is first read to load the file. The specific embodiment of this process is the association and mapping of the 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.

[0023] The main process feature of module one is path loading. The specific loading process is to associate files according to 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 the addition, modification, and query operations of the associated file. The deletion operation of the associated file is recorded separately in the description configuration file.

[0024] In module 1, 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 (with the same physical path), 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 (i.e. the mapped file).

[0025] 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 last described mapping file is selected to establish a mapping relationship with the target file according to the last-in-first principle; 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 in the order of multiple files in the configuration file, and connected or patch stacked according to the format marks, and the linked list is regarded as a single file associated with the mapped file.

[0026] 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; In module 1, when the path describing the configuration file mapping is another packaged software package, the description configuration file is parsed, and the mapping is performed one by one on other files except the Wine system library according to the recursive relationship.

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

[0028] 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 management system, which is 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 management system, used to coordinate the scheduling of Wine operating environment and virtual file system functions, and complete the packaging and packaging of Wine software running containers.

[0029] Specifically, in this embodiment: The specific loading process includes the following main scenarios: When a specified file is mapped to the target path in the description configuration file, the attributes and inodes of the two are synchronized, and all operations on the file are implemented based on the event filter.

[0030] When multiple identical files are mapped to the same path in the description configuration file and there is no superposition mark, the last described mapping file is selected to establish a mapping relationship with the target file according to the last-in-first principle; 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 connected or patch stacked according to the format marks, and the linked list is regarded as a single file associated with the mapped file.

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

[0032] 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.

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

[0034] The specific operation function relationship includes the following scenarios: When two files are associated, the operations of adding, modifying, and checking the associated file are directly regarded as the operations of adding, modifying, and checking the associated file. The operation of deleting the associated file is recorded separately in the description configuration file.

[0035] 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 (with the same physical path), 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 (i.e. the mapped file), and the difference is stored in the difference log.

[0036] When two files are associated, if a custom system call named CallDiff is made to them or an unassociated 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.

[0037] The beneficial effects of the present invention are as follows: the Wine container encapsulation method based on the user space virtual file system utilizes the IO characteristics of the user space virtual file system to achieve the maximum degree of abandonment of duplicate file storage during the operation 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.

[0038] like Figure 2 As shown, a Wine container encapsulation method based on a user space virtual file system, the Wine container encapsulation method comprises the following steps: Step 101: Call the Wine virtual container file system to create an initial virtual file system space; Specifically, in this embodiment: 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) Use the mount kernel function to call the Wine virtual container file system (hereinafter referred to as WineBottleFS) to create the container initial virtual file system space and map it to the container directory, which is / bottle / wine in this case; at the same time, write the pre-packaged difference directory into the WineMapper memory table. In this case, the pre-packaged difference directory path is / dev / sda(0,0) / apps.

[0039] Step 102: Obtain the system library path of the wine program, load the system library path into the initial virtual file system space, and obtain the first virtual file system space; Specifically, in this embodiment: Get the system library path of the wine program and load it into the virtual file system space; In this step, module 4 will try to read the environment variable WINEPATH to obtain the Wine program path. If it fails to obtain, it will read the system default Wine program path / bin / wine. And obtain the specific Wine program path and program 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 completing the reading of the Wine system path, module 4 notifies WineBottleFS to map the DLL basic environment directory to the disk folder of the container directory. In this example, the corresponding files in / dev / sda(0,0) / wine7.6 / lib / x86-64 / windows / are mapped to the corresponding directory / bottle / wine / drive_c / according to the mapping table (completed with reference to Wine's def file). At this time, all mapped files are marked as ro+p (read-only and write events are saved as Patch, and changes to files are considered differences at this time).

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

[0041] Step 103: Use the wineboot program to initialize the registry content in the first virtual file system space to obtain the second virtual file system space; Specifically, in this embodiment: S1. Collect registry change data of historical software installations in the system to obtain a multi-source training data set, where the multi-source training data set at least includes key value type, path depth, and modification frequency; S2, using the improved bidirectional LSTM neural network to identify the association pattern between software types and registry key values; 1. Data Collection and Preprocessing Improvements Multi-dimensional data enhancement: Collect the 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 windows35. Introduce synthetic data generation technology: Through registry operation mode analysis (such as Markov chain), generate simulated registry change sequences to improve data diversity.

[0042] Implement dynamic normalization: perform Z-score normalization on numeric key values ​​and perform word embedding encoding (Word2Vec) on path strings. Feature engineering optimization: Build a registry topology structure, convert the key-value path into the adjacency matrix of the graph attention network (GAT), enhance the spatial correlation expression to extract common features across software installations, and eliminate redundant dimensions through PCA dimensionality reduction. 2. Model Architecture Improvement 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 is improved by 23% when sequence length > 100).

[0043] Hierarchical gating mechanism: A hierarchical gate is added on the basis of the traditional forget gate / input gate to distinguish the system-level / application-level registry change mode.

[0044] 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 enters the plateau period. 3. Training process optimization Improved regularization strategy: Insert spatiotemporal Dropout between LSTM layers: the spatial dimension dropout rate is 0.2, and the temporal dimension dropout rate is 0.3 to prevent overfitting. Adopt dynamic weight constraints: Apply elastic L1 / L2 regularization to the output layer weights (dynamic adjustment of λ=0.01-0.1).

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

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

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

[0048] 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; Specifically, in this embodiment: S1. Generate the DLL file feature fingerprint using the SimHash algorithm and calculate the 64-bit similarity hash value; The core metadata is extracted from the segment information of the DLL using a PE file parser. The core metadata includes at least the export function table, resource directory table, and version information block data. The core metadata is converted into an N-gram pattern of the API call sequence through a disassembly engine, and features are extracted from the core metadata to obtain feature metadata. The TF-IDF weight is calculated for each feature item in the feature metadata, and a 64-bit local hash value is generated using the CRC32 algorithm. The 64-bit local hash values ​​are weighted vector merged and then reduced in dimension to obtain a 64-bit similarity hash value.

[0049] 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).

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

[0051] 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.

[0052] In this step, use Figure 1Module 4 will read the environment variable WINEDLLPKG to get the dependent module names separated by :. And write the read list into the WineMapper memory table. Then module 4 will traverse the public library index to find the modules in the list. If the module is found, it will read the WineMapper.list file of the module and execute the file loading commands except the Wine basic DLL mapping instructions in turn. At this time, all mapped files are marked as ro+p (read-only and write events are saved as Patch, and changes to the files are considered differences).

[0053] Step 105: Use the wine program to run the Windows software installation program in the target virtual file system space; Specifically, in this embodiment: 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), and then the Windows software is installed in the Wine program. The installation results of all file parts are written to the difference directory.

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

[0055] Specifically, in this embodiment: In this step, use Figure 1 Module 4 will extract all the patch contents recorded by the ro+p function and write them into the difference directory ( / dev / sda(0,0) / apps). At the same time, the WineMapper memory table is also written into the WineMapper.list file. Finally, module 4 will use the gzip compression format to package the difference file and WineMapper.list to generate a package file.

[0056] In this step, module 4 will extract all the patch contents recorded by the ro+p function and write them into the difference directory ( / dev / sda(0,0) / apps). At the same time, the WineMapper memory table is also written into the WineMapper.list file. Finally, module 4 will use the gzip compression format to package the difference file and WineMapper.list to generate a package file.

[0057] It should be noted that the variable names, file names, tag names, path compression, and parameter transfer methods involved in this process example are all interchangeable, and changing the relevant names and methods will not change the essence and innovation of the present invention. Therefore, such changed programs still belong to the process description category of the present invention.

[0058] 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 the first virtual file system space; using the wineboot program to initialize the registry content in the first virtual file system space, and obtaining the 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 the 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. The duplicate storage of files is abandoned to the greatest extent in the running process and the software packaging process. The space occupied by Windows software in the Wine container is greatly reduced whether it is running, saving, packaging, or distributing. The dependence on space is reduced while ensuring environmental consistency and running convenience.

[0059] 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: Step 301, calling the Wine virtual container file system to load the virtual file system space; Specifically, in this embodiment: In this step, the Wine virtual container operation management system ( Figure 1 Module 3) Use 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, which is / bottle / wine in this case; at the same time, read the dev_name function value in the mount parameter, parse the value, and if the value corresponds to the WineMapper.list file, directly load the file into the WineMapper memory table. If it corresponds to a gzip package, call the gzip library to dynamically decompress the package, find the WineMapper.list file and load it into the WineMapper memory table. At the same time, initialize an empty pre-packaged difference directory and load it into the file system as a basic file node. In this example, the path of the pre-packaged difference directory is / dev / sda(0,0) / apps-rtdiff.

[0060] Step 302: Load the Wine system path mapping base library into the virtual file system space; Specifically, in this embodiment: In this step, use the Figure 1 Module three will read the WINEVERSION field variable from WineMapper. Then it will try to read the environment variable WINEPATH to get the Wine program path. If it fails to get it, it will read the system default Wine program path / bin / wine. Get its Wine program version and compare it to see if it is within the permitted range of the WINEVERSION field. If the check is correct, get the specific Wine program path and program 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 completing the reading of the Wine system path, module three notifies WineBottleFS to map the DLL base environment directory to the disk folder of the container directory. In this example, the corresponding files in / dev / sda(0,0) / wine7.6 / lib / x86-64 / windows / are mapped to the corresponding directory / bottle / wine / drive_c / according to the mapping table (completed by referring to the def file of Wine).

[0061] Step 303: Load the system DLL plug-in basic library into the virtual file system space; Specifically, in this embodiment: 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 for the modules in the list one by one. If a module is found, it will read the WineMapper.list file of the module and execute the file loading commands except the basic DLL mapping instructions of Wine one by one.

[0062] Step 304: Load the difference file into the virtual file system space; Specifically, in this embodiment: In this step, use the Figure 1 Module 3 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.

[0063] Step 305: Use the wine program to run the Windows software main program in the virtual file system space; Specifically, in this embodiment: In this step, you will run the Wine program using the Wine system path obtained in step B, use the virtual file system as WINEPREFIX ( / bottle / wine in this case), and then execute the Windows software program in the Wine program.

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

[0065] Specifically, in this embodiment: It should be noted that the variable names, file names, tag names, path compression, and parameter transfer methods involved in this process example are all interchangeable, and changing the relevant names and methods will not change the essence and innovation of the present invention. Therefore, such changed programs still belong to the process description category of the present invention.

[0066] The beneficial effect is that, first, when the software and hardware environment of the container system changes, Wine software will self-update the basic runtime library (DLL) and self-compile the runtime environment. In the existing multi-layer package encapsulation technology (AppImage, Overlayfs, etc.) that relies on file system stacking technology, these self-updates and environmental changes will be regarded as "overwriting the underlying software package" operations and regarded as program differentiation and retained. The present invention uses the characteristics of the virtual file system to achieve selective transparent transmission and synthesis of file system operations, directly regards these changes as changes in the underlying software itself, so that there is no need to occupy space to re-store these differences.

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

[0068] Third, compared with the traditional packaging method of compressing the entire Wine container using a compressed package, and then re-associating the system and self-updating using wineboot after decompression, the present invention strips off the common dependent basic environment plug-in and Wine basic operation DLL library. The former needs to include all contents when packaging, while the present invention only needs to include the description file and the target software itself.

[0069] Fourth, compared with the traditional packaging and distribution method using installation scripts, the present invention directly encapsulates the container body. This reduces the dependence on the underlying system programs and networks. The installation program will not be abnormal due to the difference in the system architecture itself. At the same time, since the operating environment of the container is consistent with the content of the transplant development environment, the difficulty of testing and distribution is reduced, and the efficiency is improved.

[0070] 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 by 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. Without departing from the spirit and scope of the present invention, the present invention may have various changes and improvements, which fall within the scope of the present invention to be protected. The scope of protection of the present invention is defined by the attached claims and their equivalents.

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; Using the wineboot program to initialize the registry content in the first virtual file system space to obtain a second virtual file system space; Loading a system DLL plug-in basic library, and loading the system DLL plug-in basic 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; The pre-packaged path and the WineMapper.list file are compressed and packaged in the target virtual file system space.

2. A Wine container encapsulation method based on a user space virtual file system as claimed in claim 1, characterized in that: The using the wineboot program to initialize the registry content in the first virtual file system space 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 value type, path depth, and modification frequency; Use the improved bidirectional LSTM neural network to identify the association pattern between software types and registry key values; Integrate TensorFlow runtime into wineboot to generate optimized registry configuration in real time.

3. A Wine container encapsulation method based on a user space virtual file system as claimed in claim 2, characterized in that: The improved bidirectional LSTM neural network is used to identify the association pattern between the software type and the registry key value, including: A bidirectional LSTM neural network is established, and a multi-head self-attention mechanism is connected 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 the system-level registry change mode; 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 as claimed in claim 1, characterized in that: The loading of the system DLL plug-in basic library, loading the system DLL plug-in basic 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 as claimed in claim 4, characterized in that: The method of using the SimHash algorithm to generate the DLL file feature fingerprint and calculate the 64-bit similarity hash value includes: Extract the core metadata by extracting the segment information of the DLL using a PE file parser, wherein the core metadata includes at least an export function table, a resource directory table, and version information block data; The core metadata is used to generate an N-gram pattern of an API call sequence through a disassembly engine, and features are extracted from 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 as claimed in claim 4, characterized in that: The said establishing a version compatibility knowledge graph to store the compatibility relationship between DLLs of different Windows versions 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 encapsulation method based on a user space virtual file system as claimed in claim 1, characterized in that: The Wine container packaging method further includes the following steps: Call the Wine virtual container file system to load the virtual file system space; Load the Wine system path mapping base 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.

8. 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: User space Wine virtual container file system, used to actually perform user space 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 management system, which is 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 management system, used to coordinate the scheduling of Wine operating environment and virtual file system functions, and complete the packaging and packaging of Wine software running containers.

9. A Wine container encapsulation system based on a user space virtual file system as claimed in claim 8, characterized in that: The module 1 comprises the following units: The content mapping unit is used to describe the mapping content and path of the software packages involved by 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. It associates files according to 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 the addition, modification and query operations of 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 into the "difference"; if it is not read-only, the replaced file is written into the original file; 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 last described mapping file and the target file is selected according to the last-in-first principle; The second judgment unit is used for, when there are multiple identical files mapped to the same path in the description configuration file and with an overlay mark, to build a file linked list according to the order of the multiple files in the configuration file according to the first-in-first-out principle, to connect or patch stack according to the format mark, and to 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.

10. A Wine container encapsulation system based on a user space virtual file system as claimed in claim 8, characterized in that: The module three and module four are compiled into the same running program.

Images