CN113608791A

CN113608791A - Program operation control method, terminal device, and computer-readable storage medium

Info

Publication number: CN113608791A
Application number: CN202110824676.2A
Authority: CN
Inventors: 董时舫
Original assignee: PAX Computer Technology Shenzhen Co Ltd
Current assignee: PAX Computer Technology Shenzhen Co Ltd
Priority date: 2021-07-21
Filing date: 2021-07-21
Publication date: 2021-11-05

Abstract

The application is applicable to the technical field of computers, and provides a program operation control method, a terminal device and a computer-readable storage medium, which are applied to the terminal device, wherein the terminal device comprises an application program and a device driver, the device driver comprises a first program and a second program, the input of the second program is obtained by the output of the first program, and the method comprises the following steps: the application program sends a request to the first program through an application program interface, wherein the request carries a control code; if the first program is a function driver, the first program sends the request to the second program; and if the first program is a filter driver, the first program processes the request according to the control code. By the method, the flexibility and the adaptability of program operation control can be improved, and various application requirements of real-time operation control can be met.

Description

Program operation control method, terminal device, and computer-readable storage medium

Technical Field

The present application belongs to the field of computer technologies, and in particular, to a program operation control method, a terminal device, and a computer-readable storage medium.

Background

The device drivers in the Windows system include a function driver, a filter driver, and a bus driver, which are hierarchically coupled. The functions of the filter driver include intercepting filter requests, function expansion, data encryption and decryption and the like. By setting different configuration parameters, the filter driver can be controlled to realize different functions.

In the prior art, the configuration parameters are usually written into the registry, and the configuration parameters are read from the registry when the filter driver is started. In other words, the initial setting of the configuration parameters is performed when the device is started, and the configuration parameters cannot be changed in the subsequent operation; if the configuration parameters need to be changed, the device needs to be restarted. It can be seen that the existing operation control method of the filter driver has poor flexibility, and cannot meet the application requirements of various real-time operation controls.

Disclosure of Invention

The embodiment of the application provides a program operation control method, a terminal device and a computer readable storage medium, which can improve the flexibility and adaptability of program operation control.

In a first aspect, an embodiment of the present application provides a program operation control method, which is applied to a terminal device, where the terminal device includes an application program and a device driver, the device driver includes a first program and a second program, and an input of the second program is obtained from an output of the first program, and the method includes:

the application program sends a request to the first program through an application program interface, wherein the request carries a control code;

if the first program is a function driver, the first program sends the request to the second program;

and if the first program is a filter driver, the first program processes the request according to the control code.

In the embodiment of the application, the application program sends a request to a first program in the device driver through an application program interface; if the first program is a function driver, the first program does not process the request, but only sends the request to the second program; if the first program is a filter driver, the first program processes the request according to the control code. By the method, the application program can send the request carrying the control code to the device driver by using the application program interface provided by the operating system, and the operation of the filter driver is controlled in real time by the control code, so that the flexibility of program operation control is enhanced, and various application requirements of real-time operation control can be met.

In a possible implementation manner of the first aspect, if the first program is a function driver, the sending, by the first program, the request to the second program includes:

if the first program is a function driver, the first program judges whether the request is a first preset request;

if the request is a first preset request, the first program judges whether the control code is a preset code;

and if the control code is a preset code, the first program sends the request to the second program.

In a possible implementation manner of the first aspect, if the first program is a filter driver, the processing, by the first program, the request according to the control code includes:

if the first program is a filter driver, the first program judges whether the request is a first preset request;

and if the control code is a preset code, the first program processes the request.

In one possible implementation manner of the first aspect, the request includes a preset identifier and a function label;

if the control code is a preset code, the first program processes the request, including:

if the control code is a preset code, the first program detects whether the preset identifier is matched with an identifier of the first program;

and if the preset identifier is matched with the identifier of the first program, the first program processes the request according to the function label.

In a possible implementation manner of the first aspect, if the control code is a preset code, the processing, by the first program, of the request includes:

and if the preset identifier does not match with the identifier of the first program, the first program sends the request to a second program.

In a possible implementation manner of the first aspect, if the preset identifier matches an identifier of the first program, the processing, by the first program, the request according to the function label includes:

if the preset identifier is matched with the identifier of the first program, the first program acquires the control parameter corresponding to the function label;

the first program processes the request according to the control parameters.

In a possible implementation manner of the first aspect, after the application program sends the request to the first program through an application program interface, the method further includes:

if the first program is a function driver, the first program judges whether the request is a second preset request;

if the request is a second preset request, the first program processes the request;

and if the request is not a second preset request, the first program sends the request to the second program.

In a possible implementation manner of the first aspect, if the request is a second preset request, the processing, by the first program, of the request includes:

if the request is a second preset request, the first program judges whether the type of the request is a preset type;

and if the type of the request is a preset type, the first program processes the request in a mode corresponding to the preset type.

In a second aspect, an embodiment of the present application provides a terminal device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, where the processor implements the program operation control method according to any one of the above first aspects when executing the computer program.

In a third aspect, an embodiment of the present application provides a computer-readable storage medium, and the embodiment of the present application provides a computer-readable storage medium, where a computer program is stored, where the computer program, when executed by a processor, implements the program operation control method according to any one of the first aspect.

In a fourth aspect, an embodiment of the present application provides a computer program product, which, when running on a terminal device, causes the terminal device to execute the program running control method according to any one of the first aspect.

It is understood that the beneficial effects of the second to fourth aspects can be seen from the description of the first aspect, and are not described herein again.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or the prior art descriptions will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive exercise.

Fig. 1 is a schematic structural diagram of a device driver provided in an embodiment of the present application;

fig. 2 is a schematic flowchart of a program operation control method provided in an embodiment of the present application;

fig. 3 is a flowchart illustrating the overall operation of a program operation control method according to an embodiment of the present application;

FIG. 4 is a process flow diagram of a function driver provided in an embodiment of the present application;

FIG. 5 is a flowchart illustrating a process of a function driver according to another embodiment of the present application;

FIG. 6 is a process flow diagram of a filter driver provided in an embodiment of the present application;

fig. 7 is a schematic structural diagram of a terminal device according to an embodiment of the present application.

Detailed Description

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system structures, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

It will be understood that the terms "comprises" and/or "comprising," when used in this specification and the appended claims, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

As used in this specification and the appended claims, the term "if" may be interpreted contextually as "when.. or" upon "or" in response to a determination "or" in response to a detection ".

Furthermore, in the description of the present application and the appended claims, the terms "first," "second," "third," and the like are used for distinguishing between descriptions and not necessarily for describing or implying relative importance.

Reference throughout this specification to "one embodiment" or "some embodiments," or the like, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the present application. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," or the like, in various places throughout this specification are not necessarily all referring to the same embodiment, but rather "one or more but not all embodiments" unless specifically stated otherwise.

The program operation control method provided by the embodiment of the application can be applied to a Windows system, such as the control of the operation of a filter driver in a device driver. The following embodiments all describe the method by taking the control of the operation of the filter driver as an example.

In the Windows system, the operation of an Application program on a device is realized by a corresponding Application Programming Interface (API) function. Generally, in the Windows device driver framework, API functions for controlling devices are classified into five types: the device creates an API function (opens the device by creating the API function by the device), the device reads the API function (reads data from the device by reading the API function by the device), the device writes the API function (writes data to the device by writing the API function by the device), the device closes the API function (closes the device by closing the API function by the device), and the device controls the API function (controls or obtains the state, the operation mode, and the like of the device by controlling the API function by the device).

These API functions perform data transfer between an application and a device driver through an Input/Output Request Packet (IRP). The device driver includes three types, namely a function driver, a filter driver and a bus driver. Each device needs to be driven by one or several of these three drivers. When a plurality of drivers drive a device, the drivers adopt a layered structure, and are arranged from top to bottom in sequence to form a driver chain. For example: the device driver shown in fig. 1 is composed of a filter driver 11, a function driver 12, and a bus driver 13, where the upper driver in the hierarchical structure is the filter driver, the middle driver is the function driver, and the lower driver is the bus driver. Based on the hierarchical structure, the communication process is as follows: the application program sends the request to the filter driver program, the output of the filter driver program is the input of the function driver program, the output of the function driver program is the input of the bus driver program, and the output of the bus driver program is used for driving the equipment.

The API function is responsible for generating corresponding IRPs, issuing the IRPs to the uppermost driver of the driver chain through an I/O manager in the system, and then processing or transmitting the IRPs according to a layered structure by the drivers in each layer of the driver chain. When a certain layer of driver completes the IRP, the IRP is served and is not transferred to the lower layer any more, all drivers of the lower layer can not receive the IRP, and thus the IRP cannot be processed.

There may be multiple filter drivers in the driver chain, while there is typically only one function driver. The upper level of the function driver may have an upper level filter driver, and the lower level may have a lower level filter driver. The bus driver is typically located at the lowest level of the driver chain.

The filter driver can listen to all the IRPs passing through the driver layer where the filter driver is located, and is generally used for filtering certain specific IRPs, wherein the filtering processing comprises output acquisition, discarding, delaying, modification and the like. After the device driver is loaded, the filtering processing mode of the filtering driver is usually fixed, but in some application scenarios, the filtering processing mode needs to be changed in real time. The program operation control method provided by the embodiment of the application realizes real-time and accurate control of the filter driver by the application program through expanding and customizing the device control API function provided by the operating system in a proprietary manner and simultaneously adaptively revising the function driver and the filter driver.

Before controlling the operation of the filter driver, the function driver and the filter driver need to be adapted separately.

First, adaptive modification of a function driver is introduced, including the steps of:

s101, adding support for shared access in the function driver, so that two or more different applications or different processes can access the function driver at the same time.

As described above, the control of the device by the application is performed through the associated API functions provided by the operating system, which are passed through the IRP between the application and the device driver. Generally, in the Windows device driver framework, API functions for controlling devices are classified into five categories. Accordingly, IRPs are also classified into five categories: device create IRP, device write IRP, device read IRP, device close IRP and device control IRP. The IRP is characterized by a main function code, which in turn is: IRP _ MJ _ CREATE, IRP _ MJ _ WRITE, IRP _ MJ _ READ, IRP _ MJ _ CLOSE, IRP _ MJ _ DEVICE _ CONTROL.

The function in the device driver that handles the IRP is called a dispatch function.

In S101, the modification of the shared access support in the function driver mainly refers to the modification of the device creation dispatch function. The device creation dispatcher function is a dispatcher function in the device driver that processes the device creation IRP (i.e., IRP _ MJ _ CREATE), and the application generates and issues the device control IRP through the device creation API function.

Support for shared access is added to the device creation dispatch function so that two or more different applications or different processes may simultaneously open the device for device control operations. Support for shared access means that in the case of a device already open, the next open request to that device should not be denied, but the shared open is allowed, and the device creates a dispatch function to return a successful result.

Illustratively, assume that the device creates a dispatch function of VcomCreate (). The revision of the device creation dispatch function may be implemented by the following procedure:

NTSTATUS VcomCreate(PDEVICE_OBJECT pDevObj,PIRP pIrp)

{

NTSTATUS status＝STATUS_SUCCESS；

PDEVICE_EXTENSION pDx；

PIO_STACK_LOCATION pIrpStack；

……

pDx＝(PDEVICE_EXTENSION)pDevObj->DeviceExtension；

pIrpStack＝IoGetCurrentIrpStackLocation(pIrp)；

checking device on flag, and incoming shared on flag for device on

if(pDx->DeviceOpened&&

pIrpStack- > parameters create shareacess)// if the device is already open and reopened in a shared manner

{/- - -allow shared open request and return successful result

pIrp->IoStatus.Status＝STATUS_SUCCESS；

pIrp->IoStatus.Information＝0；

IoCompleteRequest(pIrp,IO_NO_INCREMENT)；

return STATUS_SUCCESS；

}

……

}

S102, revising the device control dispatch function in the function driving program and increasing the support to the control code.

The DEVICE CONTROL dispatch function is a dispatch function in the DEVICE driver that processes the DEVICE CONTROL IRP (i.e., IRP _ MJ _ DEVICE _ CONTROL), and the application generates and issues the DEVICE CONTROL IRP through the DEVICE CONTROL API function.

Generally, the function driver is the processing subject of the IRP, that is, the IRP initiated by the application program is already processed (including operations of confirming, executing, rejecting, discarding, etc.) in the function driver, and does not reach the filter driver of the next layer. In addition, the main function codes of the DEVICE CONTROL IRP are all IRP _ MJ _ DEVICE _ CONTROL, but the corresponding input/output CONTROL codes (abbreviated as CONTROL codes, and all referred to as "CONTROL codes" in the following embodiments) are different from each other, and different DEVICE CONTROL functions can be identified and distinguished by the CONTROL codes. And the equipment control dispatching function analyzes and processes different equipment control requests according to the control codes carried by the IRP. The device control functions that can be successfully executed and completed by the function driver are very limited, i.e., the number of control codes is limited. Therefore, in general, the function driver rejects the unsupported device control function and does not issue the function to the lower driver layer.

In the embodiment of the application, the control code is extended, the device control dispatch function in the function driver is revised, and the support of the extended control code is increased, so that the function driver does not intercept the IRP containing the control code but forwards the IRP to the lower driver, and the processing flow of the existing control code is maintained unchanged. By the revision mode, the compatibility of the system is kept, and a new function by which the application program can control the operation of the filter driver in real time is effectively expanded.

Exemplarily, the following is the definition of a part of control codes when performing device control on a serial device in a Windows system:

#define IOCTL_SERIAL_SET_BAUD_RATE 0x001B0004

#define IOCTL_SERIAL_SET_LINE_CONTROL 0x001B000C

#define IOCTL_SERIAL_SET_TIMEOUTS 0x001B001C

#define IOCTL_SERIAL_PURGE0x001B004C

#define IOCTL_SERIAL_GET_BAUD_RATE 0x001B0050

#define IOCTL_SERIAL_GET_LINE_CONTROL 0x001B0054

#define IOCTL_SERIAL_GET_COMMSTATUS0x001B006C

each device driver may define the control code according to the operating requirements of different devices. The control code is usually stored in a long and integral data, and the range of the control code is very large, and the operation requirement of the device is relatively limited. Therefore, a large number of unused values exist in the value field of the control code, and the unused values can be used as the control code for controlling the operation of the filter driver. For example, one of the unused values is taken out from the value field of the control code of the serial device as the macro definition of the control code for controlling the operation of the filter driver:

#define IOCTL_SERIAL_CONFIG_FILTER 0x001B2000

for example, assume that the device control dispatch function is VcomDeviceControl (). The revision of the device control dispatch function may be implemented by the following procedure:

NTSTATUS VcomDeviceControl(PDEVICE_OBJECT pDevObj,PIRP pIrp)

{

PDEVICE_EXTENSION pDx；

PIO_STACK_LOCATION pIrpStack；

NTSTATUS ntStatus；

ULONG IoCode；

……

pDx ═ PDEVICE _ EXTENSION) pdevieboj- > DeviceExtension; // fetch device extension Structure pointer

pIrpStack ═ iogetcurrentirpstack location (pirp); // current stack pointer of reading device

Extracting the current I/O control code from the device stack of the layer

IoCode＝pIrpStack->Parameters.DeviceIoControl.IoControlCode；

// begin parsing and processing input-output control codes

switch(IoCode)

{

case IOCTL_SERIAL_SET_BAUD_RATE:

……

break；

Novel analysis and processing flow

case IOCTL _ SERIAL _ CONFIG _ FILTER:// new and agreed control code for controlling the operation of the Filter driver

Ioskipcurrentirpstack location (pirp); // skip current stack

// issuing IRP to lower layer drive for processing and obtaining execution result

ntStatus＝IoCallDriver(pDx->pLowerDevice,pIrp)；

return ntStatus; // returning execution results

I/O control code analysis and processing flow

default:

V/reject handling, direct return and report parameter invalidation

pIrp->IoStatus.Information＝0；

pIrp->IoStatus.Status＝STATUS_INVALID_PARAMETER；

IoCompleteRequest(pIrp,IO_NO_INCREMENT)；

return STATUS_INVALID_PARAMETER；

}//switch(IoCode)

……

}

Adaptive modifications to the filter driver are described below, including: and revising a device control dispatch function in the filter driver, and increasing the algorithm for analyzing and processing the IRP containing the control code.

Analyzing the IRP containing the control code, and performing the analysis processing process of the step on the IRP only when the control code carried by the introduced IRP is the same as the control code in the step S102; if not, the IRP is forwarded to a lower layer driver, so that the lower layer filter driver can receive and process the IRP. The specific parsing and processing process can be referred to the description of the embodiment shown in fig. 6.

After the filter driver processes the IRP, the filter driver calls the IRP to complete the API function, so that the system I/O manager obtains the information that the IRP is completed, which is required by the Windows driver framework model.

The filter driving program processes the IRP and comprises the following steps: and acquiring a control data block from the IRP, and processing according to the control data block.

The control data block comprises fields such as a filter driving identifier, a function label and a control parameter. The arrangement order of the fields is not limited and can be defined by self. The control data block is an input parameter of the device control API function, namely: and the application program calls the parameter string input when the equipment controls the API function. The control data block characterizes the specific control content of the device control function. In the embodiment of the application, the format of the control data block is reasonably designed, so that interactive data between the driver and the application program can be conveniently filtered, and the function driver does not need to care about the specific format and content of the interactive data (direct transparent transmission is available), so that the coupling degree of the function driver is low, and the expansibility is excellent. The format of the control data block is designed as follows.

The filter driver identifier is a string with a set maximum width, for example: a string of maximum width 10 bytes. The filter driver identifier is used to uniquely identify a filter driver in the driver chain, and may be composed of any non-zero characters such as letters, numbers, symbols, etc., or may simply adopt the name of the filter driver. A plurality of filtering drivers may exist in the driver chain, and in the embodiment of the application, a filtering driver identifier is adopted to position a certain filtering driver, so that the scheme is applicable to a scene in which a plurality of filtering drivers exist in the driver chain, and further, the accurate control of a single filtering driver can be realized.

The function reference number is a number of a sub-function that specifically controls the filter driver. May be a non-negative integer starting from 0. The specific meaning of each label needs to be set according to the filter driver and the specific control requirement.

The control parameter is a parameter string corresponding to the function label, and is composed of one or more fields, or may be null, and its specific composition needs to be set according to the function label and its specific control requirement.

The above is the format design for the control data block. In actual practice, the filter driver may need to return data to the application after processing the IRP. For example: when the subfunction indicated by the function label in the control data block needs to obtain information from the filter driver, the corresponding information is taken out from the filter driver and written into the output data buffer area of the IRP, and the corresponding information is returned to the upper application program as a response parameter. Therefore, the format of the response parameter needs to be set. The format of the response parameter is determined by the sub-function indicated by the function label, and can be selected and set by itself, which is not described herein.

Illustratively, the following table shows the format and contents of the control data blocks and response parameters:

illustratively, revising the device control dispatch function in the filter driver may be accomplished by:

after the function driver and the filter driver are respectively adaptively modified according to the method, the program operation control method provided by the embodiment of the application controls the operation of the filter driver. Referring to fig. 2, which is a schematic flow chart of a program operation control method provided in the embodiment of the present application, by way of example and not limitation, the method may include the following steps:

s201, the application program sends a request to the first program through the application program interface, and the request carries the control code.

S202, if the first program is the function driver, the first program sends the request to the second program.

S203, if the first program is the filter driver, the first program processes the request according to the control code.

Fig. 3 is a general operation flowchart of the program operation control method provided in the embodiment of the present application. As shown in fig. 3, the application opens the device in a shared manner, and calls the device control API function after setting the correct control code, filter driver identifier, function label, control parameter, response parameter, and the like. And the system I/O manager issues a device control IRP (request) generated by the device control API function to a corresponding device driver, wherein the IRP carries a control code which is used for controlling the operation of the filter driver. If the uppermost program (first program) in the device driver is the function driver, the function driver issues the IRP to the next program (second program). And if the second program is a filter driver, the filter driver processes the IRP according to the control code. If the second program is not the filter driver, the second program continues to issue the IRP to the next layer program. And so on. If the first program of the device driver is a filter driver, the filter driver processes the IRP according to the control code.

The arrangement order of the parameters set in the application is not limited. For convenience of management and maintenance, the same arrangement as in S102, S201 is recommended. For example: the filter driver identifier is an identifier of the filter driver to be accessed, the function label should indicate one of the sub-function numbers appointed in step 201 according to actual needs, and the control parameter should set correct and valid actual data according to the function label. In addition, response parameters (output data buffer parameters, which are usually set only when response data needs to be output) should be set according to the function labels and needs. Because the response parameter is an output parameter for the equipment control API function, only a cache address for storing the response data needs to be filled; the size of the response parameter is an input parameter, and the size of a cache space for storing the response data is filled.

In one embodiment, refer to fig. 4, which is a schematic processing flow diagram of a function driver provided in an embodiment of the present application. As shown in fig. 4, S202 may further include:

if the first program is a function driver, the first program judges whether the request is a device control IRP (first preset request); if the request is equipment control IRP, the first program judges whether the control code is a preset code; if the control code is a preset code, the first program sends a request to the second program; if the request is not a device control IRP or the control code is not a preset code, the first program performs a routine process.

In the embodiment of the present application, the routine processing includes: if the control code is the existing control code and is not the extended control code (the control code for controlling the operation of the filter driver) described in the above embodiment of the present application, processing according to the processing flow corresponding to the control code; if the control code is unknown, the IRP is not processed and is discarded (not sent to the second program).

In one embodiment, as described in S101, support for shared access may also be added. Fig. 5 is a schematic processing flow diagram of a function driver according to another embodiment of the present application. As shown in fig. 5, S202 may further include:

if the first program is a function driver, the first program judges whether the request is to create an IRP (second preset request) for the equipment; if the request is that the equipment creates the IRP, the first program judges whether the type of the request is shared (preset type); if the type of the request is sharing, the first program processes the request in a sharing mode; if the request is not for the device to create an IRP, the first program sends the request to the second program in accordance with the steps shown in fig. 4.

By sharing access, different applications can open the same device in a shared manner. Therefore, different applications can access the same device in parallel and cooperatively operate the device driver corresponding to the device to complete the same communication task.

By way of example, the following is an example of controlling a filter driver in an application:

in one embodiment, refer to fig. 6, which is a schematic processing flow diagram of the filter driver provided in the embodiment of the present application. As shown in fig. 6, S203 may include:

if the first program is a filter driver, the first program judges whether the request is a device control IRP (first preset request); if the request is equipment control IRP, the first program judges whether the control code is a preset code; if the control code is a preset code, the first program processes the request; if the control code is not the preset code, the request is sent to a lower layer driving program (a second program); if the request is not a device control IRP, the first routine processes routinely.

The routine processing here is the same as the routine processing described in the embodiment of fig. 4, and specific reference may be made to the description in the embodiment of fig. 4, which is not described herein again.

Optionally, if the control code is a preset code, the filter driver processing request includes:

if the control code is a preset code, the first program detects whether the preset identifier matches with an identifier of the filter driver (identifier of the first program); if the preset identifier is matched with the identifier of the filter driver (the identifier of the first program), the first program processes the request according to the function label; if the predetermined identifier does not match the identifier of the first program, the first program sends a request to the second program.

Optionally, if the preset identifier matches an identifier of the filter driver (identifier of the first program), the processing, by the first program, of the request according to the function label includes:

if the preset identifier is matched with the identifier of the first program, the first program acquires the control parameter corresponding to the function label; the first program processes the request according to the control parameter.

The first program may search for the control parameter corresponding to the function label according to the table of the format and content of the control data block and the response parameter described in S102.

In the embodiment of the application, by introducing the filter driver identifier parameter, the application program can accurately control and access a plurality of different filter driver programs. By introducing the function labels, the application program can accurately control and access a plurality of different control items of the same filter driver.

The program operation control method provided by the embodiment of the application can be applied to application scenarios such as reliability test of a function driver through a filter driver. Such as a video data acquisition function driver, a data transmission function driver based on a USB bus, and the like. By the method provided by the embodiment of the application, the operation of the filter driver in the application program is controlled in real time and accurately, the test efficiency can be effectively improved, extreme test conditions and fault scenes can be accurately constructed, and the test coverage rate is improved.

It should be understood that, the sequence numbers of the steps in the foregoing embodiments do not imply an execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

Fig. 7 is a schematic structural diagram of a terminal device according to an embodiment of the present application. As shown in fig. 7, the terminal device 7 of this embodiment includes: at least one processor 70 (only one shown in fig. 7), a memory 71, and a computer program 72 stored in the memory 71 and executable on the at least one processor 70, wherein the processor 70 implements the steps of any of the various program execution control method embodiments described above when executing the computer program 72.

The terminal device can be a desktop computer, a notebook, a palm computer, a cloud server and other computing devices. The terminal device may include, but is not limited to, a processor, a memory. Those skilled in the art will appreciate that fig. 7 is only an example of the terminal device 7, and does not constitute a limitation to the terminal device 7, and may include more or less components than those shown, or combine some components, or different components, for example, and may further include input/output devices, network access devices, and the like.

The Processor 70 may be a Central Processing Unit (CPU), and the Processor 70 may be other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic, discrete hardware components, etc. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The memory 71 may in some embodiments be an internal storage unit of the terminal device 7, such as a hard disk or a memory of the terminal device 7. In other embodiments, the memory 71 may also be an external storage device of the terminal device 7, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), and the like, which are provided on the terminal device 7. Further, the memory 71 may also include both an internal storage unit and an external storage device of the terminal device 7. The memory 71 is used for storing an operating system, an application program, a Boot Loader (Boot Loader), data, and other programs, such as program codes of the computer programs. The memory 71 may also be used to temporarily store data that has been output or is to be output.

The embodiments of the present application further provide a computer-readable storage medium, where a computer program is stored, and when the computer program is executed by a processor, the computer program implements the steps in the above-mentioned method embodiments.

The embodiments of the present application provide a computer program product, which when running on a terminal device, enables the terminal device to implement the steps in the above method embodiments when executed.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, all or part of the processes in the methods of the embodiments described above can be implemented by a computer program, which can be stored in a computer-readable storage medium and can implement the steps of the embodiments of the methods described above when the computer program is executed by a processor. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer readable medium may include at least: any entity or device capable of carrying computer program code to an apparatus/terminal device, recording medium, computer Memory, Read-Only Memory (ROM), Random-Access Memory (RAM), electrical carrier wave signals, telecommunications signals, and software distribution medium. Such as a usb-disk, a removable hard disk, a magnetic or optical disk, etc. In certain jurisdictions, computer-readable media may not be an electrical carrier signal or a telecommunications signal in accordance with legislative and patent practice.

In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and reference may be made to the related descriptions of other embodiments for parts that are not described or illustrated in a certain embodiment.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus/terminal device and method may be implemented in other ways. For example, the above-described embodiments of the apparatus/terminal device are merely illustrative, and for example, the division of the modules or units is only one logical division, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

The above-mentioned embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not substantially depart from the spirit and scope of the embodiments of the present application and are intended to be included within the scope of the present application.

Claims

1. A program operation control method applied to a terminal device including an application program and a device driver including a first program and a second program, an input of the second program being obtained by an output of the first program, the method comprising:

2. The program operation control method according to claim 1, wherein the sending, by the first program, the request to the second program if the first program is a function driver includes:

3. The program operation control method according to claim 1, wherein if the first program is a filter driver, the first program processes the request according to the control code, including:

4. The program operation control method according to claim 3, wherein the request includes a preset identifier and a function label;

5. The program operation control method according to claim 4, wherein the processing, by the first program, of the request if the control code is a preset code includes:

6. The program operation control method according to claim 4, wherein the processing, by the first program, of the request according to the function label if the preset identifier matches the identifier of the first program includes:

the first program processes the request according to the control parameters.

7. The program operation control method according to claim 1, wherein after the application program sends a request to the first program through an application program interface, the method further comprises:

8. The program operation control method according to claim 7, wherein the processing, by the first program, of the request if the request is a second predetermined request includes:

9. A terminal device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that the processor implements the method according to any of claims 1 to 8 when executing the computer program.

10. A computer-readable storage medium, in which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1 to 8.