Disclosure of Invention
In order to overcome the defects of the prior art, the application provides a file processing method, a file processing device and a storage medium, so that the problem that one library file cannot be commonly used due to different delphi versions among different users is solved, and further the workload and the use limit of upstream and downstream users are reduced.
In a first aspect, an embodiment of the present invention provides a file processing method, which is applied to a second device, where delphi is installed on the second device, including:
acquiring a binary data file, wherein the binary data file is obtained by converting a dynamic library file, and the dynamic library file is used for providing a first function which can be called;
introducing the binary data file into a first code file, wherein the first code file comprises source codes of a first delphi program or a first dcu library file written based on the delphi, and the first code file is used for calling at least one second function, and the second function is contained in the first function;
modifying the function entry address of the at least one second function in the first code file into the address of data corresponding to the at least one second function in the binary data file respectively to obtain a second code file;
and compiling the second code file based on the delphi to obtain a second delphi program or a second dcu library file.
Optionally, the method further comprises:
acquiring a third file, wherein the third file is used for indicating the mapping relation between the function name and the function sequence number of the first function provided by the dynamic library file;
determining a function sequence number corresponding to each function name of the at least one second function based on the mapping relation;
and determining the address of the data corresponding to each of the at least one second function in the binary data file based on the function sequence number of each of the at least one second function.
Optionally, the third function is any one of the at least one second function;
determining, based on the function sequence numbers of the at least one second function, addresses of data corresponding to the at least one second function in the binary data file, including:
determining a first position of the binary data file in a first code file after the binary data file is introduced;
determining a second position of data corresponding to the third function in the binary data file based on the function sequence number of the third function;
and determining the address of the data corresponding to the third function based on the first position and the second position.
Optionally, the binary data file is obtained by converting a dynamic library file by a first device by using a conversion program, the third file is generated by the first device, and the first device is a device used by a developer of the dynamic library file.
Optionally, delphi does not need to be installed on the first device, and the delphi installed on the second device is a delphi of any version.
Optionally, the second delphi program or the second dcu library file can be independently delivered to the third device, and the second delphi program can run on the third device; or,
the second delphi program or the second dcu library file can be used on the third device to develop a third delphi program or a third dcu library file based on delphi.
Optionally, the dynamic library file is suitable for a Windows operating system.
In a second aspect, an embodiment of the present invention further provides a file processing apparatus, which is applied to a second device, where delphi is installed on the second device, including:
an acquisition module configured to acquire a binary data file, the binary data file being converted from a dynamic library file, the dynamic library file being used to provide a first function that can be invoked;
an import module configured to import the binary data file into a first code file, the first code file including source code of a first delphi program or a first dcu library file written based on the delphi, the first code file being used to call at least one second function, the second function being included in the first function;
the compiling module is configured to modify the function entry address of the at least one second function in the first code file into the address of the data corresponding to the at least one second function in the binary data file respectively to obtain a second code file; compiling the second code file based on the delphi;
and the output module is configured to output the compiled second delphi program or the second dcu library file.
In a third aspect, an embodiment of the present invention further provides an electronic device, where the electronic device includes a processor and a memory, and delphi is further installed; the memory has stored thereon predetermined computer instructions for execution by the processor to perform part or all of the steps of any of the methods of the first aspect.
In a fourth aspect, embodiments of the present invention also provide a computer-readable storage medium having stored thereon computer-executable instructions which, when executed by a processor, implement some or all of the steps of any of the methods of the first aspect.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present invention more clear, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention.
Some concepts presented in the embodiments of the present invention will be briefly described below.
delphi: a visual development tool can be used in the environments of Windows3.X, windows95, windowsNT, windowsXP, windowsVista, windows7, windows8, windows8.1, windows10, linux, OS X, iOS, android and the like, adopts an object-oriented programming language ObjectPascal and a component-based development structure framework, and provides various development tools including an integrated environment, a compiler, an Image editor (Image editor) and various application programs for developing databases, such as DesktopDataBase Expert and the like.
delphi program: using Delphi written code, the code can be compiled by a compiler in Delphi to get an executable program. That is, an executable program developed using delphi is referred to as a delphi program in this application.
dcu library file: library files developed using delphi with delphi version information. For example, the file suffix of the dcu library file may be.
Referring to fig. 1, fig. 1 is a schematic architecture diagram of an exemplary application scenario for developing dcu library files based on delphi. Among them, the device 1 is an electronic device used by a library file developer, the device 2 is an electronic device used by a downstream user, and the device 3 is an electronic device used by a downstream user (also referred to as a further downstream user).
Devices 1, 2, 3 may include, but are not limited to, electronic devices such as cell phones, tablet computers, personal computers (Personal Computer, PCs), wearable devices, augmented Reality (AR)/Virtual Reality (VR) devices, personal digital assistants (Personal Digital Assistant, PDA), etc., and the specific product form/type of the electronic devices is not limited herein.
Delphi is installed in each of the devices 1 and 2. A library file developer may compile a segment of written library code into a dcu library file (referred to as dcu library file 1 in this example for ease of distinction) with version information of the delphi through a compiler in delphi in the device it uses (e.g., device 1). dcu library file 1 may be delivered to downstream users. The downstream user may continue to develop or use dcu library file 1 on the device that he uses (e.g., device 2) based on delphi on device 2 to develop a delphi program (referred to as program 1 in this example for ease of distinction) or other dcu library files (referred to as dcu library file 2in this example for ease of distinction).
The delphi installed on the device 1 needs to be consistent with the version of delphi installed on the device 2 used by the downstream user. When version information in dcu library file 1 delivered to a downstream user by a library file developer is inconsistent with the delphi version used by the downstream user, a compiler of delphi in device 2 cannot compile program code or library code written by the downstream user into a program (i.e. program 1) or a dcu library file (i.e. dcu library file 2) based on the dcu library file 1, and errors may occur. At this time, the downstream user often needs to feed back the error report to the library file developer, and the library file developer compiles the source code again by using delphi with the version matching, and provides the dcu library file with the version matching again, so that the downstream user can use normally. Since library files developed by a library file developer may be provided to a plurality of different downstream users, when versions of delphi used by the downstream users are different, the library file developer needs to install a plurality of different versions of delphi in a device (e.g., device 1) used by itself, and a plurality of dcu library files with different version information are compiled respectively so as to be provided to the different downstream users.
After developing the program 1 or the dcu library file 2, the downstream user may deliver it to the further downstream user together with the dcu library file 1. The downstream user may then run the program 1 directly on the device it uses (e.g., device 3), or, based on delphi on device 3, continue developing or using the program 1 or dcu library file 2 to develop a new delphi program (referred to as program 2in this example for ease of distinction) or other dcu library file (referred to as dcu library file 3 in this example for ease of distinction). It will be appreciated that the downstream user may also deliver the product developed by the downstream user to the downstream user for use or further development, and the process is similar to the previous process and will not be repeated here.
It can be seen that this approach results in additional effort and more cumbersome use restrictions.
The invention provides a file processing method, a file processing device and a storage medium. The library file developer converts the dynamic library file into a binary data file and delivers the binary data file to the downstream user, so that the downstream user can avoid directly using the dcu library file, and the problem that delphi versions among different users cannot be used for the same dcu library file is avoided. By adopting the scheme, a library file developer can not need to provide dcu library files with different versions for different users, and even does not need to install delphi; the downstream user may normally invoke the library file provided by the library file developer based on delphi of any possible version. In addition, the downstream user does not need to deliver the dcu library file developed by the library file developer together when delivering the product to the downstream user. That is, with this scheme, the workload of the upstream and downstream and the use restriction can be reduced.
Referring to fig. 2, fig. 2 is an architecture diagram of an exemplary application scenario of the method provided in the embodiment of the present application.
The first device is an electronic device used by a library file developer. The delphi can be installed on the first device or not, and whether the delphi is installed or not does not affect the implementation of the scheme. The library file developer may use the electronic device to develop the dynamic library file, in which case the first device may have installed thereon the necessary development tools for developing the dynamic library file. Of course, library file developers may also use other possible electronic devices to develop dynamic library files.
The second device is an electronic device used by the downstream user. The delphi is installed on the second device, but the version of the delphi is not strictly required, and a downstream user can select a version capable of meeting the requirement according to the actual requirement. That is, the delphi installed on the second device may be any possible version of delphi.
The third device is an electronic device for use by a further downstream user. It will be appreciated that when the downstream user is simply running a product (e.g., delphi program) delivered by the downstream user, there may be no requirement as to whether delphi is installed on the device. Delphi may also need to be installed on the third device when the further downstream user needs to continue developing based on the product (e.g., delphi program or dcu library file) delivered by the downstream user.
The first device, the second device, and the third device may include, but are not limited to, electronic devices such as a cell phone, a tablet computer, a personal computer (Personal Computer, PC), a wearable device, an augmented reality (augmented reality, AR)/Virtual Reality (VR) device, a personal digital assistant (Personal Digital Assistant, PDA), and the like, and the specific product forms/types of the electronic devices are not limited herein.
It should be understood that fig. 2 is merely an exemplary architecture, and in some cases, other necessary devices may be included in the architecture, which is not limited in this application.
The method according to the embodiment of the present invention will be explained in detail with reference to fig. 3 to 4.
In a first aspect of the present invention, as shown in fig. 3, a file processing method is provided, which may be applied to the aforementioned second device. The method may comprise steps S10-S40.
Step S10, obtaining a binary data file, wherein the binary data file is obtained by converting a dynamic library file, and the dynamic library file is used for providing a first function which can be called.
Dynamic library files may generally contain functions and/or resources, etc. that allow program operations. Illustratively, the dynamic library file under the Windows system contains many functions and resources that allow the Windows-based program to operate in a Windows environment. In Windows, the dynamic library file is in most cases a file with a. Dll. Extension; in Linux systems, dynamic library files are most often files with a.so extension.
The dynamic library file in the embodiment of the present application is a file developed by a library file developer. In some exemplary embodiments, one or more functions are included in the dynamic library file, and different functions may be used to implement the same or different functions. These functions may be preset by the library file developer. For convenience of distinction and description, in this embodiment of the present application, a function provided in a dynamic library file and capable of being called is referred to as a first function, and hereinafter, the file processing method provided in this application will be described by taking the dynamic library file as an example.
In some exemplary embodiments, a development tool suitable for a Windows operating system is installed on the first device, through which a dynamic library file may be developed. The development tool may be a prior art tool for developing dynamic libraries, such as visual studio, etc.
Binary data files generally refer to files containing data or program instructions written in ASCII and extended ASCII characters.
In embodiments of the present application, a library file developer may convert a dynamic library file to a corresponding binary data file on a first device. The binary data file is capable of performing a function consistent with the corresponding dynamic library file.
Illustratively, the dynamic library file generated by the library file developer through the development tool under the Windows system may be a dynamic library file with dll as a suffix, and the dynamic library file is converted into a binary data file through a conversion program such as dll2 Inc.
The binary data file may be delivered to downstream users by the library file developer in any possible manner. In some implementations, the library file developer may use an electronic device (e.g., the first device described above) to communicate the binary data file over a network to a second device used by a downstream user to complete the delivery. In other implementations, the library file developer may also effect delivery by other possible means, such as a copy of the storage medium. When the downstream user needs to use the binary data file on the second device, the binary data file is retrieved from the storage medium.
In some implementations, the library file developer may further generate a third file on the first device, where the third file is used to indicate a mapping relationship between a function name and a function sequence number of the first function provided by the dynamic library file. At the time of delivery, the library file developer may deliver the third file to the downstream user, either together with the binary data file or separately, for use by the downstream user.
Step S20, introducing the binary data file into a first code file, where the first code file includes a source code of a first delphi program or a first dcu library file written based on the delphi, and the first code file is used to call at least one second function, where the second function is included in the first function.
The downstream user may write code based on delphi installed on the second device or possibly other devices, develop a delphi program or dcu library file. These delphi programs or dcu library files may require invocation of library files provided by a library file developer. The downstream user may invoke one or more functions in the library file according to different requirements.
For convenience of distinguishing and description, hereinafter, a delphi program which needs to call the dynamic library file is referred to as a first delphi program, and a dcu library file which needs to call the dynamic library file is referred to as a first dcu library file; the function in the dynamic library file called by the first delphi program or the first dcu library file is called a second function. It will be appreciated that the second function must be the function of the first function contained in the dynamic library file, i.e. the second function is contained in the first function.
In some exemplary embodiments, the first code file contains source code of a first delphi program or a first dcu library file developed by a downstream user using delphi. It will be appreciated that the first code file includes code segments for invoking at least one second function such that the first code file can be used to invoke at least one second function.
In some exemplary embodiments, the binary data file may be introduced in the first code file by adding a piece of functional code. For example, the first code file may be a source code of a program a developed by a downstream user using delphi, and an Include () code or { $i binary. It should be appreciated that other possible implementations may also be employed by the second device to introduce the binary data file into the first code file.
Step S30, modifying the function entry addresses of the at least one second function in the first code file to the addresses of the data corresponding to the at least one second function in the binary data file, respectively, to obtain a second code file.
As previously mentioned, the first code file includes code segments for invoking at least one second function, wherein the function entry addresses of these second functions are referred to. The function address entries for these second functions may be written based on the manner in which the dynamic library file is called. After the dynamic library file is converted into a binary data file and introduced into the first code file, the function address entries of these second functions need to be modified accordingly to obtain the second code file. Thus, the corresponding second function can be smoothly invoked when the product obtained based on the compiling of the second code file is executed subsequently.
In some exemplary embodiments, the mapping relationship between the function serial number and the function name is preset in the dynamic library file generated by the library file developer, and the mapping relationship is still reserved when the dynamic library file is converted into the binary data file. The mapping relation enables the second device to determine the address of the data corresponding to the second function in the binary data file according to the mapping relation, and further the function entry address of the second function can be modified into the address of the corresponding data.
In exemplary embodiments, referring to fig. 4, the method performed by the second device may further include the following steps S50 to S70 to determine an address of data corresponding to the second function in the binary data file.
And S50, acquiring a third file, wherein the third file is used for indicating the mapping relation between the function name and the function sequence number of the first function provided by the dynamic library file.
In some exemplary embodiments, since the mapping relationship between the reserved function sequence number and the function name may not be directly read by delphi on the second device, or the second device may not determine which data block corresponds to which first function only according to the binary data file, a file for indicating the mapping relationship may be additionally attached and delivered together with the binary data file.
Step S60, determining the function serial numbers corresponding to the function names of the at least one second function based on the mapping relation.
Step S70, determining the address of the data corresponding to each of the at least one second function in the binary data file based on the function serial number of each of the at least one second function.
In some exemplary embodiments, the second device may determine a function name of the second function involved in the first code file based on the first code file. After the second device obtains the binary data file and the third file, function serial numbers corresponding to the function names of the second functions can be respectively determined based on the third file; and then, determining the data blocks corresponding to the second functions from the binary data file based on the function serial numbers respectively, and further determining the addresses of the data corresponding to the second functions.
In some exemplary embodiments, the third file may be a pas file, which is generated by the library file developer and delivered to the downstream user, and the file has a Memory dll Loading Code schema, by which a function name can be obtained, by which a corresponding function number can be determined, and by which an address of a function corresponding to a function number can be determined in the binary data file.
In some exemplary embodiments, for ease of distinction and description, the set of functions called by the downstream user (i.e., any one of the set of second functions, referred to as the third functions), may be the same or different for each third function, where it is necessary to determine the address of the binary data corresponding to the third function, and then modify the entry address of the function in the first code file to the address of the binary data corresponding to the function.
In one exemplary implementation, the method may include the steps of:
s701, determining a first position of a binary data file in a first code file after the binary data file is introduced;
s702, determining a second position of data corresponding to a certain third function in a binary data file based on a function sequence number of the third function;
s703, determining the address of the data corresponding to the third function based on the first position and the second position.
In an exemplary embodiment, after the first code file is taken as the program a code, the downstream user can determine the position of the binary data file in the whole program a code first, then determine the position of the binary data corresponding to the third function in the binary data file based on the mapping relationship between the function serial number and the function name of the third function, and finally obtain the address of the binary data corresponding to the third function in the whole program a code according to the two positions that can be determined.
It should be understood that the sequence between steps S50 to S70 and other steps is not limited in the embodiment of the present application, as long as it is not logically contradictory. Illustratively, the step S50 may be performed before or after the step S10, or may be performed simultaneously with the step S10. Also illustratively, steps S60 and S70 are necessarily performed after step S10, and are necessarily performed prior to step S40. Also illustratively, step S701 is performed after step S20, either before or after step S50, S60, or concurrently therewith.
And S40, compiling the second code file based on the delphi to obtain a second delphi program or a second dcu library file.
The implementation manner of compiling based on delphi may be a compiling manner possible in the prior art, which is not limited in this application. Whether the delphi program or the dcu library file is compiled can be realized by a downstream user according to actual service requirements when the first code file is written and/or compiled.
In some exemplary embodiments, after obtaining the second delphi program or the second dcu library file with the downstream user developed functions or the like, the downstream user may also independently deliver the second delphi program or the second dcu library file to the further downstream user without delivering the dynamic library file, the binary data file, or the third file together to the further downstream user.
The downstream user may then run the second delphi program on the third device that it uses, or, based on the second delphi program or the second dcu library file, continue developing other programs or library files, such as a third delphi program or a third dcu file. When the second delphi program or the second dcu library file is executed or called, an electronic device such as a computer can directly load the binary data file into the memory of the second delphi program or the program calling the second dcu library file for execution, without releasing the binary data file or the dynamic library file to the local computer.
It will be appreciated that when a further downstream user needs to continue development, the third device in which it is used needs to install the necessary development tools. Especially when the downstream user needs to call the second dcu library file, delphi needs to be installed in the third device used by the downstream user, and the version of delphi installed in the third device needs to be consistent with the version of delphi in the second device.
It will be further appreciated that the program that the downstream user continues to develop may be a delphi program, or may be another type of program, and the library file that the user continues to develop may be a dcu library file, or may be another type of library file.
In a second aspect of the present invention, as shown in fig. 5, there is provided a file processing apparatus applied to a second device on which delphi is mounted, the file processing apparatus comprising:
an acquisition module configured to acquire a binary data file, the binary data file being converted from a dynamic library file, the dynamic library file being used to provide a first function that can be invoked;
an import module configured to import the binary data file into a first code file, the first code file including source code of a first delphi program or a first dcu library file written based on the delphi, the first code file being used to call at least one second function, the second function being included in the first function;
the compiling module is configured to modify the function entry address of the at least one second function in the first code file into the address of the data corresponding to the at least one second function in the binary data file respectively to obtain a second code file; compiling the second code file based on the delphi;
and the output module is configured to output the compiled second delphi program or the second dcu library file.
Optionally, the obtaining module may be further configured to: acquiring a third file, wherein the third file is used for indicating the mapping relation between the function name and the function sequence number of the first function provided by the dynamic library file;
the processing device further includes: and a determining module. The determination module may be configured to: determining a function sequence number corresponding to each function name of the at least one second function based on the mapping relation; and determining the address of the data corresponding to each of the at least one second function in the binary data file based on the function sequence number of each of the at least one second function.
Optionally, the determining module may be further configured to: determining a first position of the binary data file in a first code file after the binary data file is introduced; determining a second position of data corresponding to the third function in the binary data file based on the function sequence number of the third function; and determining the address of the data corresponding to the third function based on the first position and the second position. Wherein the third function is any one of the at least one second function.
The parts of the processing apparatus having the same characteristics as those of the foregoing processing method may be referred to the relevant description in the foregoing method embodiment, and will not be repeated here.
In a third aspect of the invention, an electronic device is provided that includes a processor and a memory. The delphi is installed on the electronic equipment. The memory has stored thereon predetermined computer instructions for execution by the processor to perform some or all of the steps of any of the methods of the previous method embodiments.
In a fourth aspect of the invention, there is provided a computer readable storage medium having stored thereon computer executable instructions which, when executed by a processor, implement some or all of the steps of any of the file processing methods described above.
In some embodiments, the executing computer-executable instructions processor can be a processing device including more than one general purpose processing device, such as a microprocessor, central Processing Unit (CPU), graphics Processing Unit (GPU), or the like. More specifically, the processor may be a Complex Instruction Set Computing (CISC) microprocessor, a Reduced Instruction Set Computing (RISC) microprocessor, a Very Long Instruction Word (VLIW) microprocessor, a processor running other instruction sets, or a processor running a combination of instruction sets. The processor may also be one or more special purpose processing devices such as an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), a Digital Signal Processor (DSP), a system on a chip (SoC), or the like.
In some embodiments, the computer readable storage medium may be memory, such as read-only memory (ROM), random-access memory (RAM), phase-change random-access memory (PRAM), static random-access memory (SRAM), dynamic random-access memory (DRAM), electrically erasable programmable read-only memory (EEPROM), other types of random-access memory (RAM), flash memory disk or other forms of flash memory, cache, registers, static memory, compact disk read-only memory (CD-ROM), digital Versatile Disk (DVD) or other optical storage, magnetic cassettes or other magnetic storage devices, or any other possible non-transitory medium which can be used to store information or instructions that can be accessed by a computer device, and the like.
In some embodiments, computer-executable instructions may be implemented as a plurality of program modules which collectively implement a file processing method according to any of the present disclosure.
The present disclosure describes various operations or functions that may be implemented or defined as software code or instructions.
Such content may be source code or differential code ("delta" or "patch" code) that may be executed directly ("object" or "executable" form). The software implementations of the embodiments described herein may be provided by an article of manufacture having code or instructions stored thereon or by a method of operating a communication interface to transmit data over the communication interface. The machine or computer-readable storage medium may cause a machine to perform the described functions or operations and includes any mechanism for storing information in a form accessible by the machine (e.g., computing display device, electronic system, etc.), such as recordable/non-recordable media (e.g., read Only Memory (ROM), random Access Memory (RAM), magnetic disk storage media, optical storage media, flash memory display device, etc.). The communication interface includes any mechanism for interfacing with any of a hard-wired, wireless, optical, etc. media to communicate with other display devices, such as a memory bus interface, a processor bus interface, an internet connection, a disk controller, etc. The communication interface may be configured by providing configuration parameters and/or sending signals to prepare the communication interface to provide data signals describing the software content. The communication interface may be accessed by sending one or more commands or signals to the communication interface.
The computer-executable instructions of embodiments of the present disclosure may be organized into one or more computer-executable components or modules. Aspects of the disclosure may be implemented with any number and combination of such components or modules. For example, aspects of the present disclosure are not limited to the specific computer-executable instructions or the specific components or modules illustrated in the figures and described herein. Other embodiments may include different computer-executable instructions or components having more or less functionality than illustrated and described herein.
It is to be understood that unless otherwise defined, technical or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terms "first," "second," and the like, as used herein, do not denote any order, quantity, or importance, but rather are used to distinguish one element from another. The word "comprising" or "comprises", and the like, is intended to mean that elements or items preceding the word are included in the listed elements or items following the word, and equivalents thereof, without excluding other elements or items. The terms "connected" or "connected," and the like, are not limited to physical or mechanical connections, but may also include electrical connections, whether direct or indirect.
It is to be understood that the above embodiments are merely exemplary embodiments of the present disclosure and are not intended to limit the present disclosure, the scope of which is defined by the claims. Various modifications and equivalents of the disclosure herein disclosed may occur to persons skilled in the art and are intended to be included within the spirit and scope of the disclosure.