CA2186684C - Dynamic library task switching - Google Patents

Abstract

A method for providing per-instance data memory in a particular dynamic link library loaded in a random access memory address space both as part of a first task and as part of a second task loaded in the address space simultaneously, in a computer having memory management hardware including a local descriptor table to map selectors to base addresses. The method includes providing a task switch enhancer DLL (the TSE); providing in the TSE a DLL registration routine to register a DLL
with the TSE; providing in the particular DLL a call to the DLL registration routine; providing in the TSE a task registration routine to register a task with the TSE;
providing in the first task and in the second task a call to the task registration routine; providing a routine requesting the operating system to provide a switching notification whenever execution of any task is about to begin or end and whenever any task is about to cease to exist; providing in the TSE a segment allocation routine for allocating a memory segment for storing per-instance data of a DLL for a task as a substitute for an original per-instance data segment for that task, and maintaining a substitute base address being a base address for the allocated segment in the LDT entry and maintaining an original base address being the original base address of the original segment in the LDT entry; calling the TSE
segment allocation routine for a per-instance data segment of the particular DLL for the first task during initialization of the first task and calling the TSE
segment allocation routine for a per-instance data segment of the particular DLL for the second task during initialization of the second task; providing in the TSE a base address setup routine to store in the LDT entry the substitute base address of a per-instance segment of a task before that task begins execution; and invoking the base address setup routine for the substitute base address for the first task in response to a switching notification received by the TSE that the first task is about to begin execution.

49357.P11

Description

21866~8~

DYNAMIC LIBRARY TASK SWITCHING
BACKGROUND OF THE INVENTION
Field of the Invention The invention relates to methods and programs for running multiple instances of programs and shared libraries under a multi-tasking operating system, and in particular to running such programs and libraries under an operating system such as Microsoft Windows 3.1.
Background A dynamic link library (DLL) provides a shared library of code and data that can be linked to multiple tasks (such as application programs) in by an operating system such as Microsoft~ Windows 3.1 or Windaws 3.11.
In this context, it is desirable to be able to run :L5 multiple instances of a DLL, and multiple instances of an application, simultaneously. Running multiple instances of an application in Windows 3.1 would require that the application s DLLs be shared between instances of the application or across applications using the same DLL.
While this feature is available in a number of operating system environments, such as Microsofte Windows 95, it conflicts with the design of the Windows 3.1 and 3.11 DLL. (From this point on, the term DLL will refer to a DLL as it is known in the Windows 3.1 and 3.11 environments, which run on microprocessors compatible with the Intele brand 80x86 family of microprocessors, and the tern Windows will refer to Windows 3.1 and 3.11 environments, unless expressly noted otherwise.) In a Windows 3.1 DLL with multiple data segments, global :30 variables will be shared by all the applications using the DLL.
In an operating system that is designed to run applications in separate address spaces, memory would be allocated for each application and the memory of the application would be switched in or out by the operating system by changing a set of registers or memory locations to switch to the appropriate memory for the application.
The Windows 3.1 environment was not designed this way even though Intel microprocessors make the functionality available in a mode of operation called protected mode.
The Intel protected mode has the same segment registers (CS, DS, ES, and SS) as the real mode, but the segment address is a 16-bit item known as a "selector".
Protected mode requires a block of memory known as a "descriptor table". The descriptor table can contain up to 8,192 8-byte entries. The upper 13 bits of the selector is an offset that references one of these entries. The descriptor table entry contains a "base address" that determines the starting point for the memory being accessed by the selector and a "limit address" that supplies the end of the range of memory accessible by the selector.
In other multitasking operating systems, the GDT
(global descriptor table) provided by the Intel protected mode is used to manage operating system memory and each process gets its own LDT (local descriptor table) for its own memory. In this way, processes are protected from interfering with each other. However, Windows 3.1 uses a single LDT that is shared among the operating environment and all Windows applications.
Turning to FIG. 1, and as stated above, global variables in segments 16, 17, and 18 will be shared by all the applications 10, 11, and 12 using each Windows 3.1 DLL 13, 14, and 15. (In the figure, the applications are APP1, APP2, and a second instance of APP2, respectively, and the DLLs are DLL1, DLL2, and DLL3, respectively.) This is a side effect of the fact that the code in a DLL is the sane regardless of which application is accessing it. A DLL is initialized once when it is first loaded into memory by the loader. If a DLL has more than one data segment, a selector for each data segment is allocated by the loader and inserted into the code segment at any point in the code that accesses the data segment. Since this selector address is inserted into the code segment which is shared between applications, the data must also be shared. This results in global data being shared between applications.
Various approaches for dealing with the problem have been implemented. All require some method for gathering per-application instance data into a block of memory allocated by the application and maintaining the "base address pointer" of this memory block for use when the application enters execution.
In a first approach, the task (application) passes the base pointer as a parameter on every call to the DLL.
A shortcoming of this approach is that it is not applicable in a situation where the DLL is the implementation of a C++ class library and some of the classes have shared variables.
In a second approach, the base pointer is kept in a well-known place in the task, for example, in a fixed address at the beginning of the stack segment. The appropriate base pointer is made available automatically when each task is entered because each task has a unique stack address. A drawback of this approach is that it requir~as a special structure and a fixed position for each DLL using it.
SUMMARY OF THE INVENTION
The invention provides per-instance data memory in a DLL linked to multiple tasks or to multiple instances of one task. A base address for each DLL instance is kept for the individual DLLs and base addresses are 218668~-switched when tasks are switched. The operating system is requested to inform an external service or ~switcher~
DLL, called TSE (Task Switch Enhancer) when tasks are switched so that base addresses can be switched and other housekeeping can be done.
The gathering of per-instance data into a memory block for each application is done by a mechanism involving both the compiler and the linker. In the context of an illustrative fourth generation language 1.0 (which we name "FGL") that generates C code for further compilation by a C compiler, the C language coding that will be described is done by the FGL compiler; otherwise, it is done by the programmer writing the C code, and the invention may be practiced either way. (The term C will 1.5 be used generically to encompass C++ as well, as implemented, for example in the Microsoft~ Visual C++
compiler, version 1.5.) By inserting instructions to the linker in a C program to indicate the segment in which a variable belongs, the linker will allocate all the 20 variables belonging to the segment into one block.
Including further instructions to the linker in linkage code supplied in a mandatory assembler object creates a unique segment group to prevent the linker from mixing such segments with others. Therefore, when the DLL is 25 loaded, this secptent will have its own descriptor, which is napped at runtime to an instance-specific physical addross.
The invention has a number of advantages. For exempla, using the invention, only variable declarations 3o need to be modified to achieve per-instance operation, and efficient code results.
Other advantages and features will become apparent from the following description and from the claims.

2issss~

BRIEF DESCRIPTION OF THE DRAWINGS
The accompanying drawings, which are incorporated in, and constitute a part of, the specification, schematically illustrate specific embodiments of the invention and, together with the general description given above and the detailed description of the embodiments given below, serve to explain the principles of the invention.
FIG. 1 is a block diagram illustrating tasks (applications), DLLs, and DLL data segments in prior art relationship.
FIG. 2 is a block diagram illustrating a relationship created by a task switch enhancer (TSE).
FIG. 2A is a schematic block diagram illustrating x5 the relationship of a DLL selector to a local descriptor table (LDT) descriptor base address, to data segments created by the TSE.
FIG. 3 is a flowchart illustrating the process associated with bringing a DLL into memory.
FIG. 4 is a flowchart illustrating the process associated with first starting a task.
FIG. 5 is a flowchart illustrating the process associated with switching a task.

2~~6~~4 DETAILED DESCRIPTION
Turning to FIG. 2, applications 100, 110, and 120 are linked, as shown, to three DLLs 130, 1.40 and 150.
Applications 110 and 120 are two instances of the same program. This corresponds to FIG. 1, except for the enhancements made to the applications and DLLs for TSE, which will be described. With the enhancements, however, a DLL, such as DLL2 140, will have a separate data segment 170, 171, and 172 for each task instance that is using the DLL, namely, in this illustration, applications 100, 110, and 120.
Turning to FIG. 2A, TSE effects the switching between or among data segments, illustratively segments 171 and 172, by switching the contents of the base :15 address portion 220 of the descriptor 210 (in LDT 200) that selectors) 142 (in DLL DLL2 140) point to. The base address 220 will point to the original data segment 175 loaded with DLL2 140 when no application is using DLL2 140, and to data segment 172 when application 120 is using DLL2 140.
Thus, turning back to FIG. 2, TSE will cause base address contents to point to data segments as shown in FIG. 2: DLL1 130 will point to data segment 160 when APP1 100 is linked to DLL1; DLL2 140 will point to data segment 170 when APP1 100 is linked to DLL2; DLL2 140 will point to data segment 171 when APP2 (:first instance) 110 is linked to DLL2; DLL2 140 will point to data segaont 172 when ?~PP2 (second instance) 120 is linked to DLL2; DLL3 150 will point to data segment :180 when APP2 (first instance) 110 is linked to DLL3; and DLL3 150 will point to data segment 181 when APP2 (second instance) 120 is linked to DLL3.
Registration. Turning to FIG. 3, when a DLL is brought into memory, it registers itself with TSE, step 2igsss4 340, supplying a notification callback function. When a DLL is loaded that calls TSE routines, TSE is also loaded, if it has not already been loaded, step 310.
After all required modules have been loaded (step 320), Windows calls LibMain() for a DLL (step 330), which calls TSE to register all of the DLLs linked to the task (steps 340 and 350).
Turning to FTG. 4, when a task starts execution, it calls WinMain() which calls TSE to register the task with TSE, steps 410 and 420. WinMain() also calls TSE to look through the task's DLL list and to call notification callbacks of the DLLs registered with it, steps 430, 440, and 445. The callback function will typically request TSE to instantiate some segment(s), steps 450, 452, and 454, and then call module initialization functions to initialize global and class member variables, step 460.
Because instantiation (described below) copies the original segment, all the static initializations generated for global variables will be preserved.
,segment Instantiation. To instantiate a segment (which can belong either to an application or to DLL), TSE makes a copy of a segment memory and remembers its flat address. After that, every time the task is activated, TSE will set the address in the corresponding entry of the local descriptor table (LDT) to point to the rameabered address. Thus, each instance of the task will use the instance data.
Initialization. To provide per-instanca'data to multiple tasks sharing a DLL, the data from the separate modules comprising a DLL is consolidated to allow easy duplication for each instance of an application using the DLL. This is done by including C compiler pragmas in the source code to name the segments and segment groups.

21w~6fi-84 _8_ Also, an assembler language object is created to be linked with the DLL to consolidate segment groups so the linker will group data segments together according to the names provided in the compiler pragmas. The assembler object also provides a function that returns the base address of this data segment.
A set of initialization functions is provided that includes a Libt4ain(). (A LibMain() must be provided to initialize all Windows DLLs). This TSE LibMain() calls TseDllRegister() to register the DLL with TSE, step 340.
Its arguments are (1) the Windows "instance handle" for identifying the DLL, and (2) the address of a callback function that will be called by TSE each time the DLL
needs initialization for a new instantiation. The call to TseDllRegister() causes TSE to insert the DLL into a list of registered DLLs.
A set of initialization functions is provided to be called from the start-up module, for example, the WinMain() function, of an application for registering with TSE. These include TseTaskRegister(),, which causes TSE to place the Windows task handle in a :list of tasks registered with TSE, step 420, and TseDLLInstantiateALL(), which causes TSE to search through the module table for the calling task and compare the list of DLLs used by the task to the list of registered DLLs. When TSE finds a match, it calls the callback function previously recorded for the DLL when TsaDllR~gister() was called, step 445. In response, the DLL that TSE is calling passes back the selector that references the per-instance data segment of the DLL. TSE
allocat~s a block of momory (which belongs to th~ task that will use the memory, not the TSE DLL) of the sage size as the original data segment referenced by the selector and copies the contents of the original data segment into the newly allocated block of memory, step 2isss~4 _ g _ 452. TSE maintains the original selector and the selector of the newly allocated block in a list of selector pairs for each DLL being used by the task, step 454. (In place of TseDLLInstantiateALL(), TseDLLInstantiate() can be called as often as~needed to instantiate particular DLLs.) In addition, TSE also calls the callback function and directs it to call any module initialization functions, step 460. Module initialization functions are .l0 typically generated by compilers to perform functions such as registering classes and initializing global variables.
In order to be modified of task switching events, TSE calls the Windows Toolhelp API NotifyRegister() function, passing to it the task handle of the TSE task and the address of a TSE function (the "notify callback") that will be called by Windows any time any task is entered or exited, steps 472 and 474. TSE must pass NofifyRegister() a task handle as a parameter, and it uses the task handle of the first task that called TSE.
NotifyRegister() associates the notify callback with this task handle. When this task terminates, TSE recognizes the condition and, as described later, associates itself to another TSE-registered task. This particular task is referred to as tha TSE task.
Oyeration. Turning to FIG. 5, when a task is entar~d, tha notify callback in TSE checks the list of tasks registered with TSE to see if the task being entered is registered, steps 51o and 530. If it is and is exiting, step 540, TSE switches the descriptors of the selector pairs so that the original selector references the aemory block allocated for the task by TSE, step 532, and the allocated selector references the original memory segment. Whan a task terminates or exits, the callback 2l$ssa4 in TSE checks the list of tasks registered with TSE to see if the task is registered, step 510. If it is, TSE
switches the descriptors of the selector pairs so that the original selector references the original data segment and the selector allocated by TSE references the allocated memory block, step 542. In this way, TSE
restores the mapping to what Windows thinks it is. If it is registered and is terminating, step 520, TSE
deallocates the associated allocated per-instance memory, :LO step 522, unregisters the task, step 524, and, if the task was the one associated with receiving TSE task switch notifications, TSE transfers the association to another TSE-registered task, step 526.
TSE switches the base addresses by using the DOS
Protected Mode Interface (DPMI) functionality. TSE uses two functions provided by DPMI, one to request the base address of a descriptor addressed by a selector provided by the application, and the other to change the base address of a descriptor addressed by a selector provided by the application.
The TSE task, which owns the original task handle that TSE used when calling NotifyRegister(), may terminate. In that case, TSE calls NotifyUnregister() for that task handle and then calls NotifyRegister() again, passing the task handle of the first task in the list of tasks registered with TSE, which first task then becosea the TSE task. This is done because Windows will not call the callback if it is associated with a task that has terminated.
~0 Note that, in Windows, a memory block can be owned either by an application or by a DLL. Data segments allocated by the loader as part of loading a DLL are owned by the DLL. The segments TSE allocates for the per-instance data are owned by the task that TSE is linked to at the time TSE does the allocation.

If all tasks registered with TSE terminate, TSE
will release the allocated memory and selectors and then terminate.
Unreaisterinc. Although task un-registration is not strictly required, because TSE monitors task terminations and can do so automatically, it is provided by means of TseTaskUnregister() as a safety precaution.
A DLL that is to be used with TSE should be coded to unregister itself, in its WEP() (Windows Exit Procedure) 1.0 procedure, for example.
~~E API Details. The following five routines provide library instantiation services.
1. BOOL TseDllRegister(hLibInst, initCallback) registers the DLL identified by hLibInst with TSE. The 1.5 second argument is the address of the callback function called by TSE when DLL is instantiated/terminated.
TseDllRegister() is usually called from LibMain() where the instance handle is readily available. Thus, the instance handle is converted into a module handle to 20 simplify later module table lookups.
2. initCallback(wReason) is a placeholder for the user function that is called by TSE. The parameter wReason spacilia the event that triggered the call.
When called because the DLL is i~nstantiated, the callback 25 should instantiate all the segments containing par-instance data and then initialize them.
3. TseDllUnregister(hLibInst) removes the DLL
identified by hLiblnst frog the r~gistered DLLs list.
4. TseDllInstantiate(hLibInst) instantiates the DLL
30 specified by hLibInat for the currant task. This routine checks that the DLL identified by hLiblnst is registered and ignores unregistered ones. It checks that the current task is registered with TSE. If the DLL has been 218fi684~

already instantiated for the task, this routine returns.
Otherwise, it calls the DLL's notification callback and stores per-instance data information in the task list for this task.
5. TseDllInstantiateAll() calls TseDllInstantiate() for each DLL used by the current task.
The following three routines provide segment instantiation services.
1. TseTaskRegister() adds the current task to the TSE
1.0 task list. On the first call, it links the current task to TSE (which is a DLL). (This task may be referred to as the TSE task. This routine should be called before either TseDllInstantiate() or TseDllInstantiateAll().
2. TseTaskUnregister() removes the current task from the TSE list. All the instantiated segments of the task are restored to their original state.
3, TseSegmentInstantiate(hInstance, hSegment) checks that the current task has been registered. It allocates a new segment, makes a copy of hSegment into it, and swaps the addresses of those two segments. The argument hInstance identifies segment's owner: it is a DLL handle.
Data Structures. TSE's basic data structures are a TSE registered library list (a linked list of LIBENTRY
structures) and a TSE registered task list (a linked list of TSBNTRY structures).
The registered library list keeps the module handle of each DLL in the LIBENTRY structure as the primary search key, although the module name is also maintained for error monitoring purposes. The TSE NOTIFYCB initialization function pointer is maintained here; it is DLL specific and will not vary as a function of the application. The original DLL
FGL INSTDATA selectors (the selectors for the DLL's original data segment) are also kept for error detection and monitoring purposes. The structures of the registered library list are illustrated in the following table.
-// Start of Library Selector List structa struct taqLIBSBL {
struct taqLIBSBL *pNextt UINT s~loctor;
YO ?t typedef struct taqLIBSBL LIBSEL, *PLIBSELf struct taqLIBBNTRY
char modNaiae [ 9 ] ;
HMODULi hLibrary=
CINITPROC pInitProct //Called when the Sxe has been initialized //if "moduleInitialized is FALSB
SOOL moduleInitializedi//TRU$ if DLL initialized UINT usageCount; //TSB usaqeCount (Maybe not same as system use count //Inc/Dec when Task Starte/Terminates PLIBSEL pSelList;
struct taqLIB=NTRY *pNextLibf ?i typed~f struct taqLIB3NTRY LIBENTRY, *PLIBBNTRY;
~5 -The TSE registered task list is a linked list of TSENTRY structures containing the HTASK (task handle) as the priaary search key. It contains a pointer to a linked list of TLIBENTRY structures which identify the 30 DLLs being used by the task. This list is maintained for error detection and recovery. It also contains linked list of TLIBSEL structures where the original and the allocated per-instance selectors are maintained for switching on task entry and exit. A flag "'selSwitchMode"
35 in the TLIBSEL structure determines if the selector being used currently is the original selector or the selector 2lsss~4 allocated for this instance. This is used for error detection and for switching selectors back to their original state during task termination. ?'he module name and module handle are redundantly kept in the TLIBENTRY
and the TLIBSEL for monitoring and error detection.
These data structures are illustrated in the following table.
~truct tagTLIBENTRY {
char modName[9]; //Name for thi~ DLL
FI~DULB hLibrary; //For thi~ DLL
CINITPROC pInitProc;//Call~d when the Exe ha~ been initialized //if "moduleInitialized is P1lLSE
SOOL ~mory?~llocated;//TRUE if DLL n~aory has been allocated BOOL moduleInitialized;//TRUE if DLL is initializ~d PLIBSEL pSelLi~t;//Linked li~t of selectors maintained by TSE
~truct tagTLIBENTRY *pNextLib;
)i typedef struct tagTLIBENTRY TLIBENTRY, *PTLIBENTRY;
2 0 etruct tagTLIBSEL {
char modNanw[9];//Name of DLL u~ing these ~elector~
HMODULE hLibrary;//HMODULE for DLL u~ing the~e selectors BOOL salSwitchMode; //SWITCIiED ~ TRUE
HOOL memory~rllocated= //True if Memory l~llocated a 5 UINT origSelector; //Original Selector UINT taskSalector; //Instance Selector ~truct tagTLIBSEL *pNextSelt ):
typadef ~truct tagTLIBSEL TLIBSEL, *PTLIBSEL;
:30 struct tagTSENTRY {
HTA.S1C hTask; //Task H11NDLE for ta~k u~ing this ~tructure FIINSTAIiCE hIn~taace f UINT in~tanceNu~iber;
char ta~kNamis[9];
35 char newTa~kNam~[9];
char tuklilena~ [ 13 ] ;
char ne*rTa~ktilenaee[13];
BOOS. dll~Initialized;//Task has all it~~ DLLs initialized PTLIBEIiTRY pTa~kLibLi~t; //Linked li~t of DLLs using TSE for this 40 ta~k PTLIiSEL pTa~k8elLi~t; //Li~t of selectors u~ed by TSE for this task ~truct taqTSENTRY *nextTa~k;
)f typedef ~truct tagTSENTRY TSENTRY, * PTSBNTRY;
45 _ Example ~lly~,glication Initialization Sequence. The discussion below illustrates initialization sequence for a MYAPP application that uses a MYLIB.DLL (assume for this illustration to be a C library).
[MYAPP]
The user starts MYAPP.EXE. Kernel passes control to astart(), which calls InitTask(), which is a call to kernel to load DLLs.
[KERNEL]
For each DLL needed by the application that is not already in memory, kernel loads it and calls its entry point libentry().
[MYLIB]
The routine libentry() calls _cinit() for C
runtime initialization, which in turn calls LibMain(). LibMain() registers the DLL with TSE
by calling TseDllRegister(hLib, InitInstance).
[TSE]
TSE adds (hLib, InitInstance) to its registered ~0 library list and returns to MYLIB.
[MYLIB]
LibMain() returns TRUE.
[KERNEL]
Kernel proceeds as above with other DLLs. After ~5 all DLLs have been loaded, kernel returns to the application.
[MYApP]
Ths application calls cinit() for C runtime initialization, which then calls WinMain(), where 30 the user code begins. WinMain() calls TseTaskRegister().
[TSE]
TseTaskRegister() adds the current task to the registered task list. (No instantiated segments 35 have been created yet.) 2lssss4 [MYAPP]
WinMain() calls TseDllInstantiateAll().
[TSE]
TseDllInstantiateAll() scans the list of DLLs needed by MYAPP. For each registered DLL, it calls the DLL's callback with a reason code indicating that segments are to be inetantiated.
[MYLIB]
The callback routin~ calls TseSagmentInstantiate.
[TSE]
TseSegmentInstantiate() makes a copy of the segment, and adds original and copied selectors to the list of segments to be swapped on activation of the current task.
:15 [MYLIB]
After TseSegmentlnstantiate() returns, the callback routine returns to TSE.
[TSE]
Continues for other DLLs.
[MYAPP]
Executes application system initialization code to register classes and initialize variables.
Finally, it calls the main application module.
Consolidating Data and Initialization. As has bean a~ntioned, per-instance data is linked into contiguous s4gments for processing by TSE. A data consolidation mechanism may also be needed in the case of prograaming languages or environments with an object or class oriented design, such as a 4GL. This may arise in two cases. First, for initialization, each compiled module may contain the code that has to be executed before a main program gets control. Classes that the application will use may have to be registered in order to calculate member variable offsets and object sizes.

2lssss~.

Also, if any global and/or shared member variables are defined in a module and explicitly initialized, the initialization code has to be executed. A 4GL compiler typically generates one initialization function per module and a variable containing the address of it. By making the linker build an array of those addresses, start-up code is able to call them easily.
Consolidation across modules is also useful if a DLL is to be used by a pseudo-code interpreter, for which the DLL must supply function names and their addresses.
A FGL compiler can generate an array of these for each module, and the linker can be made to consolidate these arrays from all the modules that the DLL contains.
The Microsoft linker provides a consolidation mechanism in the form of logical segments (not to be confused with 80x86 memory segments, which are named segment groups). Logical segments control how the linker combines the code and data when it builds an executable from separate modules. Each object code entity (function code and global variable) belongs to some particular logical segment. A logical segment has a number of attributes associated with it that control where it will be located in the executable, including segment group and segment class.
Sogment group is used by the linker to combine logical segments into physical segments: all the logical segmonta belonging to the same group are put into one physical segsent. To specify a logical segment's group, a GROUP directive in an assembler module is used.
Segment class together with segment name controls how the logical segments from the different object modules are combined. The linker combines the data from all the segments with th~ same name and class into one contiguous block of memory. Within the class, the data belonging to the same segment is put into one contiguous block. The relative order of the segments within a class is determined by the order in which the linker sees them.
With a Microsoft C compiler, variables may be allocated to specific segments with a ,~pragma directive.
The directive #pragma data-/ag( "lI7C8iG", "MYCL1~SS" ) instructs the compiler to put all the variables that follow the directive into segment MYSEG, which belongs to the class MYCLASS. For multiple ,~pragma data_seg directives, the compiler generates logical segments in the reverse order of their declarations in the source code.
Thus, data from separate modules can be consolidated into a contiguous array and its starting and ending address can be obtained as follows. First, each module must define the same logical segment sequence, for example:
*prac~ma data,oag("FGL ao0_3ND", "FGL FOO") #pragma data_sag("FGL TOO U88R", "FGL P~00") 2 0 #pragma data sag("FGL 1r00 BEGIN",~"FGL 1r00") #pragma data s~g(y Each object nodule will then contain the segments FGL FOO BEGIN, FGL FOO_USER, and FGL_FOO_END, in that order. Data to be consolidated is then put into the ~5 FGL FOO USER segment, the middle segment in the set of threw.
Tha runtime start-up module declares the segment sequence as above and provides a dummy element at the beginning:
static footypa based ( aagnaa~("1roL !0O BRGIN")) foo- -begin = NULL
and a label at the end:
static footype _baa~d ( s~gnaow("PGL 1~'00_END")) f o0 and = NULL. .

As a result, the executable will contain a.n array of data, of any kind, sandwiched between foo begin and foo end. Thus, if the data is an array of initialization functions, initialization may be accomplished by calling only one routine and passing it the address of the initialization functions vector and the address of the first word after the end of it.
Data and function consolidation is useful, as has been mentioned, in the context of 4GL programs interpreted by a pseudo-code (p-code) interpreter. DLLs supporting TSE per-instance data can be made accessible to p-code interpreted applications. As described, each DLL will be built to export a "userfunc" array, that is, an array of function names and their entry points, for use by the interpreter to resolve the references to DLL
functions, as well as by the debugger.
In addition to the function names, the userfunc array may also contain the name/address pairs of the global and shared member variables defined in a DLL, that need to be accessed from the p-code interpreter or from a debugger.
Generating user unc. A 4GL coapiler can generate a userfunc array for ~ach FGL modul~. It contains the entries for all the functions and methods defined in the module as follows:
// Provide segwnt ordering #pragaa data-seg("FGL OF slip","FGL OF") #pracpoa data aeg("FGL U1~ U83R","!GL OF") #prac~aa data sey ( "FGL Ul~ SiGIii" , "FGL UF" ) // Rent to default data segment #pxagma data seQ() // Put u~~rfunc into FGL OF U88R segment otatic ~truct userfunc _baied ( segname("FGL OF USER")) _FGLuserfunc(] ' 3 5 ("functionl", (USSRFUNC)functionl,<#arg~>) {"function2", (USBRFUNC)function2,<#args>) };'..............

2186G8~
- z0 -The runtime start-up can then provide the entry point for the consolidated userfunc array as follows:
// Provide dummy exportable entry struct userfunc based (-segname("FGL OF HEGIN") export _FGLuserfunc() _ ( ("",NULL} // so ~t will not match any name ):
/ / 1~ sent ine 1 static struct userfunc _based (_segnanw ( "1P~GL OF BND"
FGLuserfunc() _ (NULL,NULL) ~1 Generating Module Initialization Code. A 4FGL
compiler can generate the module initialization function in an FGL-INIT segment as follows:
// Define segawnt ordering, then reset to default segment #pragaia data-peg("FGL INIT END","FGL INIT") #pragma data_seg("lrGL INIT USER","!'GL INIT") ;20 ~ra~a data sue( "~L-INIT SgGIN", "FGL_INIT" ) #P 9~ _ e9( ) // Define module initialization function address static void * based ( segnanw("FGL INIT USSR")j FGLinitptr = (void *) FGLinitcj The runtime start-up can then provide an entry ~5 point for the consolidated module initialization functions array as follows:
// Brovide beginning void * based ( segname("!'GL_INIT_HBGIN"jj IGL~nitfunc~= NULLp :30 // 8rovide sentinel void * based ( segname("lrGL INIT BND"jj IGLInitfunclT= NULL=
As a result, ~ FGLinitfunc0 and ~-FGLinitfuncN are starting and ending addresses, and if the .segment :35 FGL INIT USER is loaded with initialization routine addresses, the initialization can be performed by calling one routine, for example, fglInitl~ll ( G lrGLinitfunc0, G tGLinitfuncN) , that successively calls each function whose address is 40 loaded in the segment.

Loqical Segments and GrouR~. In order to save space in the default data segment of the executable and in the instantiated data segment in a DLL, all static data can be put into a separate, read-only segment group, named, for example, FGL RODATA. This group may contain the illustrative segments listed in the assembly language source code module set forth later in this description For an application, the segments in FGL RODATA and the group itself are defined in an asaembl.er abject code module. In addition to the segments and group definitions, the module contains a dummy variable referenced in the application initialization module to ensure that this assembler object module will be loaded with the application to give effect to the segment and group definitions in the linker.
For a DLL there may be two 4GL-specific groups, FGL RODATA as described and FGL INSTDATA. FGL INSTDATA
may contain tha a logical segment for per-instance variable information and data.
The definitions of the segments and groups for a DLL are in an assembly language module that also contains the function FGLInstanceSeg(), which returns the selector assigned to the FGL INSTDATA group. Source code for such an assembly module is shown in the following table.
_ This ~~odul~ contains definitions of the logical ugments and ; smgsrst group (i.a., physical s~nta) used by ayat~ and us~c !'GL DLLs.
; It also contains lGLInstanco8~g() function that returns tht :30 ; sag~snt of the 1GL INBTDATlr.
The following tabli summarizes the scents dafinsd, thair ; order and uuga.
; Sent Class Siza Rd/Wri Usagm :35 ; ssasssssssssssasssssssssssssssassssssssssssssssssssssassssass !'GLINIT BBGIlfTGL_INIT4 RO Provides ; - - the address !GL IIiIT 1~'GLIIiITvaries RO of module USSR initiaization functions array llddr~ss~s of module initialisation _ functions TGL INIT BND !'GLINIT4 RO Smntinal the array for ________________________________________________.______________ IrGLUP B=GIN !GL INIT12 RO Provides address of the the userfunc array PGL U! USER !GL INIT varies Userfunc array RO

FGL U1~ END FGL_INIT 12 RO Userfunc array sentinel ____________ ___________________________________ ____________ ; FGL VT FGL VT varies Class virtual address tables RO

_________ _____________________.._____________.._________________ FGL CI FGL CI varies Other class information RW

____________ ___________________________________..______________ !GL_D7lTl~r PGL_DI~Tl~varies User data RW

; ssssssssssssssssss=ssasa ssssss=ssssssssas=sssssssss:ao=sss:ate Two segment fined:
groups are de F'GL ROD7~T1~contains read-only - data (FGL
INIT-xxx, PGL U!
xxx, and P'GL VT
segments) ; FGL INSTDI~Thcontains inatantiatoddata ( IrGL DlITJr and FGL CI ) Init related segments.

FGL INIT BEGINSEGMENT WORD PUBLIC'FGL INIT' PGL INIT BEGINBNDS

FGL INIT USSRSEGI~NT WORD PUBLIC'FGL INIT' FGL INIT AND SEGNBNT WORD PUBLIC'FGL INIT' lrGL RODIITJrGROUP FGL INIT
BEGIN, FGL INIT
USER, FGL INIT
END

Userfunc-related segments 2 FGL U! BEGIN SEGMENT WORD PUBLIC'FGL UF' FGL U! BEGIN BNDS

FGL OF USER SEGMENT WORD PUBLIC'FGL UF' FGL OF USER ENDS

PGL U! 8ND SEGI~NT WORD PUBLIC'FGL U!' P'GL U! END ENDS

FGL RODPrTJ~ GROUP FGL OF
BEGIN,FGL
OF USE:R,P'GL
OF END

VTAB

PGL VT SEGMENT WORD PUBLIC'FGL VT' iGL vT ENDS

~ FGL RODATJv GROUP lrGL VT

CLASSINFO

FGL CI SEGMENT WORD PUBLIC'PGL CI' 1~'GL CI ENDS

TGL INSTDIITI,GROUP PGL
CI

4~0; Uiar data _ ?GL D11T11 SEGMENT WORD PUBLIC' FGL_DPrTA' dataLabel label byte rcL Darn s~ros ~'GL I11S?D11?11GROUP P'GL D11TA

4~ ; _ _ ; lUNCTIOlI: 1~GLInstanceSeg = PURPOSE: Returns the 1~GL_INSTD11T1~ group the segment of f . YODEL L7WGE, C

50 . ooDE

!'GLInatance8egPROC
--IiOV A7t, BEG datalabel RET!

I~GLInstanceSegENDP

5 _ PUBLIC FGLZnetanceSeg END

2isss~4 Multigle Instances of EXE Programs. As a corollary to the ability to run multiple instantiations of one DLL simultaneously, it is desirable to be able to run multiple instantiations of one program simultaneously and, more particularly, multiple instantiations of one .EXE program. Windows limits one's ability to run multiple instantiations of one .EXE program by rejecting requests to run multiple instances of an .EXE program that has multiple veritable segments, which limits :l0 veritable data in .EXE programs that are intended for multiple instantiations to 64 Kbytes (16-bit addressing space). When multiple instances of an .EXE program are run, the code can be shared by all instances and the per-instance veritable data, being limited to 64 Kbytes, for each instance has its own, task-specific DS register value by Windows.
To overcome the Windows limitation, the veritable segments in an .EXE program could be disguised, so Windows would load the multiple instances .and share one :?0 copy of the code; and then the techniques described above, of dynaaically creating per-instance veritable segments and swapping base addresses in the LDT, could be applied to achieve larger aaount of writab:le data in an .EXE program. A simpler solution is available, however.
TSE achieves the desired result by transforming the name of an .EXE program that has invoked TSE (presumably becauao it is intended to be run in multiple instances) in the Windows nodule table. The test by which Windows recognizes that a second instance of a program is being run turns out to be case sensitive, while ithe stored name is always upper case. By changing, for example, the case of the first letter of the .EXE prograa's name in the module table, multiple instances may be run. This is done at the cost of some computer memory, however, since each instance will have not only its own copy of the 2lssss~

veritable data, as desired, but also its own copy of the program's code.
The present invention has been described in terms of specific embodiments. The invention, however, is not limited to these specific embodiments. Rather, the scope of the invention is defined by the following claims, and other embodiments are within the scope of the claims. For example, the invention can be used by other languages such as PASCAL to support multi-:instance data.
1.0 Also, the invention can be used to implement thread support on top of an operating system that otherwise does not provide it. Also, what has been described is an embodiment in which per-instance data is loaded into one or more per-instance segments and shared data is loaded into other segments (in particular DGROUP). In a small memory model embodiment, or to have a per-:instance DGROUP, the descriptor base address by the DGROUP is also switched by TSE.
What is claimed is:

Claims (5)

1. A method for providing per-instance data memory in a particular dynamic link library (DLL) loaded in a random access memory (RAM) address space both as part of a first task and as part of a second task loaded in the RAM
address space simultaneously, in a computer having memory management hardware including a local descriptor table (LDT) to map selectors to RAM base addresses, the method comprising:
providing a task switch enhancer DLL (the TSE);
providing in the TSE a DLL registration routine to register a DLL with the TSE when the DLL is loaded;
providing in the particular DLL a call to the DLL
registration routine;
providing in the TSE a task registration routine to register a task with the TSE when the task is started;
providing in the first task and in the second task a call to the task registration routine;
providing in the TSE a routine requesting the operating system to provide the TSE a switching notification whenever execution of any task is about to begin or end and whenever any task is about to cease to exist;
providing in the TSE a segment allocation routine for allocating a memory segment for storing per-instance data of a DLL for a task, which allocated segment is a substitute for an original per-instance data segment for that task, the original segment being referenced through a selector in the particular DLL
referencing an LDT entry, the segment allocation routine maintaining a substitute base address being a base address for the allocated segment in the LDT entry and maintaining an original base address being the original base address of the original segment in the LDT entry;
calling the TSE segment allocation routine for a per-instance data segment of the particular DLL for the first task during initialization of the first task and calling the TSE segment allocation routine for a per-instance data segment of the particular DLL for the second task during initialization of the second task;
providing in the TSE a base address setup routine to store in the LDT entry the substitute base address of a per-instance segment of a task before that task begins execution; and invoking the base address setup routine for the substitute base address for the first task in response to a switching notification received by the TSE that the first task is about to begin execution.

2. The method of claim 1, further comprising:
in response to a switching notification received by the TSE, storing the original base address in the LDT entry for the per-instance segment of the particular DLL when no task linked to the particular DLL is about to begin execution.

3. The method of claim 1, further comprising:
in response to a switching notification received by the TSE, linking the TSE to another TSE
registered task if the TSE is linked to a task that is about to cease to exist.

4. The method of claim 1, where:
the operating system is selected from the group consisting of Microsoft Windows 3.1 and Microsoft Windows 3,11; and the computer is based on a microprocessor compatible with the Intel 80386 microprocessor.

5. In the context of a multitasking operating system providing for the loading of dynamic link libraries (DLLs) in a random access memory (RAM) address space and the linking of a DLL to multiple tasks loaded in the RAM
address space simultaneously, and a computer having memory management hardware including a local descriptor table (LDT) to map selectors to RAM base addresses, a kit for providing per-instance data memory for a particular DLL loaded both as part of a first task and as part of a second task, the kit comprising: a task switch enhancer DLL (the TSE) including a DLL registration routine to register a DLL with the TSE when the DLL is loaded;
a task registration routine to register a task with the TSE when the task is started;
a routine requesting the operating system to provide the TSE a switching notification whenever execution of any task is about to begin or end and whenever any task is about to cease to exist;
a segment allocation routine for allocating a memory segment for storing per-instance data of a DLL
for a task, which allocated segment is a substitute for an original per-instance data segment for that task, the original segment being referenced through a selector in the particular DLL referencing an LDT entry, the segment allocation routine maintaining a substitute base address being a base address for the allocated segment in the LDT entry and maintaining an original base address being the original base address of the original segment in the LDT entry; and a base address setup routine to store in the LDT
entry the substitute base address of a per-instance segment of a task before that task begins execution.