Details of user protection, Linking objects and static libraries in external c, Use of dllmain: clarification – National Instruments Window User Manual

Page 27: Releasing resources when a dll unloads: clarificat

Advertising
background image

©

National Instruments Corporation

27

LabWindows/CVI Release Notes for Windows

Details of User Protection

The Avoid Unassigned Dynamic Allocation in Function Parameters section is new to the
Details of User Protection discussion in Chapter 1, LabWindows/CVI Compiler, of the
LabWindows/CVI Programmer Reference Manual.

Linking Objects and Static Libraries in External Compilers

When you use an external compiler to link a project that contains object or static library
files created in LabWindows/CVI, there are several points to remember. Refer to the Using
Object and Library Files in External Compilers
section in Chapter 3, Windows 95/NT
Compiler/Linker Issues
, of the LabWindows/CVI Programmer Reference Manual for more
information.

Use of DllMain: Clarification

Each DLL can have a

DllMain

function, except that the Borland compiler uses

DllEntryPoint

as the name. The operating system calls

DllMain

with various

messages. To generate the template for

DllMain

, use the Insert Constructs command

in the Edit menu of the Source window.

Use caution when inserting code in the

PROCESS_ATTACH

and

PROCESS_DETACH

cases.

In particular, avoid calling into other DLLs in these two cases. The order in which
Windows 95/NT initializes DLLs at startup and unloads them at process termination is
not well defined. Thus, the DLLs you want to call might not be in memory when your

DllMain

receives the

PROCESS_ATTACH

or

PROCESS_DETACH

message.

It is always safe to call into the LabWindows/CVI Run-time Engine in a run state change
callback as long as you do so before calling

CloseCVIRTE

.

Releasing Resources when a DLL Unloads: Clarification

When a program terminates, the operating system releases resources your DLL allocates.
If your DLL remains loaded throughout program execution, it does not need to release
resources explicitly when the system unloads it at program termination. However, if the
program unloads your DLL during program execution, it is a good idea to have your DLL
release any resources it allocates. The DLL can release resources in

DllMain

in response to

the

PROCESS_DETACH

message. Alternatively, the DLL can release resources in a function

that it registers with the ANSI C

atexit

function. The system calls the function you register

when the DLL receives the

PROCESS_DETACH

message.

If your DLL calls into the LabWindows/CVI Run-time Engine DLL, it can allocate resources,
such as user interface panels. If a program unloads your DLL during execution, you might
want to release these resources by calling functions such as

DiscardPanel

in the

LabWindows/CVI Run-time Engine. On the other hand, as explained in the previous section,
it is generally unsafe to call into other DLLs in response to the

PROCESS_DETACH

message.

Advertising