Windows dynamic library calling method, system and equipment suitable for bank medical Linux system and medium
By constructing an adaptation layer module and an environment simulation module, the problem of loading and calling Windows DLL files under the Linux system was solved, enabling efficient and secure calling of Windows dynamic libraries for medical terminal devices, and solving the problems of high resource consumption and low calling efficiency in existing technologies.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-11-28
- Publication Date
- 2026-04-10
AI Technical Summary
Existing technologies for migrating DLL files from Windows platforms to Linux systems suffer from insufficient versatility, high resource consumption, and low calling efficiency, especially evident in medical terminal devices.
A method for calling Windows dynamic libraries suitable for the Yinyi Linux system is constructed, including a DLL loading unit, a function parsing unit, a parameter conversion unit, and a call execution unit. These units enable the loading, parsing, and calling of Windows dynamic link libraries under the Linux system. Combined with an environment simulation module and security verification, the legality of DLL files and the optimization of system resources are ensured.
It achieves precise support for specific social security-related DLL libraries in the medical industry, reduces system resource consumption, improves function call efficiency, and ensures the stability and response speed of medical terminal devices.
Smart Images

Figure CN121833089A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The application relates to the technical field of Windows dynamic library calling, in particular to a Windows dynamic library calling method, system, device and medium suitable for a silver medical Linux system. BACKGROUND
[0002] With the popularization of domestic operating systems, the medical terminal and other industries gradually migrate the system from Windows to the Linux platform. The medical terminal system needs to be connected with the social security system, and the interface library provided by the social security system and social security card reader manufacturers in various places is mostly a DLL file on the Windows platform. Due to the differences in underlying technologies between the two systems, these DLL files cannot be directly used in the Linux system, which brings great obstacles to system migration.
[0003] The current common prior art solution is to use a compatibility layer such as Wine. Wine is a compatibility layer that can run Windows applications on Unix-like systems such as Linux. It simulates Windows APIs and runtime environments, allowing some Windows programs to run on Linux systems. Disadvantages of the prior art: 1. Strong universality but poor targeting: Wine aims to support various Windows programs, but it does not support the specific social security-related DLL library in the medical industry well, which may cause calling failure, abnormal function, etc. 2. Large resource consumption: Wine needs to simulate a large number of Windows system components and environments, which consumes a lot of system resources and is not suitable for resource-constrained devices such as medical terminals. 3. Low calling efficiency: Due to the universal design of Wine, its calling process is complex and generates a lot of additional overhead, resulting in low calling efficiency and affecting the response speed of the medical terminal, which may delay the medical service process. SUMMARY
[0004] The application provides a Windows dynamic library calling method, system, device and medium suitable for a silver medical Linux system to solve the problems of strong universality but poor targeting, large resource consumption and low calling efficiency in existing solutions.
[0005] In a first aspect, the application provides a Windows dynamic library calling method suitable for a silver medical Linux system, the method comprising: building an adaptation layer module, the adaptation layer module including a DLL loading unit, a function analysis unit, a parameter conversion unit and a calling execution unit; loading the target dynamic link library file on the Windows platform in the Linux system environment through the DLL loading unit; The function resolution unit parses the exported function information in the target dynamic link library file and establishes a mapping relationship between function names and function entry addresses. When a Linux application needs to call a function in a target dynamic link library, the parameter conversion unit converts Linux system-compatible parameter data into Windows system-compatible parameter data. By calling the execution unit based on the mapping relationship between function name and function entry address, the function code segment pointed to by the function entry address is executed using the converted parameter data. The execution result is then converted into data of Linux system compatible type by the parameter conversion unit and returned to the Linux application.
[0006] In one implementation of this application, before loading the target dynamic link library file for the Windows platform in a Linux system environment via the DLL loading unit, the method further includes: Build an environment simulation module; The environment simulation module simulates the Windows operating environment within a Linux system environment.
[0007] In one implementation of this application, the target dynamic link library file for the Windows platform is loaded in a Linux system environment through a DLL loading unit, specifically including: Obtain the target dynamic link library file for the Windows platform; Read the PE format structure of dynamic link library files to obtain file layout, section information, import table and export table contents; Based on the section information, the Windows system is simulated through the environment simulation module, and independent memory space is allocated for dynamic link library files; Based on the import table, identify the dynamic link library files that have dependencies on the dynamic link library files; The environment simulation module matches the simulated implementations of dynamically linked library files with dependencies in the Linux system and queries the actual memory addresses of the corresponding dependent functions in the simulated implementation. Fill the actual memory address into the import address table corresponding to the import table.
[0008] In one implementation of this application, after loading the target dynamic link library file for the Windows platform in a Linux system environment via a DLL loading unit, the method further includes: When loading the target dynamic link library file, digital signature verification is performed on the target dynamic link library file to check whether the file has been signed by a legitimate publisher; The target dynamic link library file is confirmed to have been tampered with by calculating its hash value and comparing it with a preset hash value.
[0009] In one implementation of this application, the exported function information in the target dynamic link library file is parsed by a function resolution unit to establish a mapping relationship between function names and function entry addresses, specifically including: Read the export table of the target dynamic link library file; extract the name, ordinal number, and entry address of the exported functions from the export table, and establish a mapping relationship between function names and function entry addresses, storing it in the function mapping table.
[0010] In one implementation of this application, before converting Linux system-compatible parameter data to Windows system-compatible parameter data through the parameter conversion unit, the method further includes: Based on the differences in string types between Linux and Windows systems, a string type conversion program was created. Based on the difference in integer type length between Linux and Windows systems, an integer type length conversion program was created. Based on the differences in structure alignment methods between Linux and Windows systems, a structure alignment conversion program was created. Based on the differences in pointer address space mapping between Linux and Windows systems, a pointer address space mapping conversion program was created.
[0011] In one implementation of this application, before executing the function code segment pointed to by the entry address according to the function calling convention of the Windows platform, the method further includes: The input parameters of the input function code segment are subjected to a preset validity check, and input parameters that do not meet the preset validity are filtered out.
[0012] Secondly, this application provides a Windows dynamic library calling system suitable for the Yinyi Linux system, the system comprising: The DLL loading unit is used to load target dynamic link library files for the Windows platform in a Linux system environment; The function resolution unit is used to parse the exported function information in the target dynamic link library file and establish a mapping relationship between function names and function entry addresses; The parameter conversion unit is used to convert parameter data of Linux system compatibility type to parameter data of Windows system compatibility type. The execution unit is used to execute the function code segment pointed to by the function entry address based on the mapping relationship between function name and function entry address, and to use the converted parameter data. The execution result is then converted into data of Linux system compatible type by the parameter conversion unit and returned to the Linux application.
[0013] Thirdly, this application provides a Windows dynamic library calling device suitable for the Yinyi Linux system, the device comprising: processor; And memory, on which executable code is stored, which, when executed, causes the processor to execute a Windows dynamic library calling method applicable to the Yinyi Linux system, as described above.
[0014] Fourthly, this application provides a non-volatile computer storage medium storing computer instructions thereon, which, when executed, implement a Windows dynamic library calling method applicable to the Yinyi Linux system as described above.
[0015] As can be seen from the above technical solutions, this application has the following advantages: By constructing an adaptation layer module specifically for the Linux system of the medical and healthcare industry, the problem of existing technologies being highly general but lacking specificity is solved. This adaptation layer module directly loads target dynamic link library files for the Windows platform through a DLL loading unit, and establishes a precise mapping relationship between function names and function entry addresses through a function resolution unit. This achieves accurate support for specific social security-related DLL libraries in the medical industry, avoiding call failures and functional abnormalities caused by general compatibility design.
[0016] The optimized modular design reduces system resource consumption. Compared to general solutions that require simulating numerous Windows system components and environments, this application implements core functions only through necessary parameter conversion units and execution call units, avoiding redundant system resource consumption. This streamlined architecture is particularly suitable for resource-constrained devices such as medical terminals, ensuring stable system operation in resource-limited environments.
[0017] The simplified calling process improves calling efficiency. The calling execution unit directly looks up the entry address based on pre-established function mapping relationships and executes the function code according to the Windows platform calling conventions, avoiding the complex intermediate conversion process in general solutions. This direct calling mechanism reduces additional overhead, improves the response speed of medical terminals, and ensures the timeliness of medical service processes. Attached Figure Description
[0018] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the description will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0019] Figure 1This is a flowchart of a Windows dynamic library calling method applicable to the Yinyi Linux system provided in this application embodiment.
[0020] Figure 2 This is a schematic diagram of the internal structure of a Windows dynamic library calling system applicable to the Yinyi Linux system, provided in an embodiment of this application.
[0021] Figure 3 This is a schematic diagram of the internal structure of a Windows dynamic library calling device applicable to a medical Linux system, provided in an embodiment of this application. Detailed Implementation
[0022] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0023] Those skilled in the art should understand that the embodiments described below are merely preferred embodiments of this disclosure and do not imply that this disclosure can only be implemented through these preferred embodiments. These preferred embodiments are merely used to explain the technical principles of this disclosure and are not intended to limit the scope of protection of this disclosure. Based on the preferred embodiments provided by this disclosure, all other embodiments obtained by those skilled in the art without creative effort should still fall within the scope of protection of this disclosure.
[0024] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.
[0025] The technical solutions proposed in the embodiments of this application will be described in detail below with reference to the accompanying drawings.
[0026] This embodiment provides a method for calling Windows dynamic libraries applicable to the Linux system of a hospital and hospital, such as... Figure 1 As shown in the embodiments of this application, the method mainly includes the following steps: Step 110: Construct the adaptation layer module, which includes a DLL loading unit, a function parsing unit, a parameter conversion unit, and a call execution unit.
[0027] It should be noted that step 110, constructing the adaptation layer module, includes a DLL loading unit, a function parsing unit, a parameter conversion unit, and a call execution unit. The DLL loading unit is configured to parse the PE format structure of the target DLL file on the Windows platform to obtain the file layout, section information, import table, and export table. It also allocates independent memory space for the DLL file to avoid memory conflicts with other processes in the Linux system, handles the DLL file's dependencies on other DLLs, and completes import table relocation to ensure normal loading. The function parsing unit is configured to read the export table after the DLL file is loaded to extract the names, ordinal numbers, and entry addresses of exported functions, establish and store a mapping table between function names and function entry addresses, and can handle commonly used social security interface functions for medical terminals (such as authentication functions). The function (e.g., functions for querying numbers and medical insurance information) is marked and preprocessed; the parameter conversion unit is configured to implement data type conversion between Linux and Windows systems, specifically including mutual conversion between UTF-8 encoded strings and Unicode encoded strings, length conversion of integer types between Linux and Windows systems, adjustment of the alignment of structure members in the Linux system according to Windows rules, and establishment of pointer mapping relationship between Linux address space and DLL internal address space; the call execution unit is configured to support the execution of target functions according to the function calling convention of the Windows platform (such as __stdcall, __cdecl), can receive parameters processed by the parameter conversion unit and pass them to the target function, and can also receive function execution results and pass them to the parameter conversion unit for format conversion.
[0028] Step 120: Load the target dynamic link library file for the Windows platform in the Linux system environment using the DLL loading unit.
[0029] The method further includes the following steps before loading the target dynamic link library file for the Windows platform in the Linux system environment via the DLL loading unit: Build an environment simulation module; The environment simulation module simulates the Windows operating environment within a Linux system environment.
[0030] Specifically, loading the target dynamic link library file for the Windows platform in a Linux system environment via the DLL loading unit includes: Obtain the target dynamic link library file for the Windows platform; Read the PE format structure of dynamic link library files to obtain file layout, section information, import table and export table contents; Based on the section information, the Windows system is simulated through the environment simulation module, and independent memory space is allocated for dynamic link library files; Based on the import table, identify the dynamic link library files that have dependencies on the dynamic link library files; The environment simulation module matches the simulated implementations of dynamically linked library files with dependencies in the Linux system and queries the actual memory addresses of the corresponding dependent functions in the simulated implementation. Fill the actual memory address into the import address table corresponding to the import table.
[0031] It should be further explained that before loading the target dynamic link library file through the DLL loading unit, the constructed environment simulation module is configured to reproduce the basic operating environment of the Windows system in the Linux system: First, it provides a key-value pair storage and access interface that matches the functions of the Windows registry, supporting the target DLL to read and modify configuration information at runtime; Second, it implements the simulation logic of commonly used APIs in Windows core libraries (such as user32.dll, kernel32.dll, and advapi32.dll), covering functions such as memory allocation (GlobalAlloc), file operation (CreateFile), and time acquisition (GetSystemTime); Third, it simulates the Windows memory management mechanism, supporting virtual memory allocation, memory protection attribute settings, and memory page management, ensuring that the target DLL runs according to Windows memory operation rules.
[0032] When obtaining the target dynamic link library file through the DLL loading unit, it can be read from the specified storage path of the medical terminal. The target file contains social security-related DLLs (such as SSSE32.dll). When reading the PE format structure, the DOS header, PE header, and section table are parsed in sequence to extract the file layout (starting address and size of code segment, data segment, and resource segment), section information (memory attributes and alignment of each section), import table (names of dependent DLLs and names of functions to be imported), and export table (entries of its own exported functions), providing basic data for subsequent loading.
[0033] Based on the section information, the memory management unit of the environment simulation module allocates an independent memory space for the target DLL. This space is isolated from the address spaces of other Linux processes, and the memory attributes are configured according to the section information (such as setting the code segment to be readable and executable, and the data segment to be readable and writable). After determining the dependent DLL according to the import table, the environment simulation module queries its simulation implementation library in Linux, extracts the actual memory address of the dependent function (such as GlobalAlloc in kernel32.dll), fills it into the import address table of the target DLL import table, and completes the address relocation.
[0034] The method further includes, after loading the target dynamic link library file for the Windows platform in the Linux system environment via the DLL loading unit: When loading the target dynamic link library file, digital signature verification is performed on the target dynamic link library file to check whether the file has been signed by a legitimate publisher; The target dynamic link library file is confirmed to have been tampered with by calculating its hash value and comparing it with a preset hash value.
[0035] It should be noted that a security verification is initiated when the target DLL is loaded: first, digital signature verification is performed, the file signature block is parsed, the certificate validity and certificate chain integrity are verified, and the publisher's legitimacy is confirmed; then, the file hash value is calculated using the SHA-256 algorithm and compared with the preset hash value provided by the legitimate publisher; if the signature verification fails or the hash value does not match, loading is terminated; if both pass, the subsequent exported function call stage can proceed.
[0036] Step 130: Parse the exported function information in the target dynamic link library file through the function resolution unit, and establish a mapping relationship between function names and function entry addresses.
[0037] Specifically, the function resolution unit, based on the starting address and structure information of the export table in the PE format of the target dynamic link library file obtained by the DLL loading unit, reads the export directory entries, function address table, name table, and name ordinal table contained in the export table; extracts the string name of each exported function from the name table, extracts the ordinal number of the corresponding function from the name ordinal table, extracts the entry address of the corresponding function from the function address table, establishes the association between the name table and the function address table through the name ordinal table, and then extracts the name, ordinal number, and entry address of each exported function; subsequently, using the function name as the key and the function entry address as the value, a key-value pair function mapping table is constructed and stored in a designated memory area of the Linux system. Among them, for commonly used social security-related exported functions of medical terminals (such as authentication functions and medical insurance information query functions), their function category identifiers are synchronously marked in the function mapping table so that the target function can be quickly located when the Linux application initiates a call.
[0038] Step 140: When a Linux application needs to call a function in the target dynamic link library, the parameter conversion unit converts the parameter data of the Linux system compatible type into the parameter data of the Windows system compatible type.
[0039] In some embodiments, when a Linux application needs to call a function in a target dynamic link library, the parameter conversion unit converts Linux system-compatible parameter data into Windows system-compatible parameter data, specifically including: Based on the differences in string types between Linux and Windows systems, a string type conversion program was created (Linux systems typically use UTF-8 encoded strings, while Windows systems mostly use Unicode encoded strings. This unit can convert between the two encoding methods to ensure that no information is lost or erroneous during the transmission of string parameters). Based on the difference in integer type length between Linux and Windows systems, an integer type length conversion program is established (because Linux and Windows systems have different definitions of integer types, such as the number of bits of the Linux long type and the Windows DWORD type may be different, this unit can perform integer type length conversion according to the actual situation to ensure numerical accuracy). Based on the differences in structure alignment between Linux and Windows systems, a structure alignment conversion program is established (Windows and Linux systems have different alignment rules for structure members. This unit adjusts the alignment of structure members in Linux according to the structure alignment rules of Windows system to ensure that the memory layout of structure parameters during transmission meets the requirements of Windows functions). Based on the differences in pointer address space mapping between Linux and Windows systems, a pointer address space mapping conversion program is established (establishing a mapping relationship between the Linux address space and the internal address space of the DLL, enabling correct reference of pointers in the address spaces of the two systems, and ensuring that functions can correctly access the data pointed to by the pointers).
[0040] Step 150: By calling the execution unit based on the mapping relationship between function name and function entry address, the function code segment pointed to by the function entry address is executed using the converted parameter data. The execution result is then converted into data of Linux system compatible type by the parameter conversion unit and returned to the Linux application.
[0041] It should be noted that the execution unit first receives the name of the function to be called from the Linux application via the application interface module, queries the function mapping table stored in the function resolution unit, and accurately matches and extracts the corresponding function entry address based on the function name. Next, it confirms the Windows function calling convention (such as __stdcall or __cdecl) followed by the function to be called. If it is __stdcall, the called function performs stack cleanup; if it is __cdecl, the execution unit is responsible for stack cleanup and allocates registers according to the convention (such as ECX and EDX for passing the first two parameters). Then, the Windows-compatible parameters processed by the parameter conversion unit are pushed onto the memory stack or registers according to the parameter passing order of the calling convention (such as pushing from right to left), triggering the execution of the function code segment. After the function execution is completed, the execution unit obtains the output result (including return value and output parameters) and passes it to the parameter conversion unit, which performs the conversion according to the Linux data type standard (strings are converted back to UTF-8, integers are adjusted to the corresponding Linux length, structures are restored to Linux alignment, and pointers are mapped back to the Linux address space). Finally, the result is returned to the Linux application via the application interface module.
[0042] Before executing the function code segment pointed to by the entry address according to the function calling convention of the Windows platform, the method also includes: The input parameters of the input function code segment are subjected to a preset validity check, and input parameters that do not meet the preset validity are filtered out.
[0043] The specific detection content can be as follows: First, parameter type matching detection, comparing whether the actual type of the input parameter is consistent with the preset parameter type of the function to be called to avoid type mismatch; second, parameter value range detection, for parameters with clear restrictions (such as the 18-digit ID number parameter of the social security identity verification function), verifying whether the value conforms to the rules; third, pointer parameter validity detection, checking whether the pointer points to a memory area that has been allocated and accessed by the Linux system, excluding null pointers and wild pointers; if any parameter is illegal, the calling execution unit terminates the call and returns an error message, and if all parameters are valid, the subsequent process continues.
[0044] As described above, this embodiment constructs a dedicated adaptation layer module to realize the interactive adaptation between the Linux system and the Windows platform library, including key functions such as DLL loading, function parsing, parameter conversion, and call execution. By using an environment simulation module, the basic operating environment of a Windows system is simulated in a Linux system, thus solving the problem of DLL libraries' dependency on the Windows system environment. A security verification module is introduced to perform digital signature verification and integrity checks on the loaded DLL files to ensure system security. Performance optimization steps were implemented, and function call efficiency was improved by establishing a call caching and preloading mechanism. The method for calling Windows dynamic libraries applicable to the Yinyi Linux system includes building an adaptation layer module, and the steps of loading the DLL, parsing functions, converting parameters, and executing the call through this module.
[0045] The specific implementation methods and functions of each unit (DLL loading unit, function parsing unit, parameter conversion unit, and call execution unit) in the adaptation layer module. The environment simulation module simulates the basic operating environment of the Windows system (registry operations, system APIs, memory management mechanisms). The specific methods for performing digital signature verification and integrity checks on DLL files during the security verification process.
[0046] The performance optimization steps include establishing a call cache and adopting a preloading mechanism. The system that implements the above method includes an adaptation layer module, an environment simulation module, a security verification module, and an application interface module. This method and system are applied in the field of medical terminals, especially in the application of calling social security-related Windows platform DLL libraries in domestic Linux systems.
[0047] In addition, this application Figure 2 This application provides a Windows dynamic library calling system suitable for a medical and healthcare Linux system. For example... Figure 2 As shown in the embodiments of this application, the system mainly includes: DLL loading unit 210 is used to load target dynamic link library files for the Windows platform in a Linux system environment; The function parsing unit 220 is used to parse the exported function information in the target dynamic link library file and establish a mapping relationship between function names and function entry addresses; The parameter conversion unit 230 is used to convert parameter data of Linux system compatible type into parameter data of Windows system compatible type.
[0048] The execution unit 240 is used to execute the function code segment pointed to by the function entry address based on the mapping relationship between the function name and the function entry address, and to return the execution result to the Linux application after converting it into data of Linux system compatible type through the parameter conversion unit.
[0049] The above are method embodiments of this application. Based on the same inventive concept, this application also provides a Windows dynamic library calling device suitable for the Yinyi Linux system. Figure 3 As shown, the device includes: a processor; and a memory storing executable code thereon, which, when executed, causes the processor to perform a Windows dynamic library calling method applicable to the Yinyi Linux system as described in the above embodiment.
[0050] Specifically, the server-side implementation constructs an adaptation layer module, which includes a DLL loading unit, a function resolution unit, a parameter conversion unit, and a call execution unit. The DLL loading unit loads the target dynamic link library file for the Windows platform within the Linux system environment. The function resolution unit parses the exported function information in the target dynamic link library file, establishing a mapping between function names and function entry addresses. When a Linux application needs to call a function in the target dynamic link library, the parameter conversion unit converts Linux-compatible parameter data into Windows-compatible parameter data. Based on the mapping between function names and function entry addresses, the call execution unit executes the function code segment pointed to by the function entry address using the converted parameter data. The execution result is then converted back to Linux-compatible data by the parameter conversion unit and returned to the Linux application.
[0051] In addition, this application embodiment also provides a non-volatile computer storage medium storing executable instructions, which, when executed, implement the Windows dynamic library calling method applicable to the Yinyi Linux system as described above.
[0052] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A method for calling Windows dynamic libraries in a medical and healthcare Linux system, characterized in that, The method includes: An adaptation layer module is constructed, which includes a DLL loading unit, a function parsing unit, a parameter conversion unit, and a call execution unit; Load the target dynamic link library file for the Windows platform in a Linux system environment using the DLL loading unit; The function resolution unit parses the exported function information in the target dynamic link library file and establishes a mapping relationship between function names and function entry addresses. When a Linux application needs to call a function in a target dynamic link library, the parameter conversion unit converts Linux system-compatible parameter data into Windows system-compatible parameter data. By calling the execution unit based on the mapping relationship between function name and function entry address, the function code segment pointed to by the function entry address is executed using the converted parameter data. The execution result is then converted into data of Linux system compatible type by the parameter conversion unit and returned to the Linux application.
2. The Windows dynamic library calling method applicable to the medical and healthcare Linux system according to claim 1, characterized in that, Before loading the target dynamic link library file for the Windows platform in a Linux system environment via the DLL loading unit, the method further includes: Build an environment simulation module; The environment simulation module simulates the Windows operating environment within a Linux system environment.
3. The Windows dynamic library calling method applicable to the Linux system of a hospital and hospital, as described in claim 2, is characterized in that, Loading target dynamic link library files for the Windows platform in a Linux system environment via a DLL loading unit specifically includes: Obtain the target dynamic link library file for the Windows platform; Read the PE format structure of the dynamic link library file to obtain the file layout, section information, import table and export table contents; Based on the section information, the Windows system is simulated through the environment simulation module, and independent memory space is allocated for dynamic link library files; Based on the import table, identify the dynamic link library files that have dependencies on the dynamic link library files; The environment simulation module matches the simulated implementations of dynamically linked library files with dependencies in the Linux system and queries the actual memory addresses of the corresponding dependent functions in the simulated implementation. Fill the actual memory address into the import address table corresponding to the import table.
4. The Windows dynamic library calling method applicable to the Linux system of a hospital and hospital, as described in claim 1, is characterized in that, After loading the target dynamic link library file for the Windows platform in a Linux system environment via the DLL loading unit, the method further includes: When loading the target dynamic link library file, digital signature verification is performed on the target dynamic link library file to check whether the file has been signed by a legitimate publisher; The target dynamic link library file is confirmed to have been tampered with by calculating its hash value and comparing it with a preset hash value.
5. The Windows dynamic library calling method applicable to the Linux system of a hospital and hospital, as described in claim 1, is characterized in that, The function resolution unit parses the exported function information in the target dynamic link library file and establishes a mapping relationship between function names and function entry addresses. Specifically, this includes: Read the export table of the target dynamic link library file; extract the name, ordinal number, and entry address of the exported functions from the export table, and establish a mapping relationship between function names and function entry addresses, storing it in the function mapping table.
6. The Windows dynamic library calling method applicable to the Linux system of a hospital and hospital, as described in claim 1, is characterized in that, Before converting Linux-compatible parameter data to Windows-compatible parameter data via the parameter conversion unit, the method further includes: Based on the differences in string types between Linux and Windows systems, a string type conversion program was created. Based on the difference in integer type length between Linux and Windows systems, an integer type length conversion program was created. Based on the differences in structure alignment methods between Linux and Windows systems, a structure alignment conversion program was created. Based on the differences in pointer address space mapping between Linux and Windows systems, a pointer address space mapping conversion program was created.
7. The Windows dynamic library calling method applicable to the Linux system of a hospital and hospital, as described in claim 1, is characterized in that, Before executing the function code segment pointed to by the entry address according to the function calling convention of the Windows platform, the method further includes: The input parameters of the input function code segment are subjected to a preset validity check, and input parameters that do not meet the preset validity are filtered out.
8. A Windows dynamic library calling system suitable for the Linux system of medical institutions, characterized in that, The system includes: The DLL loading unit is used to load target dynamic link library files for the Windows platform in a Linux system environment; The function resolution unit is used to parse the exported function information in the target dynamic link library file and establish a mapping relationship between function names and function entry addresses; The parameter conversion unit is used to convert Linux system-compatible parameter data into Windows system-compatible parameter data when a Linux application needs to call a function in the target dynamic link library. The execution unit is used to execute the function code segment pointed to by the function entry address based on the mapping relationship between function name and function entry address, and to use the converted parameter data. The execution result is then converted into data of Linux system compatible type by the parameter conversion unit and returned to the Linux application.
9. A Windows dynamic library calling device suitable for a medical-medical Linux system, characterized in that, The device includes: processor; And a memory having executable code stored thereon, which, when executed, causes the processor to perform a Windows dynamic library calling method for a medical Linux system as described in any one of claims 1-7.
10. A non-volatile computer storage medium, characterized in that, It stores computer instructions, which, when executed, implement a Windows dynamic library calling method applicable to the Yinyi Linux system as described in any one of claims 1-7.