Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Schongar P.VBScript unleashed.1997

.pdf
Скачиваний:
43
Добавлен:
23.08.2013
Размер:
1.59 Mб
Скачать

procedure takes this responsibility. Thus, the PASCAL function calls eliminate any duplication of code because multiple instances could exist of one procedure calling a single instance of another procedure.

The EXPORT keyword tells the compiler what functions in the DLL should be made visible and accessible to the world outside the DLL.

Exported Functions

Exported functions define the programming interface of a DLL and are meant to be called by applications and other DLLs. They usually represent the highest abstraction level a DLL provides to its callers. To implement these high-level services, exported functions often call non-exported functions that perform the necessary operations to support their functionality.

Exported functions must be declared as far because they do not reside in the segments from which they are called. They may, however, use any naming and parameter-passing conventions that pass parameters on the stack. Two popular conventions are pascal and cdecl. Conventions that pass parameters in the CPU's registers may not be used because prolog code uses the CPU's registers when the function is called. Also note that exported functions that return floatingpoint values or structures and objects larger than 4 bytes must use the pascal calling convention.

Non-Exported (Internal) Functions

Internal functions can only be called by other functions within the same DLL; applications and other DLLs cannot call them and do not need to be aware that they even exist. Because they are internal to a DLL, you can use only nonexported functions to implement the functionality of the DLL's initialization, termination, and exported functions. Nonexported functions should be used in DLLs just as they are in applications-to build a modular structure and to break down the complexity. Internal functions in DLLs can use any naming and parameter-passing conventions supported by your compiler.

Why Use DLLs?

DLLs represent important technology that has gained widespread use and acceptance since its inception. Many advantages to using DLLs exist. DLLs provide better memory management. A dynamic link library gets loaded only at runtime, and only one copy of the library needs to be loaded into the memory space. If more than one application needs it, the library is shared across applications. An application can even unload the DLL if it is not needed at any given time, which frees up memory. Consequently, you make efficient use of your system memory.

A wave of third-party libraries has hit the marketplace. Utilizing these existing DLLs directly with your application saves you a great deal of time and effort. It enables you to focus on the core of your application because the DLLs take care of some of the intricacies of your application.

A DLL is usually written using C or C++. Programs written in C or C++ operate quickly and efficiently, which improves the speed and response time of your application tremendously.

Consider this example. Your application involves complex mathematical calculations, and you are using a front-end GUI tool, such as Visual Basic or PowerBuilder, to build the user interface for your application. You can implement the mathematical calculations in two ways. You can write them as functions directly in Visual Basic or PowerBuilder, not the most efficient way to do it. On the other hand, you can write them as C or C++ functions embedded within a DLL, which is fast and efficient. Moreover, a DLL comprised of such functions can be used across different applications. You write it once and you use it multiple times, which encourages code sharing and reusability. Implementing the mathematical calculations this way makes the structure of your application modular. Furthermore, you can modify the functions within the DLL (without changing the name references) and do not have to worry about re-creating the executable. All you have to do is update your user's system with the latest version of the DLL.

A large pool of third-party developers exists for Visual Basic, the development environment for Windows. These developers have created a large number of third-party controls and libraries for Visual Basic. Most of these controls and libraries are nothing but DLLs. The developers have created DLLs that not only handle complex mathematical and geometrical calculations, but also provide enhanced user interface controls. Visual Basic 3.0's release included a basic set of user interface controls that left a big void to be later filled by the third-party developers. Examples of such controls include dropdown calendar, spin control, progress bar, etc. These controls can be programmed and created as part of a DLL, thus making them reusable across different applications. If you are using a third-party DLL, make sure you have all the necessary documentation on the DLL. Without proper documentation, you would have a hard time figuring out what functions are included within the DLL and what types of arguments those functions take.

NOTE

Even with the advent of OCX and ActiveX technologies, DLLs will exist for quite some time. The large established base of DLL-based applications cannot disappear so easily and quickly.

Disadvantages of Using DLLs

Although DLLs offer significant advantages, you need to know about certain drawbacks. Because DLLs are usually written in C or C++, a good programming knowledge of C or C++ becomes essential. Programming using C or C++ is not the easiest task. It has a steep learning curve, and understanding pointers and pointer management is important.

As indicated earlier, DLLs are likely to create distribution nightmares. For more on this topic, refer to the section titled "Static Versus Dynamic Library," earlier in this chapter.

Integrating DLLs with a front-end application written in a 4GL language calls for an effective implementation of errorchecking protocol. An added component to debugging exists-in addition to debugging your front-end application, you also have to debug your DLL code if necessary.

A Sample DLL

Listing 19.3 shows the three main files for creating a DLL using any C++ compiler. These three files have the following extensions: cpp, def, and .rc. Listing 19.3 also shows the block of code that goes into these three files. Use the export keyword to denote what functions can be called by the calling application. Any function not declared with the export keyword is an internal function and cannot be called by the calling application.

Listing 19.3. The three main files for creating a Windows DLL.

BEGIN FILE : <dll.cpp>

#include <windows.h>

/*** Windows DLL Entrance & Exit Functions ***/

int FAR PASCAL LibMain (HANDLE hInst, WORD wDataSeg, WORD wHeapSize, LPSTR lpszCmdLine)

{

if (wHeapSize > 0 )

UnLockData(0);

return 1;

}

int FAR PASCAL _export WEP(bSystemExit)

int bSystemExit;

{

return 1;

}

/* enter the code for your function here */

int FAR PASCAL _export your_function(<param1, param2, param3,... , paramN>)

{

<the code for this function goes here>

}

END FILE dll.cpp

BEGIN FILE : dll.def

/* module definition file */

Library

dll_function

/* For WINDOWS EXE, use NAME */

 

 

/* For WINDOWS DLL, use LIBRARY */

Exetype

WINDOWS

 

Description

'WINDOWS Sample DLL'

Stub

'WINSTUB.EXE'

 

Code

Shared Moveable Discardable Preload

Data

Single Moveable Preload

HeapSize

1024

 

StackSize

8192

 

Exports

WEP

/*

identify

the functions */

 

dll_function

/*

that are

being exported */

END FILE dll.def

 

 

 

 

BEGIN FILE : dll.rc

Q7inf RCData

Begin

0x4337, 0x444D, 0x03E8, 0,0,0,0

End

StringTable

Begin

1000:"dll_function,1000"

End

END FILE dll.rc

NOTE

Creating a Windows DLL involves the use of three main files: .cpp, the C+ + source code file; .def, the module definition file; and .rc, the resource file.

Next, you will undertake the task of writing an investment formula DLL. Depositing funds in an interest-bearing account represents a traditional method for accumulating savings. To quickly determine how much time is required to double a sum of money, you can apply an estimate commonly known as the Rule of 72. This estimate provides an approximation. The exact time depends on the compounding method being used.

The Rule of 72 says you divide 72 by the stated interest rate. The result shows the approximate number of years required to double a deposit. Listing 19.4 shows the Rule of 72 formula.

Listing 19.4. The Rule of 72 formula.

Formula : rule of 72

72 / Interest Rate = Years to double

For example, you deposit $5,000 in an account that pays 8 percent interest. It will take 9 years (= 72/8) to double to $10,000. Listing 19.5 shows the source code files for this DLL.

Listing 19.5. Source code for rule72.dll.

BEGIN FILE : rule72.cpp

#include <windows.h>

/*** Windows DLL Entrance & Exit Functions ***/

int FAR PASCAL LibMain (HANDLE hInst, WORD wDataSeg, WORD wHeapSize, LPSTR

lpszCmdLine)

{

if (wHeapSize > 0 )

UnLockData(0);

return 1;

}

int FAR PASCAL _export WEP(bSystemExit)

int bSystemExit;

{

return 1;

}

/* To simplify calculations integer values are used */

int FAR PASCAL _export rule72(int intrate)

{

return(72/intrate);

}

END FILE rule72.cpp

BEGIN FILE : rule72.def

/* module definition file */

Library

rule72

/* For WINDOWS EXE, use NAME */

 

 

/* For WINDOWS DLL, use LIBRARY */

Exetype

WINDOWS

 

Description

'WINDOWS Sample

DLL'

Stub

'WINSTUB.EXE'

 

Code

Shared Moveable

Discardable Preload

Data

Single Moveable

Preload

HeapSize

1024

 

StackSize

8192

 

Exports

WEP

/* identify the functions */

 

RULE72

/* that are being exported */

END FILE rule72.def

BEGIN FILE : rule72.rc

Q7inf RCData

Begin

0x4337, 0x444D, 0x03E8, 0,0,0,0

End

StringTable

Begin

1000:"RULE72(),1000"

End

END FILE rule72.rc

Use the small or medium memory model for compiling and creating Windows DLLs.

VBScript and DLLs

VBScript is a subset of Visual Basic, the programming language. Visual Basic uses the following convention for declaring and calling DLL functions. Because DLL procedures reside in a file external to your application, you have to give your application some information so that it can find and execute the DLL procedures you want to use. You provide this information with the Declare statement. Once you have declared a DLL procedure, you can use it in your code like any other procedure. Listing 19.6 shows the syntax for the Declare statement.

Listing 19.6. Syntax for Declare statement in Visual Basic.

Declare Sub publicname Lib "libname" [Alias "alias"] [([[ByVal] variable_ [As type]

[,[ByVal] variable

[As type]]...])]

or

Declare Function publicname Lib "libname" [Alias "alias"] [([[ByVal] variable_ [As

type] [,[ByVal]

variable [As type]]...])] As Type

If the procedure does not return a value, declare it as a Sub procedure. For example, Listing 19.7 shows the declaration of a subroutine, InvertRect, from the Windows DLL, user.exe.

Listing 19.7. Declaring the procedure-InvertRect.

Declare Sub InvertRect Lib "User" (ByVal hDC as integer, aRect as Rect)

If the procedure returns a value, declare it as a Function. For example, Listing 19.8 shows the declaration of a function, GetSystemMetrics, from the Windows DLL, user.exe.

Listing 19.8. Declaring the function-GetSystemMetrics.

Declare Function GetSystemMetrics Lib "User" (ByVal n as Integer) as

Integer

Because VBScript is a subset of Visual Basic, you would expect that it supports the calling of DLLs. Unfortunately, as of this writing VBScript does not support it. This might change in the future. VBScript is the new kid on the block and continues to evolve as it gains wider acceptance. Future releases of VBScript might support DLL integration.

As previously stated, lack of support for DLL integration limits VBScript. Thousands of DLLs exist that can be utilized and integrated very easily. With no support for DLL integration, you may wonder what options you have. You would have to use the built-in structures for declaring VBScript functions and procedures instead. For example, you would have to define your own function, rule72(), in VBScript to replace the rule72.dll's functionality. Listing 19.9 shows the VBScript rule72() function.

Listing 19.9. VBScript function rule72().

<SCRIPT LANGUAGE="VBScript">

<!--Option Explicit

Dim strMsgBoxTitle

Dim bValidOrder

Dim nyears

Function rule72(int_rate)

nyears = 72 / int_rate

return nyears

End Function

Sub Window_OnLoad

strMsgBoxTitle = "MSFTD"

Call BtnInit_OnClick

End Sub

....

....

....

-->

</SCRIPT>

NOTE

If Microsoft decides to include support for DLLs, you would probably use syntax and format similar to the preceding example for declaring them and calling the DLL procedures.

Another option is to use ActiveX controls. VBScript supports integration of ActiveX controls with HTML. In fact, Microsoft Internet Explorer 3.0 is the only browser in today's market that includes full support for ActiveX controls and VBScript. You can use Visual C++ or Borland C++ to write ActiveX controls-the same tools that you use to write DLLs.

NOTe

Microsoft might not include support for DLLs in VBScript because it is actively promoting its ActiveX technology. In such a case, you would need to convert existing DLLs into ActiveX controls for use with your VBScript code.

Relevant Web Sites

Table 19.1 lists Web sites for more information on DLLs and VBScript. Many resources and examples exist on the Internet.

Table 19.1. Relevant Web sites.

Purpose

Site URL

Overview of dynamic link libraries http://ipserve.com/jzhuk/dll.html

Using Windows to create DLLs http://www.awu.id.ethz.ch/~didi/wxwin/

wx/wx53.html

Windows Developer FAQ on DLLs http://www.r2m.com/win-developer-FAQ/

 

dlls

VBScript

http://www.microsoft.com/vbscript

VBScript links

http://www.microsoft.com/vbscript/us/

 

vbsmain/vbslinks.htm

Review

DLLs represent important technology that has gained wide acceptance over the years. Although DLL technology is a precursor to OLE and ActiveX, it is still very much in wide use. Understanding how to write DLLs helps you extend the capabilities of your application and maintain code modularity.

You can link a library with the executable in two ways: statically and dynamically. Static linking provides better performance. In the case of a DLL, it has to be first loaded before it can be used. In static linking, you do not have to worry about maintaining different versions of the library because it is completely embedded and linked into the executable. In dynamic linking, DLL maintenance becomes critical, because you would end up having different versions of the same DLL over time.

DLLs may have any file extension (res, fon, exe, or dll). A DLL program does not include the main() or winmain() function. Instead it contains the functions Entry, LibMain, and Exit.

A pool of third-party developers for Visual Basic and other Microsoft programming tools has created a large volume of enhanced controls and libraries that you can use with your Windows applications. Most of these controls and libraries are nothing but DLLs. A DLL is usually written using C or C++, which provides speed and efficiency. You should perform mathematically intensive tasks using DLLs, and use your favorite GUI tool for building the user interface. Your application gains improved speed and response time. And code modularity is maintained.

As of this writing, the current release of VBScript does not support DLL integration, which indicates a very serious limitation in VBScript. If and when Microsoft includes support for DLLs, the syntax and format for declaring them and calling the DLL procedures would probably be similar to that discussed in the "VBScript and DLLs" section. Another option is to convert existing DLLs into ActiveX controls and integrate them with your VBScript code.