CA2157572C - Method and apparatus for allocating memory to reduce conventional memory requirements - Google Patents
Method and apparatus for allocating memory to reduce conventional memory requirementsInfo
- Publication number
- CA2157572C CA2157572C CA 2157572 CA2157572A CA2157572C CA 2157572 C CA2157572 C CA 2157572C CA 2157572 CA2157572 CA 2157572 CA 2157572 A CA2157572 A CA 2157572A CA 2157572 C CA2157572 C CA 2157572C
- Authority
- CA
- Canada
- Prior art keywords
- memory
- module
- application
- range
- block
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/06—Addressing a physical block of locations, e.g. base addressing, module addressing, memory dedication
- G06F12/0615—Address space extension
- G06F12/0623—Address space extension for memory modules
Abstract
The present invention provides an environment for DOS executable programs or "modules" that are constructed so that they can cooperate with other similarly constructed programs in sharing memory used by portions of their code or data. This reduces the overall requirements of conventional memory (102). The modules include transient code and data (403), that may be swapped out of conventional memory, and global code and data (402) that is not swappable and stays resident in conventional memory. The present invention reduces conventional memory requirements by allowing modules to share a single block of conventional memory for transient code and data. Instead of swapping transient blocks of modules to and from disk storage (204), the transient blocks are swapped between conventional memory and extended (111) or expanded memory (406). This significantly reduces transfer time compared to overlay schemes, improving performance.
Description
~wo s4nosos PCT/USg4/02523 121~7~ 72 M~THOD ~l~D APPAP~TUS FOR MF.l~ORY M~l~AG~
BACKGROUND OF THE PRESENT INVENTION
.
5 1. FIELD OF THE INVENTION
This invention relates generally to the field of computer memory ~y tl~lns and in particular to a nlPntory m~nAgement ~ysl~ln for control and optimi7~tion of computer memory use.
BACKGROUND OF THE PRESENT INVENTION
.
5 1. FIELD OF THE INVENTION
This invention relates generally to the field of computer memory ~y tl~lns and in particular to a nlPntory m~nAgement ~ysl~ln for control and optimi7~tion of computer memory use.
2. BACKGROUND ART
A typical computer ~yslell~ consists of a number of modules or compo~ents. Computer ~y~Lellls typically include a central proresrin~ unit 15 (CPU) such as a microprocessor. The microprocessor is a program-controlled device that obtains, decodes and executes instrll~hoI ~.. A computer ~tyslelll also includes storage components for storing sy~ lll operating software, appli~Ation program instrllctionc and data. These storage components may be read only memory (ROM), rAn~lom access memc-ry (RAM), or mass storage such as disk 20 or tape storage, or any other suitable storage meAn...
The operation of a computer ~y .L~ is controlled by a series of instructions known as the "operating sysl~ ". The operating sy .Lell- iS used tocontrol basic fllnctions of the computer ~.yslelll, such as input/output, and is25 typically stored in a permAn~nt storage element such as a ROM or disk storagewhich is then lo~le(l and run in RAM. Examples of operating sy~ lns include M~DOS or PC-DOS. Computer .ysl~ S are used to execute application programs.
2~5~S -2- PCT/US94/02 During some proc~ssin~ operations, the CPU may also require the storage of data temporarily while instructions are executed on that data. In ~d~litiol, the applic~tion program that controls the pro~r~csin~ and the o~eIaLl.g ~yslelll under which the program runs mus`t be ~ccessihle to the CPU.
5 This inform~tion is made available to the CPU~by storing it in RAM, a resource known as "main m~mory".
The m.~mory co~.~ollent known as main memory is a scarce resource that is dr~mic~lly ~ c~te~l to users, data, ~roglaLns or ~rorecs~s. Memory 10 users competing for this scarce resource include applicA~ion programs, TSR's ("terminate and stay rPcitl~nt" programs) and other processes. Fy~mples of applic~ffon programs in~ lde word processors, spreadsheets, drawing programs, rl~t~h~2p~;~ etc. Certain applic~tion programs may be stored in ROM.
Generally, ho~vevel, app!ic~tion programs are stored on a mass storage device, 15 such as a disk drive. Upon initi~li7~tion, applic~tion progr. ms that are to be execllt~-l by ~e CPU are transferred from mass storage to RAM.
TSR's are also used on computer ~y~ llLS. Such programs provide "hot keys" and "pop-up windows" and . re used to ~ background tasks, such 20 as displaying a clock in the corner of the video display or mor itoring disk drive activity. TSR's have been written for many other appli~hons, . nd users often desire to have several TSR's r~cicl~nt on their computers simlllPneously. Since each TSR requires memory space in which it is located, Acl~lin~ TSR~s to the ~.y~.L~ll also increases memory rlem~nd on main m~mory-.
Main memory is typically a silicon-based memQry such as a RAM.
Alternatively, dynamic r~n~om access memory (DRAM) is used as the main m~mory. Main memory RAM can be .~cc~ssed as conventional memory, exton~le~l memory- and exp.~nde-l memory-~
~wo 94/2090s 2 1 5 7 5 72 PCT/US94l02523 Conventional Memory Cc,llv~.liorlAl mPmory is a region of RAM that is most easily AccPcsell by 5 the CPU. It is desirable to have data and instrl1~ionC nee-le-l by the CPU to be stored in convPntioIlAl memory. However, there are limits on the size of convPntionAl mPmory that limit the amount of data and instructions that can be stored in conventional memory.
Early microcomputers had 16-bit address buses, which provide 64K of address space. As the amount of mPmory required by appli- Atiorlc ineased, microcomputers had to ov~collle the limitAho~s of a 1~bit address bus. Thus, the IBM Personal Computer was intro~ erl with a segm~rltPrl addressing st~hPme which su~olled a 20-bit address bus. A 20-bit address bus provides 15 1024K, or lM, of address space, which is 16 times that of a 16-bit bus. The original IBM PC and ~ty~.l~ll soflw.l e was l1Pcigne~l with an artificial limit for convPntion~l mPmory of 640K. The 384K of address space from 640K to lM
was reserved for future use, primarily for ROM's. Since subsequent models of computers have been ~lp~cigmp~l to be backwards-comp~hble with the ori~in~l 20 IBM PC and to use the same PC-DOS M~DOS operating ~y~ , the 640K limit on convpntiorl~l memory continues to constrain the amount of memQry available to applic~hoTIc on modern computers.
wo g412~5 2 1 5 ~ 5 7 2 ~CTnUS94/02323 E~cten~P~ Memory F~ten~le-l mPmory is RAM great~:r than 1024 Kbytes that can be directly addressed by microprocessors witlh sl~ffiriPnt nurnbers of address lines. For 5 example the Intel 80286 microprocessor has a 2i bit addressing capability and can address 15M of e)~tPncle-l m~rnory above the first IM of m~mory. Intel 80386 and 80486 microprocessors have 32 bit addres~ g capability and can address appro~im~ly 4 Gigabytes of P~cten-le-l memory above the first lM of memory.
Expanded Memory E~cp~n-led mPmory, also known as "expanded memory sperifir~tionll (EMS) resel.~es a portion of ~t~n~lP~i memory, which is not dilecLly ~ccPcsihle,15 for use as P~nd~P~l mPmory and divides it into pages. By switrhing the exp~n-lef~ mPmory one page at a time into the address spaoe which is directly ~rc~PssihhP by the CPU, EMS is able to acoess a virtually lmlimiterl amount of memr~ry. However, EMS takes time to change pages. Lf the desired data is not in the EMS page frame lor~te-l in direclly ~c~Pccihle mPmory, liMS must page 20 out the current r~Iltpntc of the page frame and page in d e page from expanded mpmory which coT~t~ins the desired data. Since such a page ~h~n~e requires time, the procPcsing speed of the computer is reduced. Also, EMS is not generally applicable to all applir~tion software. Appli~ ~tion software must be written specifir~lly to take advantage of EMS if it is avAil~hle ~wo 94/2090s 2 1 5 7 5 7 2 PCT/US94/02523 Memory Map Figure 1 illustrates a mpmory map of main memory RAM on a typical computer, namely, a computer based on the 8088/8086 family of 5 microprocessors and operating under MS-DOS, such as an IBM Personal Computer. The memory map of Figure 1 is not the only possible menlQry map, but is an example of a typical mPmory map. The mPnlory map is org~ni7etl from the bollom up, with memQry location æro (101) at the bottom, continuing through the highest location in mPmory at the top. The mPmQry 10 map has three basic areas. The first area in~ lPc the lowest 640K of mPmc ry and is rere~ed to as convPntiort~l mPmory 102. ConvPntion~l mpmc)ry 102 consists entirely of RAM, which allows both read and write operations, although not all ~yslellls include the entire 640K, and some nlPmory space may be left lnt1cP l ConvPntioT-~l mPmory 102 is used to store ~ysleln software, applir~tion software, user data and other code and data, including TSR's and device dlivels. As illustrated in Figure 1, MS-DOS uses the lowest portion of memc)ry to store its own code 106 and ACSo~i~tp~l data 107. Above that, MS-DOS stores applirAffon sofl~vare, TSR's and device drivers, rollectively illustrated as 20 Pl~PmPnt 112.
Above collv~ ioT~l mPmc)ry is the 384K of reserved memQry 103, which lies in the mPm~ ry addresses above the 640K RAM limit and 1024K.
The reserved memory area 103 is occupied mainly by ROM's, which are read 25 only devioes. The ROM's found in the reserved mPmory area indude the wo 94/20sos ~ us94l02s23 ~y~leln ROM, video ROM and perhaps ROM for o~er peripheral devices, such as hard disk drives or network interfaces. In ~ lition to ROM's, the reserved m~mory area 103 also includes other types of speriAli7ell mPmory, e.g. video frame buffers.
System ROM, which supports the basiç o~elalions of the computer, typically occupies, for example, the highe~ 64K of the reserved mPmory area 103 from 960K to 1024K. The rem~ining space in the reserved memory area 103 is either llnllce-l or used for other purposes, in~ lin~ ROM's which 10 ~,u~olL other peripheral devices or an EMS page frame.
As noted above, PYtpn~lp~l mPmclry 111 includes all memory above lM.
Microprocessol, with a 24-bit ad~es ,ing capability, such as the 80286, c,m address up to 16M of mPmory, including 15M of ~t~n~lell memory 111 in 15 ~ ition to the lM of reserved m,~mory 103 and coll~e~lior~l mpmory 102.
Mi-:lo~,roc~sors which have a 32-bit ad~es~ g capability, such as the 80386 and 80486, can address up to 4G of memory~ which includes 4095M of exten~lP-memory 111 in AC~ tion to the lM of reserved memory 103 and col.v.-~ltio mPmr~ry 102. The area of P~ct~ e~l m~mory 111, located just above lM, is 20 sometim~c referred to as the high memQry area 113.
As TSR's proliferate, and as applir~tiorl programs become larger, the competition for space in conventional mPmory increases. It is desirable to provide more conv~ntiorl~l memory for applir~tion programs while 25 preserving the ability to use TSR's.
The amount of convention~l memory space available for applir~tioIl programs can be increased by reducing the amount of mPmory used by TSR's, ~wo 94/2090s 2 1 5 7 S 7 PCT/US94/02523 reducing the number of TSR's, or by rPlorAting TSR's to m-omory outside of conventional memory.
Reducing the number of TSR's is not desired because it can result in 5 reduced functionality or ~ Ance~ Reducing the amount of convPntionAl memory used by each TSR is not practical because it requires rewriting each TSR.
Since TSR's occupy some of the convPntiorlAl memory space which 10 could otherwise be used by applicAtion software, more mPmory would be available for applicAtionc software if these programs could be moved to mPmory outside of convPntionAl mPmory 102. One prior art met?lo~l increases the amount of convPntionAl memory 102 available for applirAtion software by moving TSR's from co~ tirJnAl mPmory 102 to reserved memory 103.
To implement this method, the amount of unused reserved memory 103 must first be determine~l Also, the amount of conventirnAl mPmory occupied by TSR's must be determine~l- Then, a s~lffirient amount of unallocated RAM from extPnrle~ memory must be mapped into the reserved 20 memory area to provide mPmQry space for the TSR's. Next, the TSR's are rPlorAtP-7 to the available mPmory in the reserved memory area 103.
This prior art method has disadvantages. First it, can use only unallocated reserved m-omory space. It cannot use reserved mPmory space that 25 has been AllorAte~l to ROM's, video frame buffers, or other uses. Also, the relocation of TSR's must be done to ensure that all le~elences to them are redirected to their new lorAtion.s wo 94/20905 Pcr/uss4/02s23 21S75~2 ~
Another prior art method for relc-rAt~ng from conventiorlAl mPmory is known as an "overlay". Overlays are e~ecllt~hle portions of programs that are swapped in and out of memory as ~eecl~fl Over~ys have the disadvantage of requiring the program using the overlays to be linked with an overlay 5 mAn~ger that controls access to the fllnchor c and data that are located in the overlays.
An example of the overlay scheme is illustrated in Figures 2A and 2B.
Referring first to Figure 2A, the first 1024 bytes of RAM that are Accessihle by10 the CPU are shown as mPmory block 201. ~PmOry block 201 in~ ld~pc a region of convPntion~l mpmory 102. Conventior~Al mem-ory 102 includes region 202 at the lower addresses for storing o~dlillg sy~lell- code, such as DOS. The rPmAindPr 112 of convPntio~l rnPmory 102 above the DOS region 202 and below leselved memory 103 is used for storing applil~hon~, TSR's, device 15 driv~s, etc.
Some applirAtior-.c are too large to be stored entirely in convPntioI Al mPmory region 112. One example of such an applic~ti-~n is Word Perfect, a word proressing app!i~Atio~ There~ore, only a portion of Word Perfect ~s 20 stored in mern~ry region 112 at any one time. The remAining portions are stored in other nlPmory~ such as disk storage 204. As portions of the application are r~eP~l~P~l~ they are transferred from disk storage 204 to mPmoryregion 112.
25In the example of Figure 2A, a portion of the application reprP~Pntef~ by block A 203 is stored in memory region 112. The applirAtion is divided into ~wo s4/2090s 2 1 5 7 5 7 2 PCT/US94/02523 two other portions, block B 205 and block C 206, that are stored in disk storage204. Disk storage 204 is coupled to RAM 201 through a bus or other trAncmi~sion means 207.
When the f 1nctiorlAlity contained in block A 203 is being called or used, block A 203 rPmAin~ rPsi-lPnt in memQry region 112. When other filn~honAlity is required, the code providing that ftmctionAlity must be transferred from the disk storage 204 to the memory 201. Referring now to Figure 2B, block B 205 is transferred from disk storage 204 to mPmory region 112. Accordillgly, the applicAhon portion block A 203 previously r~ci~ing in mPmory region 112 is transferred to disk storage 204. Block B 205 is shown graphically as taking up more of memnry region 112 than did block A 203. The blocks need not be the same size, but must be as small as the available address space in mpmory region 112.
A disadvantage of overlays is that they are sv~ ed to and from a disk file, increasing exectlhQn time and rerlllcing y~r~ lAnce~ Certain programs require some code or data to always be rPsi~lPnt in col~ ,tionAl ~nPmory.
Overlays do not provide any Tlletho~l of idellli~yillg code or data that permAnPntly resides in convPnhor~Al memory. When blocks A 203 and B 205 are swapped, they are ~w~yed in ~ eLy. No portion of block A 203 rPmAins in mPmory region 112. The.efore, such programs cannot use the overlay schPme. Some TSR's cannot be converted to overlays. These TSR's include those that provide internal DOS fllnctionAlity. One example of this is 25 NetWare DOS Client sofl-w~e produced by Novell, Inc. of Provo, Utah.
Thus, the prior art does not provide a ~y~L~l~l for reducing the arnount of convPnhoItAl memory used by TSR's without sacrificing performAnce WO 9412090s PCT/US94102523 215~572 ~
SUMMARY OF THE PRESENT INVENTION
The present invention provides DOS execllt~hle programs that are constructed so that they can coo~laLe with other similarly constructed 5 programs in sharing m-pmory used by portions of their code or data. This reduces the overall requirements of conv~fitioI Al mpmory. In the present inveT-hon, these programs are referred to as modules and can be application programs, TSR's or any other P~ec-lt~hle file which are collveLled into this module format. The modules include tr~nciPnt code and data that may be 10 swapped out of collv.~ ioIl~l mPmory, and global code and data that is not ~wdl,~able and stays resi~lPnt in convPnfforl~l mpmory.
By providing global data blocks that remain resi-lPnt in m~Pmory, modules of the present invention can call other modules, as well as interrupt 15 h~nAlPrs and other code or data that is externally or asynchronously available.
The present invention thus Sll~Ol~S more progr~mming interfaces than overlays.
The present invention re~ ces convention~l memory requir~ment~ by 20 allowing mr~ les to share a single block of convention~l memory. Regardless of the number of modules, the size of the block of convPntion~l memory allocated for their use r~mAins the same. The mPmory block ~ is of a size large enough to store the largest block of tr~n~ipnt code or data of the modules that share the convPntion~l memory block.
Tnstp~ of swapping transient blocks of modules to and from disk storage, the tr~n~iel t blocks are swapped between col~v~ ;on~l memory and extenfl~l or expanded m.~mory. This si~nific~ntly reduces transfer time comp~red to overlay ~rhemes, improving ~lfo~ nce ~WO 94/20905 2 1 5 7 5 7 2 PCT/US94102523 BRIEF DESCRIPIION OF THE DRAWINGS
Figure 1 is a nlPmory map illustrating the mPmory org~ni7~ion of a typical computer ~ysLe~
Figures 2A and 2B illustrate a prior art overlay s~eme.
Figure 3 illustrates the module structure of the present invenho Figure 4A - 4E illustrate ~t:lalion of the m~mory m~n~ger.
Figure 5 is a flow diagram illustrating the pre-init operation of the invention.
Figure 6 is a flow diagram illustrating the real-init ~aLion of the invention.
Figure 7 is a flow diagram illustrating the calling of a module in the invention.
Figure 8 is a block diagram of a computer ~ySl~lll for implPmPnhng the invention.
Figure 9 illusliales a VMCB data block.
W0941~905 21575~2 PCr/US94102523 DETAILED DES~ lON OF THE PRESENT ~VENTION
A methoA for providing more PfhriPnt use of convPntion~l ~nemory in a computer ~y~lel-l is described. In the following flPsrription~ numerous 5 specific details, such as type of computer ~y~leln, memory address lor~tion~, amounts of mPmory, etc., are described in detail in order to provide a more thorough description of the present invPnhon- It will be apparent, however, to one skilled in the art, that the present invention may be pr~cticeA without these specific ~lPt~ . In other instances, well-known features have not been 10 described in detail so as not to llnneces5~rily obscure the present invPntion-The present invention reduces col~ .lhor~l mPmory requir~mPnt~ byproviding a method and apparatus for TSR's and other programs to share space in convPnhi(!n~l memQry. The TSR's and programs are configured as 15 "modules" and a module m~na~er controls the swapping of modules into and out of convPntion~l memory. In the ~rer~lled emboAiment of the i~ .,Rorl, only one module is resiflPnt in convpntion~l nnPm~ry at any one time. The other modules are stored in e~cten~lp~l mPmory or exp~n~leA m~mory. This avoids time consuming and ~.ro~ nce reAI-ring disk swaps.
The c~lalion of the module m~n~r is illustrated in Figures 4A-4E.
Figure 4A illustrates a memory map of convpnhon~l~ reserved, exten~leA and exp~ndeA mpmory. ConventioTl~l memory 102 includes DOS storage region 202 at the lower mPmory area. Just above the DOS region 202 in the 25 cc,llv~ltion memory 102 is space reserved for the module m~n~ger 401. Above the module m~n~ger 401 is a region resel ved for global code and data of any modules available to the ~ysleln. Stored above the global code and data region 402 is a region reserved for tr~n~iPnt blocks of the modules. The tr~n~i~nt ~wo g4120gO5 2 1 5 7 5 7 2 PCT/US94/02523 block module 403 has an upper boundary 404 which is fixed and determined by the largest trAn.cient block of any module in the ~y~ . The space in coll-v.~..tionAl mPmory 102 above upper boundary 404 and below reserve mPmc-ry 103 is available for other applicAh~rlc and proc~csPs.
Reserve mPmory 103 is used for ROMs and for expanded memory 406.
Above reserved memory 103 is P~tPn-le~ m-omory 111 (above 1024 Kbytes). The extPn~lerl mPmory 111 stores the tr~nci~ont block 405 of a module re~elled to asmodule A. The e~n~le~ mPmory 406 indudes the trAnciPnt blocks 407 and 10 408 of modules referred to as modules B and C, r~ectively.
After the global code and data have been stored in global region 402 and the upper bound 404 of trAnCipnt block 403 has been ~fille~l~ the mo~ 1e mAna~er is ready to access modules as they are called. Referring to Figure 4B, 15 conci-ler the case where module B is requested. Module B may inr~ e code perm~nPntly resil1Pnt in the global region 402. When morlllle B is called, the module m~n~Pr transfers the module B tr~ncipnt block 407 from expanded memory 406 into the trAnci~nt block 403 of convpntio~Al mPmory 102. Any tr~nciPnt block of other modules is ~vvd~ed out of co~l-vr.ltion~l memory at 20 this time. The ~locess calling module B then can access it as if InorllllP B were always resirlPnt in conventiQr-Al m~mory. As seen in Figure 4B, the trAnciPnt block 407 of module B does not use all of the available address space in tr~n.cierlt block 403. However, the upper bound 404 of tr~nsient block 403 remAinc fixed.
Figures 4C-4E illustrate the process of a module calling another module.
The trAncient block 408 of module C is resitl~nt in tr-Ancipnt block 403 of collv~..hollAl mPmory 102 as illustrated in Pigure 4C. Module C calls module wo 94/20905 Pcrlus94l02 21~j75~2 -14-A through the module m~nsger. The module nSAn~ger keeps track of the calling module and the destination module. The transient block 408 of module C is swapped with the tr~n~iPnt block 405 of module A. Referring to Figure 4D, the trrsn~ipnt block 405 of module ~ is now stored in the trAn~iPnt 5 block 403. Note that the transient blo~k 405 of module A occupies all the address space of tr~n.ciPnt block 403. After module A execlltes the f -ncfi~n for which it was called, the module m~n~ger swaps the tr~sn~iPnt block 405 of module A with the tr~n~iPnt blocl~ 408 of module C, as illustrated in Figure 4E.
10 Module Structure In the present invPn~ion, code and data of modules are structured into different r~le~ ies so that a general soll~*nn is provided for m~n~geInent of the mo~ p~ in convPn*Qn~l mPmory. These categories indude a f~lnctiQn 15 licp~tcls table (jump table), trAnCient code and data, global code and data, and start-up code and data. The format of a module is illustrated in Figure 3.
The structure of the morlllle 301 inrl~ c three regions 302, 303 and 304.
Region 302 inrlllflPs a jump table 305 and a tr~n~jPnt group 306. Region 303 20 colst~ins global code and data and region 304 includes start-up code and data.
The tr~ncipnt region 302 in~ d~ code and data that is "swappable." That is, this data can be sw~ed in and out beLvve~lL col~ hols~l m~mory and PnhAnCe~ mPmory (P~tende~l or exp~n~Pd).
~57~ 72 ~wo 94l2090s ~ Pcrrusg4/02s23 ~UMP TABLE
The jump table 306 represents fllnctiorl.~ s~yyolled by the module. The jump table (also rer~led to as tr~n~iPnt code) can be ~wd~ed out at any time.
5 Theierc,le interrupt h~n-llPrs (or any code se~mPnt which can be directly ~ccPsse-l) cannot exist in the transient code se~mPnt The first enhy in the jump table is the pointer to the module init routine. The jump table 306 consists of yoilllels to at least four prellPfine(1 functions which are conlmor to all modules, namely, init, lmlo~-l, version, and statistics.
Init: Init is an initiAli7~tiQn routine in the moAllle This initi~li7~tion routine ~elrollns pr~init to obtain the nerPss~ry par~mePrs for inih~li7in~ a module and then ~elroll~s a real-init to ~ctll~lly load the module into the ay~r~l;ate sef~ment- It is within this real-init process that veclo~s are hooked.
Unload: The lm1O~1 filnrtion f~rilit~p~ release of resources. The nln~i request can be failed if a check for lmlo~l safety (CX = FE~Fh) returns a critical section status. If a mcl~ltlle is well behaved, then there is no reason to fail and a check for tlnlo~ safety returns a zero, in~ tin~ that it is safe to 20 llnlo~l for real. A request to lmlo~l for real cannot be failed. If a module fails the lmlo~l check, then all modules previously ~ ke~l are notified with an -nlo~1 cancel (i.e., CX = ~ ;h).
Version: The version fllnction obtains the major and minor version of 25 the module. This fimchion provides f )mmon~lity between modules. Other subfilnctions of this version filnctioIl also establish commor ~lity between wo 94l20905 Pcrlus94l02~
215757~ -16 modules. The other subfunctions (Olh-OBh) also h~iliPte inter-module communication (multi-casting) regarding connechon establichmPnt, ~liccorlnechorl, etc.
-For example, there is a multi-cast call at the first task termin~te (i.e., _Notify ~n~ r subfunction 01h,PSP Termin~te). This subfilnctioI is part of the pre-lPhn~-l general fllnction Statistics: The sPhctir~ filnction obtains statistics for the mo~ le This 10 fllnchon is optional. The statistics are for module debllg~ing. The statistics structure is a length-prece~ l buffer; the first word of the statistics structure table in~ir~tes the number of bytes of valid statistics i~ ti~n All other sPhcti~ i..rO....~tic!n needs to be recorded between the stat size and the stat end fieldc.
Other filnchonc can be provided specific to the n~o~l~llP and follow these pre.~ hnerl fimctiortc. The t~rmin~tin~ zero (DD0) follows the common fllnctioJI.c and all other fllnctionc rlefine~l by the module in the jump table.This lets the module m~n~r know how many fllnc~ionc are supported by the 20 module so that requests beyond this number can be ~l~nierl TRANSIENT DATA
Tr~ncient data, like tr~nci~nt code, has specific requir~m~n~c. Certain 25 types of data cannot exist in the tr~nciPnt group. These restricte(l types in~ e stacks and data which is p~Csecl to another module. ~or performance reasons, all data that is not global should be in this tr~n~ient data segmPnt- Tr~nciPnt data is swapped between ~nh~ncerl memory and convPnho~l memory.
~wo g4/20905 21 5 75 7~ PCT/US94/02~23 GLOBAL CODE AND DATA
The global region 303 stores code and data that must remain rPsiAPnt in 5 convPnho~l memory. For example, code and data that may be stored in the global region 303 include interrupt h~nAlers for global code, far call h~"AlPrs not ~ccPcsed through the moAlllP mAn~gPr, stacks, and data passed to other modules. It is possible to create a module with no mPn~ory in the global region.
STARTUP REGION
The startup region includes the inih~li7~hon code. The code provides pre-init and real-init o~alions. During pre-init, each moAllle provides a 15 module m~n~ger with a VMCB structure data block. The modules use the init routine to report the amount of initi~li7~hion mPmory required (including global and tr~n~iPnt m~Pmory ~egm~Pntc) through this VMCB structure.
Sperifi~Ally, the VMCB_TnitTm~gPparaLength par~nnet~Pr ~fines the preload total size.
The module m~n~ger uses VMCB_InitImageParaLength to determine how much m~mory to swap in and out during real init and run time. This method of deterrnining mofl~ m-omory ~llor~tioIl avoids confusion and simplifies the process of keeping m~mory segment~ separate. Keeping 25 m~mory se~nent~ s~araLe is use~ful when rllnning global and protected mode data segrn~nt~ simllltAneously. If the mo~lllP is dep~nflPnt on other modules being lo~le-l, the dep~ntlency for the module is ~erke~ during the pre-init stage. The fake init flag (AX = -1) is passed on the way into this procedure.
wo 94l2090S PCT/US94/0Z523 215~5~2 -18-During real-init, the module is required to move the global code/data from its lo~flP-l lor~tion The destin~tion of this group is rl~fine(l in the BX
register when thc morlllle m~nAger calls the l~it f-inction on a real init. After 5 this process, the module must execllte any fixups nece~siPtel1 by the moving of the global group. These fixups are performed to ensure that the data is ler~ cing the new location rather than the group k~lerl by DOS.
MODULE MANAGER
Overseeing the individual mo~ les and multiplexors is the module m~n~Pr. Appli-~tionc make all calls to the mo~lllle ~n~n~gPr, which directs requests to their ~.o~er destin~honc~ whether that be another module (child) or multiplexor. the module m~n~ger also ensures that replies return to their 15 a~.~.iate callers.
Every moAllle calls other modules via the module m~n~ger. Even when a module is calling its particular layer's multiplexor, it makes that call to the module m~n~ger~ which then calls the particular multiplexor. Likewise, 20 when a call returns from a particular mo~lllle~ that call makes its way from the multiplexor to the particular TnorllllP via the module m~n~ger.
One responsibility of the module m~n~ger is ensuring that API calls between the other pieces are ~ ~ly routed. The module mAn~ger must 25 there~ole know if the modules required by a given user applic~tion have lo~-lPrl It polices modules that call other modules. The module m~n~ger h~ncllP~ modules and fllncfion~ that are called asynchronously as well.
~wo 94/20so~ 2 1 5 7 5 7 2 K~TIUS94/02523 The module m~n~ger provides the APIs to call a function and a module by number. ~he module m~n~ger also knows who is calling that fimction, via the caller's module ID. Module IDs are pre-A~si~erl Because the module m~nager h~n~lles all APIs on a number basis, the module m~n~ger has no 5 intrin~ic depen~lenries or ties to the individual f~nctiorl~ in the modules.
~'orl~equently, modules that are not part of the specific Requester model can use the module m~n.~cr as a TSR memory m~n~ger. This is what gives the module m~n~ger the c~pAbility of supporting varied and diverse TSRs.
The mo~ le mAn~ger provides the basic services that all modules require, especially those allowing and f~rilit~ting calls between all lo~
modules. Th~l. rore, the module m~n~ger encoTnp,~ses all layers of the Requester model.
The module m~nAger not only loads and lmlo~lc each module, inr~ ing multiplexors, it also h~n~ s mPmory services (allocation and m~nA~m~nt) for all mo~ . The mo~ e m~n~ger employs memory swapping for its modules.
The module m~n~ger ~1r~r~ s whether a given mo~ e uses e~n~1e-1 m-omory, extPnfle~l memory~ conv~ntion~l nl~mory~ or any memory type su~olled~ without affecting the modules tllemcPlves. The individual child modules are therefole freed from these m~mory concerns.
-Child modules must still conform to certain requiremPntc for memory usage. Once they have done so, they gain all the advantages of having the module manager h~n~lle m~mory merll~ni~m~ for them.
w0 94/2090s Pcr/us94l02s23 ~
'' 215rlS~2 The module m~n~ger is also responsible for 10~-7time-configuration APIs. Any module may be configurable. For instance, the cor~nection table wants a certain number of co lnecti<~ns, or IPX wants to support a number of ECBs, or bigger or sm~ r buffers. In these instances, the module m~n~ger 5 does the work for the module. ~
~ of7ihior7~11y, a user may want to load a module in non-swapped m~mory~ regard ess of the memory type being used, in order to optimize perform~nce. Ideally, optimal configuration vari~tions are ~.7ministered by 10 the modu e m~nager. An API is provided for mo~7l71~s that may desire this capability.
RerAIlce the n~o~711le m~n~Pr cdnnot be aware of all possible configuration perml1Pho~s, the Requester includes an API wherein a module 15 can specify its own configuration options, int 1tlo7ing the tokens used to eco~,~,ize those options. This is a table-driven API that can be called at sldr of a moflt11e to parse configuration inform~hon from the NET.CFG file.
When the module m~n~er loads, it reads from a file, within the 20 current or other-sperifiell directory, what modules it should load. The module m~n~?r loads those modules in ~he file-specified order.
~WO 94/20905 - 21 - PCT/US94/02523 When lo~llin~ modules, the current dilecLol~ is used by default. If you want to load modules from a different directory, you can ~l~si~n~te the directory in the mo~llle = commAn-l in the configuration file. For example:
5 VLM = C:\NWCLIENT\CONN.VLM
You can also specify a path for the configuration file on the morllllP
romm~n~ line. For example:
10 VLM /C=C:\NWCLIENT\NET.CFG
A default set of modules is hard-coded into the module m~n~er for basic filnction~lity. Ho~vevel, NET.CPG can be used to override the ~lPf~t~lt options.
C~llin~ the Module Manager To find the address for the motlllle m~n~er far call hAnr~l~r, the applir~hon makes an i~ yL 2Ph with 7A20h in the AXregister and BX = Oh.
20 The module m~na~er returns an address in ES:BX that is a pointer to the far call address (the moflllle m~n~Pr). AX is æroed out to let the applirAhon know the module m~n~er h~n~lle~l the call.
Call-By-Number System:
The module m~n~er uses a call-by-number ~yslelll which uniquely i~lPntifi.os modules in the ~yslt:~n. Fllnchon~ are also called by number. This protocol requires that appli~hQns provide three essential pieces of W094/2090~ ~CTrus94lo2s23 21S75~2 informAho~l to the nlo~ le m~n~er, including CALLER_ID, DEST_ID, and DEST_FUNC. Each of these three numbers is of size WORD.
CALLER_ID and DEST_ID are nOmbers which uniquely identify a 5 particular module. The module mAnAgPr uses these nllmkers to swap in the proper module and dispatch the call a~lu~liately.
DEST_FUNC in~lirAt~s what f~lnction the caller wants to ~e~
DestinAtion filnction~ are rlefin~rl within the individual module. These 10 fllnctionc are rl~hined by the mo ~ ec jump table region 305.
These three required Plpmer~tc work together on every filnctiorl call mAnAgP~l by this sy:.Lwll. When an appli~-~tion makes a module call, a far call address for the module mAnAger mus~ be obtained. The following code is an 15 example of how an applil~Atiorl retrieves the far call address.
data s~..~
vlmCallAddress dword 0 data ends oode se~
o mov ax, 7A20h mov bx, 0 int 2Fh or ax, ax 1nZ NO VLM
mov word pk vlmCallAddress, bx mov word ptr vlmCalL~ddress + 2, ES
o NO_VLM: .
o o aode ends ~WO 94/2090S 2 1 5 7 5 7 2 PCT/US94/02523 The following code is an example of a non-module application using the far call address to make a request of _VLM Notify to rehurn the version of the module m~n~ger module.
5 mov ax,0 push ax ; CALLER_ID
mov ax, VLM_ID_VLM ;(Olh) push ax ; DEST_ID
n~v ax, VLM_NOTIFY ;(Olh) 10 push ax ; DEST_FUNC
mov bx, 0 ; GET VERSION SUB-FUNC
call VLMCallAddress In sl~mm~ry, the caller first pushes its own ID on the stack.
(CALLER_IDs are non-zero for modules and 0 for applir~ffQr c.) Then, the caller pushes the desffn~hon ID--sperihr~lly, the ID of the multiplexor module or of the specific child mo~ le it wants to call. Finally, the caller pushes thedesired filnchon n-lmh~r.
There are two reserved (or ~y~ -only) fi~nchonc~ nchnn zero and f lncfirn two, used for iniff~li7~ffQn and lmlo~ e~e~ively. Fllnchonc one and three are also used consisl~tly across the various modules. One and three are used for a generic notify hlnchcn with multiple subhmr~ions and 25 module statistics l~s~eclively.
On return, the module m~n~er dears the CALLER_ID, DEST_ID and DEST_Fl~C from the stack, so an applir~ffon must not do so. This is coInmoI~ly ~e~--ed to as the Pascal calling conv~ntion.
wog412090s 2~.Sl~rl2 Pcr/us94lo2s23 Two registers are used by the module m~nAger: AX and BP. BP is for internal use by the module m~n~ger only. Applications should not use BP for any parameter request. BP may be used only to push on the stack the three required values. Applic~horl~ should use AX for return codes only.
The module m~n~er also provides a method for h~n~3lin~
asynchronous calls. The calling fimrtion provides a pointer to a block of memory that includes the destinAtion ID, destin~tior~ function, caller ID, and also any registers that need to be set up for the call. The request can then be put 10 on hold and PYectltP~l at a later time. When the module m~nAger determines that it can't PYPCllte code that is n~PP~l~Prl, the module mAnA~Pr can put off the e~eclltion of the code. The caller of the ftlnction can receive control back before the f~mchon is actually completed.
15 Module Manager Pr~Init A flow diagram of the pre-init operation of the present i~l~,ention is illustrated in Figure 5. At step 501, the mor~ e m~na~r configures itself (NET.CPG, and VLM = files). The configuration could include a list of new or 20 ~ itior~l modules. The module mAnAger then loads each module on the current list one at a time at step 502. The module is lo~ using the load overlay API at step 503. The initi~li7Ation filnction is called with the "hke-init" flag on (in(1irAting pre-init) at step 504. The module being lo~ier7 provides to the module mArl~er a VMCB data block at step 505. At step 506, 25 the module m~n~er reads the mpmory requirement~ of the module, i.e. the inih~ tion ml~mory re~ .ents, any global memQry requir~menh, and tr~ncient memory requir~m~nt~.
~WO 94/20905 2 1 5 7 5 7 2 PCT/US94/07523 At step 507, the module mAnAger stores the parAmeters for the module in a module parameter table. The parAmetPrs include initiAli7Ati~n memory requirPment~, global nnPmory requirPmPnt~ (if any), trAnCient memory requirPmPnt~, and the number of fimchon~ of the module.
The module mAnAger proceeds to rle~i~ion block 508. At ~leri~ion block 508 the argument "last module?" is made. If the argument is false, there is more module mPmory informAtion to be obtained and the module mAnAger returns to step 505. If the argument at ~1P~ on block 508 is true, the memory 10 re~lui~ .Pntc of all modules have been obtained and the module mAnAger proceeds to step 509.
At step 509 the mo~llle mAnAger collectc the data from the module par~metPr table to determine the mPmory rlee~le~ for global data. The module 15 mAnA~er then All~AtPs address space in cc,~ ..tionAl mPmory for storing the global dat~.
At step 510, the module mAnAgPr i~lPntifips the largest trAnciPnt mPmory requirement of the mo~ lPs that have are to be loAde-l The size of the largest 20 trAncipnt block ~lpfinps the size of the t~rAncjerlt block 403 in convPTltior Al memory. At step 510, the mo~ mAnAger AllocAt~Ps RAM for the trAnCipnt mPmory block of a size at least as large as the largest block of the modules to be loAdPcl At step 511, the module m~nAger delellllilles what address space can be used for storing the trAn~ipnt blocks of each module. The order of ~ier~l~l,ce is first extended memory, then expanded memory, then convPntionAl mPmory.
The user can configure the module mAnAger to use one type of memory in wo 94/20905 Pcr/uss4/02s23 2157~72 -26-particular. The module m~n~ger determines at step 512 if one type of mPmory is enabled for use. If a type of mPmory is not enabled, the module m~n~ger selects a mPmory type using the aÇor~ PntiomP~7l heuristic.
An example of a VMCB data block is illustrated in Figure 9.
Module MaI ~er Real-Init After the pre-init routine, the ~no~'l-lPc are lo~- P~ again with the fake-init flag not set, so that the real-init routine is PYec~te-'. The operation of the real-init routine is illustrated in Pigure 6. At step 601, the morlt71P m~n~gPr sets the fake-init flag to zero. At step 602, the first modu,e is lo~f Prl At step 603, the initi~li7~tion routine is called. At step 604, any interrupt veclu~ for15 the module are hoo~cef7 At step 605, any other resources of the modu'es are pllor~tPrl At step 606, global code and data is moved to the ~1lorAtPr3 address space. At step 607, the tr~nCipnt block of the mof7l~le is copied into the address space ~ t~Pr~ for that mo~ l-le's tr~n~ipnt block (in e~ctPnflPf, exp~nf r~, or col~v~--Ron~l nl~mory). At rlPri~ion block 608 the argument "last mofllllP?" is 20 made. If the argument is true, the rea'.-init procedure e~ds at step 609, where the module m~n~Pr termin~tes and stays rP~ Pnt- If the argument at rlPri~ n block 608 is false, the system returns to step 602.
Module Loading A flow diagram illustrating module lo~ling is illustrated in Figure 7. At step 701 the module m~n~ger receives a call to access a module. At rleri~ion block 702, the argument "other request being serviced?" is made. If the ~wos4nosos ~7 PcT/uss4/o~cz3 argument is true, the module mAnAger stores the current ID at step 703 so that when the P~iting call is completed, the new call can be made.
If the argument at rlericion block 702 is false, the ~y~L~ proceeds to - 5 lP~ ion block 704 and the argument "DEST ID valid?" is made. If the argument is true, the module mAnAger proceeds to ~lericion block 705. If the argument is false, the module mAnAger returns an error. At ~lPricion block 705, the argument "Fllnctic-n # valid?" is made. If the argument is true, the ~ysL~
proceeds to rlPri~jorl block 706. If the argument is false, the mo~ le m~nAger 10 returns an error.
At rlPricion block 706 the argument "caller ID = 0?" is made. If the argument is true, the caller ID is replaced with the current moflllle ID and the~y~Le~ll proceeds to step 707. If the argument is false, the ~y~L~ll proceeds to15 step 707.
At step 707 any module :u~ lLly in the trAnci~pnt block is copied to its AllorAte-l address space in PnhAnce~l mPmory-. Any changes to code or data of the module are concer~uently updated in the "home" address space (AllorAte~
20 address space of that module). At step 708, the trAncient block of the calledmo~lllle is mapped in from its allocated address space in PnhAncPrl memclry.
At step 709, the called fllnction number is lerere~lced in the jump table now stored in trAncipnt mPmory. At step 710, the filnchon is called. On return, the caller ID is checked at 711. If nPc-pssAry~ the calling module is mapped into the 25 trAn~ipnt block. At step 712, control is returned to the calling filnchon or process.
w094/2090s PCT/US94/02 2~5rlS~ ~ -28-The above example applies when an application calls a module fllncfi- n The present ill-v~l~Lion is also used when the global mpmory of a module is calling a tr~n~iPnt n Pmory h~nction and when a module in trAnciPnt memory calls the tr~n~iPnt biock of another module. In a global to 5 trAn~iPnt call, the cs~elalion is the same as for the appli~Afion call of Figure 7.
The caller ID of the global requester is 0. For a trAn~i~nt to trAnsi~Pnt cA~l, the proper caller ID is pushed so that when the caller is mapped back in and control is returned, so that the requesting trAncipnt code is Actl~lly in mpm-ory.
Otherwise, it is possible for some other process to get mapped back into 10 mpmory~ which could result in an unstable ellvilo~ .ent for the computer ~y~
The present il~-v~:l.lion may be prA~ on any computer sy~ . A
ty-pical computer ~yslelll for pr~hrin~ the present invention is illustrated in 15 Figure 8. The computer ~y~l~ll. inrlll~lps a CPU 801, RAM (main memory) 802, ROM (read only mPrnory) 803, and I/O (input/output) 804 all coupled to ~y~lelll bus 807. The I/O block 804 provides access to other sy~ s such as mass storage 806 through bus 805.
The CPU 801 controls the colll~uLel, PYecllt~s instrll~iorC and processes data. The CPU 801 co~nntlmirAt~ps with the other com~ul-ents via the sy~l~ln bus 807. The CPU receives input data fronn the other coll-~ullents of the computer over the ~y~lem bus 807 and sends output data to the other components of the computer over the ~y~lell bus. The ~ysl~ bus 807 usually 25 includes an address bus, a data bus and various other control lines. The width of the address and data buses, as well as the number and type of control lines, varies from one computer ~yslel~ to _nother.
~wo g4/20905 2 1 5 7 ~ 7 2 PCT/US94/02523 Each component of the computer ~y~lelll, including RAM 802, ROM
803, and mPmory mapped I/O 804, rontAinC a nl-mhPr of individual mPm-ory lot~Ationc. To allow the CPU 801 to access these locAtiorl~, each location is ~csigmP l a specific address. Each address is a specific r~mbinAtion of binary 5 values which can be trAncmitte~l over the address bus. Since most memory devices include more than one location, addresses for all of the locAtions of a single mPmory device are usually ACsigne~l as a contiguous block. These blocks are often ~csign~Prl addresses (mapped into mPmory) in a contiguous mAnner~
as well. How~vel, there may be gaps of lmAssigne~ addresses or addresses 10 leselved for future use.
The computer ~yslelll of Figure 8 is given as an e~cample only. The present illv~lllion may be prAchcerl on any computer sy~lelll.
Thus, a metho~ and apparatus for mPmory m~nAgPm~nt is described.
A typical computer ~yslell~ consists of a number of modules or compo~ents. Computer ~y~Lellls typically include a central proresrin~ unit 15 (CPU) such as a microprocessor. The microprocessor is a program-controlled device that obtains, decodes and executes instrll~hoI ~.. A computer ~tyslelll also includes storage components for storing sy~ lll operating software, appli~Ation program instrllctionc and data. These storage components may be read only memory (ROM), rAn~lom access memc-ry (RAM), or mass storage such as disk 20 or tape storage, or any other suitable storage meAn...
The operation of a computer ~y .L~ is controlled by a series of instructions known as the "operating sysl~ ". The operating sy .Lell- iS used tocontrol basic fllnctions of the computer ~.yslelll, such as input/output, and is25 typically stored in a permAn~nt storage element such as a ROM or disk storagewhich is then lo~le(l and run in RAM. Examples of operating sy~ lns include M~DOS or PC-DOS. Computer .ysl~ S are used to execute application programs.
2~5~S -2- PCT/US94/02 During some proc~ssin~ operations, the CPU may also require the storage of data temporarily while instructions are executed on that data. In ~d~litiol, the applic~tion program that controls the pro~r~csin~ and the o~eIaLl.g ~yslelll under which the program runs mus`t be ~ccessihle to the CPU.
5 This inform~tion is made available to the CPU~by storing it in RAM, a resource known as "main m~mory".
The m.~mory co~.~ollent known as main memory is a scarce resource that is dr~mic~lly ~ c~te~l to users, data, ~roglaLns or ~rorecs~s. Memory 10 users competing for this scarce resource include applicA~ion programs, TSR's ("terminate and stay rPcitl~nt" programs) and other processes. Fy~mples of applic~ffon programs in~ lde word processors, spreadsheets, drawing programs, rl~t~h~2p~;~ etc. Certain applic~tion programs may be stored in ROM.
Generally, ho~vevel, app!ic~tion programs are stored on a mass storage device, 15 such as a disk drive. Upon initi~li7~tion, applic~tion progr. ms that are to be execllt~-l by ~e CPU are transferred from mass storage to RAM.
TSR's are also used on computer ~y~ llLS. Such programs provide "hot keys" and "pop-up windows" and . re used to ~ background tasks, such 20 as displaying a clock in the corner of the video display or mor itoring disk drive activity. TSR's have been written for many other appli~hons, . nd users often desire to have several TSR's r~cicl~nt on their computers simlllPneously. Since each TSR requires memory space in which it is located, Acl~lin~ TSR~s to the ~.y~.L~ll also increases memory rlem~nd on main m~mory-.
Main memory is typically a silicon-based memQry such as a RAM.
Alternatively, dynamic r~n~om access memory (DRAM) is used as the main m~mory. Main memory RAM can be .~cc~ssed as conventional memory, exton~le~l memory- and exp.~nde-l memory-~
~wo 94/2090s 2 1 5 7 5 72 PCT/US94l02523 Conventional Memory Cc,llv~.liorlAl mPmory is a region of RAM that is most easily AccPcsell by 5 the CPU. It is desirable to have data and instrl1~ionC nee-le-l by the CPU to be stored in convPntioIlAl memory. However, there are limits on the size of convPntionAl mPmory that limit the amount of data and instructions that can be stored in conventional memory.
Early microcomputers had 16-bit address buses, which provide 64K of address space. As the amount of mPmory required by appli- Atiorlc ineased, microcomputers had to ov~collle the limitAho~s of a 1~bit address bus. Thus, the IBM Personal Computer was intro~ erl with a segm~rltPrl addressing st~hPme which su~olled a 20-bit address bus. A 20-bit address bus provides 15 1024K, or lM, of address space, which is 16 times that of a 16-bit bus. The original IBM PC and ~ty~.l~ll soflw.l e was l1Pcigne~l with an artificial limit for convPntion~l mPmory of 640K. The 384K of address space from 640K to lM
was reserved for future use, primarily for ROM's. Since subsequent models of computers have been ~lp~cigmp~l to be backwards-comp~hble with the ori~in~l 20 IBM PC and to use the same PC-DOS M~DOS operating ~y~ , the 640K limit on convpntiorl~l memory continues to constrain the amount of memQry available to applic~hoTIc on modern computers.
wo g412~5 2 1 5 ~ 5 7 2 ~CTnUS94/02323 E~cten~P~ Memory F~ten~le-l mPmory is RAM great~:r than 1024 Kbytes that can be directly addressed by microprocessors witlh sl~ffiriPnt nurnbers of address lines. For 5 example the Intel 80286 microprocessor has a 2i bit addressing capability and can address 15M of e)~tPncle-l m~rnory above the first IM of m~mory. Intel 80386 and 80486 microprocessors have 32 bit addres~ g capability and can address appro~im~ly 4 Gigabytes of P~cten-le-l memory above the first lM of memory.
Expanded Memory E~cp~n-led mPmory, also known as "expanded memory sperifir~tionll (EMS) resel.~es a portion of ~t~n~lP~i memory, which is not dilecLly ~ccPcsihle,15 for use as P~nd~P~l mPmory and divides it into pages. By switrhing the exp~n-lef~ mPmory one page at a time into the address spaoe which is directly ~rc~PssihhP by the CPU, EMS is able to acoess a virtually lmlimiterl amount of memr~ry. However, EMS takes time to change pages. Lf the desired data is not in the EMS page frame lor~te-l in direclly ~c~Pccihle mPmory, liMS must page 20 out the current r~Iltpntc of the page frame and page in d e page from expanded mpmory which coT~t~ins the desired data. Since such a page ~h~n~e requires time, the procPcsing speed of the computer is reduced. Also, EMS is not generally applicable to all applir~tion software. Appli~ ~tion software must be written specifir~lly to take advantage of EMS if it is avAil~hle ~wo 94/2090s 2 1 5 7 5 7 2 PCT/US94/02523 Memory Map Figure 1 illustrates a mpmory map of main memory RAM on a typical computer, namely, a computer based on the 8088/8086 family of 5 microprocessors and operating under MS-DOS, such as an IBM Personal Computer. The memory map of Figure 1 is not the only possible menlQry map, but is an example of a typical mPmory map. The mPnlory map is org~ni7etl from the bollom up, with memQry location æro (101) at the bottom, continuing through the highest location in mPmory at the top. The mPmQry 10 map has three basic areas. The first area in~ lPc the lowest 640K of mPmc ry and is rere~ed to as convPntiort~l mPmory 102. ConvPntion~l mpmc)ry 102 consists entirely of RAM, which allows both read and write operations, although not all ~yslellls include the entire 640K, and some nlPmory space may be left lnt1cP l ConvPntioT-~l mPmory 102 is used to store ~ysleln software, applir~tion software, user data and other code and data, including TSR's and device dlivels. As illustrated in Figure 1, MS-DOS uses the lowest portion of memc)ry to store its own code 106 and ACSo~i~tp~l data 107. Above that, MS-DOS stores applirAffon sofl~vare, TSR's and device drivers, rollectively illustrated as 20 Pl~PmPnt 112.
Above collv~ ioT~l mPmc)ry is the 384K of reserved memQry 103, which lies in the mPm~ ry addresses above the 640K RAM limit and 1024K.
The reserved memory area 103 is occupied mainly by ROM's, which are read 25 only devioes. The ROM's found in the reserved mPmory area indude the wo 94/20sos ~ us94l02s23 ~y~leln ROM, video ROM and perhaps ROM for o~er peripheral devices, such as hard disk drives or network interfaces. In ~ lition to ROM's, the reserved m~mory area 103 also includes other types of speriAli7ell mPmory, e.g. video frame buffers.
System ROM, which supports the basiç o~elalions of the computer, typically occupies, for example, the highe~ 64K of the reserved mPmory area 103 from 960K to 1024K. The rem~ining space in the reserved memory area 103 is either llnllce-l or used for other purposes, in~ lin~ ROM's which 10 ~,u~olL other peripheral devices or an EMS page frame.
As noted above, PYtpn~lp~l mPmclry 111 includes all memory above lM.
Microprocessol, with a 24-bit ad~es ,ing capability, such as the 80286, c,m address up to 16M of mPmory, including 15M of ~t~n~lell memory 111 in 15 ~ ition to the lM of reserved m,~mory 103 and coll~e~lior~l mpmory 102.
Mi-:lo~,roc~sors which have a 32-bit ad~es~ g capability, such as the 80386 and 80486, can address up to 4G of memory~ which includes 4095M of exten~lP-memory 111 in AC~ tion to the lM of reserved memory 103 and col.v.-~ltio mPmr~ry 102. The area of P~ct~ e~l m~mory 111, located just above lM, is 20 sometim~c referred to as the high memQry area 113.
As TSR's proliferate, and as applir~tiorl programs become larger, the competition for space in conventional mPmory increases. It is desirable to provide more conv~ntiorl~l memory for applir~tion programs while 25 preserving the ability to use TSR's.
The amount of convention~l memory space available for applir~tioIl programs can be increased by reducing the amount of mPmory used by TSR's, ~wo 94/2090s 2 1 5 7 S 7 PCT/US94/02523 reducing the number of TSR's, or by rPlorAting TSR's to m-omory outside of conventional memory.
Reducing the number of TSR's is not desired because it can result in 5 reduced functionality or ~ Ance~ Reducing the amount of convPntionAl memory used by each TSR is not practical because it requires rewriting each TSR.
Since TSR's occupy some of the convPntiorlAl memory space which 10 could otherwise be used by applicAtion software, more mPmory would be available for applicAtionc software if these programs could be moved to mPmory outside of convPntionAl mPmory 102. One prior art met?lo~l increases the amount of convPntionAl memory 102 available for applirAtion software by moving TSR's from co~ tirJnAl mPmory 102 to reserved memory 103.
To implement this method, the amount of unused reserved memory 103 must first be determine~l Also, the amount of conventirnAl mPmory occupied by TSR's must be determine~l- Then, a s~lffirient amount of unallocated RAM from extPnrle~ memory must be mapped into the reserved 20 memory area to provide mPmQry space for the TSR's. Next, the TSR's are rPlorAtP-7 to the available mPmory in the reserved memory area 103.
This prior art method has disadvantages. First it, can use only unallocated reserved m-omory space. It cannot use reserved mPmory space that 25 has been AllorAte~l to ROM's, video frame buffers, or other uses. Also, the relocation of TSR's must be done to ensure that all le~elences to them are redirected to their new lorAtion.s wo 94/20905 Pcr/uss4/02s23 21S75~2 ~
Another prior art method for relc-rAt~ng from conventiorlAl mPmory is known as an "overlay". Overlays are e~ecllt~hle portions of programs that are swapped in and out of memory as ~eecl~fl Over~ys have the disadvantage of requiring the program using the overlays to be linked with an overlay 5 mAn~ger that controls access to the fllnchor c and data that are located in the overlays.
An example of the overlay scheme is illustrated in Figures 2A and 2B.
Referring first to Figure 2A, the first 1024 bytes of RAM that are Accessihle by10 the CPU are shown as mPmory block 201. ~PmOry block 201 in~ ld~pc a region of convPntion~l mpmory 102. Conventior~Al mem-ory 102 includes region 202 at the lower addresses for storing o~dlillg sy~lell- code, such as DOS. The rPmAindPr 112 of convPntio~l rnPmory 102 above the DOS region 202 and below leselved memory 103 is used for storing applil~hon~, TSR's, device 15 driv~s, etc.
Some applirAtior-.c are too large to be stored entirely in convPntioI Al mPmory region 112. One example of such an applic~ti-~n is Word Perfect, a word proressing app!i~Atio~ There~ore, only a portion of Word Perfect ~s 20 stored in mern~ry region 112 at any one time. The remAining portions are stored in other nlPmory~ such as disk storage 204. As portions of the application are r~eP~l~P~l~ they are transferred from disk storage 204 to mPmoryregion 112.
25In the example of Figure 2A, a portion of the application reprP~Pntef~ by block A 203 is stored in memory region 112. The applirAtion is divided into ~wo s4/2090s 2 1 5 7 5 7 2 PCT/US94/02523 two other portions, block B 205 and block C 206, that are stored in disk storage204. Disk storage 204 is coupled to RAM 201 through a bus or other trAncmi~sion means 207.
When the f 1nctiorlAlity contained in block A 203 is being called or used, block A 203 rPmAin~ rPsi-lPnt in memQry region 112. When other filn~honAlity is required, the code providing that ftmctionAlity must be transferred from the disk storage 204 to the memory 201. Referring now to Figure 2B, block B 205 is transferred from disk storage 204 to mPmory region 112. Accordillgly, the applicAhon portion block A 203 previously r~ci~ing in mPmory region 112 is transferred to disk storage 204. Block B 205 is shown graphically as taking up more of memnry region 112 than did block A 203. The blocks need not be the same size, but must be as small as the available address space in mpmory region 112.
A disadvantage of overlays is that they are sv~ ed to and from a disk file, increasing exectlhQn time and rerlllcing y~r~ lAnce~ Certain programs require some code or data to always be rPsi~lPnt in col~ ,tionAl ~nPmory.
Overlays do not provide any Tlletho~l of idellli~yillg code or data that permAnPntly resides in convPnhor~Al memory. When blocks A 203 and B 205 are swapped, they are ~w~yed in ~ eLy. No portion of block A 203 rPmAins in mPmory region 112. The.efore, such programs cannot use the overlay schPme. Some TSR's cannot be converted to overlays. These TSR's include those that provide internal DOS fllnctionAlity. One example of this is 25 NetWare DOS Client sofl-w~e produced by Novell, Inc. of Provo, Utah.
Thus, the prior art does not provide a ~y~L~l~l for reducing the arnount of convPnhoItAl memory used by TSR's without sacrificing performAnce WO 9412090s PCT/US94102523 215~572 ~
SUMMARY OF THE PRESENT INVENTION
The present invention provides DOS execllt~hle programs that are constructed so that they can coo~laLe with other similarly constructed 5 programs in sharing m-pmory used by portions of their code or data. This reduces the overall requirements of conv~fitioI Al mpmory. In the present inveT-hon, these programs are referred to as modules and can be application programs, TSR's or any other P~ec-lt~hle file which are collveLled into this module format. The modules include tr~nciPnt code and data that may be 10 swapped out of collv.~ ioIl~l mPmory, and global code and data that is not ~wdl,~able and stays resi~lPnt in convPnfforl~l mpmory.
By providing global data blocks that remain resi-lPnt in m~Pmory, modules of the present invention can call other modules, as well as interrupt 15 h~nAlPrs and other code or data that is externally or asynchronously available.
The present invention thus Sll~Ol~S more progr~mming interfaces than overlays.
The present invention re~ ces convention~l memory requir~ment~ by 20 allowing mr~ les to share a single block of convention~l memory. Regardless of the number of modules, the size of the block of convPntion~l memory allocated for their use r~mAins the same. The mPmory block ~ is of a size large enough to store the largest block of tr~n~ipnt code or data of the modules that share the convPntion~l memory block.
Tnstp~ of swapping transient blocks of modules to and from disk storage, the tr~n~iel t blocks are swapped between col~v~ ;on~l memory and extenfl~l or expanded m.~mory. This si~nific~ntly reduces transfer time comp~red to overlay ~rhemes, improving ~lfo~ nce ~WO 94/20905 2 1 5 7 5 7 2 PCT/US94102523 BRIEF DESCRIPIION OF THE DRAWINGS
Figure 1 is a nlPmory map illustrating the mPmory org~ni7~ion of a typical computer ~ysLe~
Figures 2A and 2B illustrate a prior art overlay s~eme.
Figure 3 illustrates the module structure of the present invenho Figure 4A - 4E illustrate ~t:lalion of the m~mory m~n~ger.
Figure 5 is a flow diagram illustrating the pre-init operation of the invention.
Figure 6 is a flow diagram illustrating the real-init ~aLion of the invention.
Figure 7 is a flow diagram illustrating the calling of a module in the invention.
Figure 8 is a block diagram of a computer ~ySl~lll for implPmPnhng the invention.
Figure 9 illusliales a VMCB data block.
W0941~905 21575~2 PCr/US94102523 DETAILED DES~ lON OF THE PRESENT ~VENTION
A methoA for providing more PfhriPnt use of convPntion~l ~nemory in a computer ~y~lel-l is described. In the following flPsrription~ numerous 5 specific details, such as type of computer ~y~leln, memory address lor~tion~, amounts of mPmory, etc., are described in detail in order to provide a more thorough description of the present invPnhon- It will be apparent, however, to one skilled in the art, that the present invention may be pr~cticeA without these specific ~lPt~ . In other instances, well-known features have not been 10 described in detail so as not to llnneces5~rily obscure the present invPntion-The present invention reduces col~ .lhor~l mPmory requir~mPnt~ byproviding a method and apparatus for TSR's and other programs to share space in convPnhi(!n~l memQry. The TSR's and programs are configured as 15 "modules" and a module m~na~er controls the swapping of modules into and out of convPntion~l memory. In the ~rer~lled emboAiment of the i~ .,Rorl, only one module is resiflPnt in convpntion~l nnPm~ry at any one time. The other modules are stored in e~cten~lp~l mPmory or exp~n~leA m~mory. This avoids time consuming and ~.ro~ nce reAI-ring disk swaps.
The c~lalion of the module m~n~r is illustrated in Figures 4A-4E.
Figure 4A illustrates a memory map of convpnhon~l~ reserved, exten~leA and exp~ndeA mpmory. ConventioTl~l memory 102 includes DOS storage region 202 at the lower mPmory area. Just above the DOS region 202 in the 25 cc,llv~ltion memory 102 is space reserved for the module m~n~ger 401. Above the module m~n~ger 401 is a region resel ved for global code and data of any modules available to the ~ysleln. Stored above the global code and data region 402 is a region reserved for tr~n~iPnt blocks of the modules. The tr~n~i~nt ~wo g4120gO5 2 1 5 7 5 7 2 PCT/US94/02523 block module 403 has an upper boundary 404 which is fixed and determined by the largest trAn.cient block of any module in the ~y~ . The space in coll-v.~..tionAl mPmory 102 above upper boundary 404 and below reserve mPmc-ry 103 is available for other applicAh~rlc and proc~csPs.
Reserve mPmory 103 is used for ROMs and for expanded memory 406.
Above reserved memory 103 is P~tPn-le~ m-omory 111 (above 1024 Kbytes). The extPn~lerl mPmory 111 stores the tr~nci~ont block 405 of a module re~elled to asmodule A. The e~n~le~ mPmory 406 indudes the trAnciPnt blocks 407 and 10 408 of modules referred to as modules B and C, r~ectively.
After the global code and data have been stored in global region 402 and the upper bound 404 of trAnCipnt block 403 has been ~fille~l~ the mo~ 1e mAna~er is ready to access modules as they are called. Referring to Figure 4B, 15 conci-ler the case where module B is requested. Module B may inr~ e code perm~nPntly resil1Pnt in the global region 402. When morlllle B is called, the module m~n~Pr transfers the module B tr~ncipnt block 407 from expanded memory 406 into the trAnci~nt block 403 of convpntio~Al mPmory 102. Any tr~nciPnt block of other modules is ~vvd~ed out of co~l-vr.ltion~l memory at 20 this time. The ~locess calling module B then can access it as if InorllllP B were always resirlPnt in conventiQr-Al m~mory. As seen in Figure 4B, the trAnciPnt block 407 of module B does not use all of the available address space in tr~n.cierlt block 403. However, the upper bound 404 of tr~nsient block 403 remAinc fixed.
Figures 4C-4E illustrate the process of a module calling another module.
The trAncient block 408 of module C is resitl~nt in tr-Ancipnt block 403 of collv~..hollAl mPmory 102 as illustrated in Pigure 4C. Module C calls module wo 94/20905 Pcrlus94l02 21~j75~2 -14-A through the module m~nsger. The module nSAn~ger keeps track of the calling module and the destination module. The transient block 408 of module C is swapped with the tr~n~iPnt block 405 of module A. Referring to Figure 4D, the trrsn~ipnt block 405 of module ~ is now stored in the trAn~iPnt 5 block 403. Note that the transient blo~k 405 of module A occupies all the address space of tr~n.ciPnt block 403. After module A execlltes the f -ncfi~n for which it was called, the module m~n~ger swaps the tr~sn~iPnt block 405 of module A with the tr~n~iPnt blocl~ 408 of module C, as illustrated in Figure 4E.
10 Module Structure In the present invPn~ion, code and data of modules are structured into different r~le~ ies so that a general soll~*nn is provided for m~n~geInent of the mo~ p~ in convPn*Qn~l mPmory. These categories indude a f~lnctiQn 15 licp~tcls table (jump table), trAnCient code and data, global code and data, and start-up code and data. The format of a module is illustrated in Figure 3.
The structure of the morlllle 301 inrl~ c three regions 302, 303 and 304.
Region 302 inrlllflPs a jump table 305 and a tr~n~jPnt group 306. Region 303 20 colst~ins global code and data and region 304 includes start-up code and data.
The tr~ncipnt region 302 in~ d~ code and data that is "swappable." That is, this data can be sw~ed in and out beLvve~lL col~ hols~l m~mory and PnhAnCe~ mPmory (P~tende~l or exp~n~Pd).
~57~ 72 ~wo 94l2090s ~ Pcrrusg4/02s23 ~UMP TABLE
The jump table 306 represents fllnctiorl.~ s~yyolled by the module. The jump table (also rer~led to as tr~n~iPnt code) can be ~wd~ed out at any time.
5 Theierc,le interrupt h~n-llPrs (or any code se~mPnt which can be directly ~ccPsse-l) cannot exist in the transient code se~mPnt The first enhy in the jump table is the pointer to the module init routine. The jump table 306 consists of yoilllels to at least four prellPfine(1 functions which are conlmor to all modules, namely, init, lmlo~-l, version, and statistics.
Init: Init is an initiAli7~tiQn routine in the moAllle This initi~li7~tion routine ~elrollns pr~init to obtain the nerPss~ry par~mePrs for inih~li7in~ a module and then ~elroll~s a real-init to ~ctll~lly load the module into the ay~r~l;ate sef~ment- It is within this real-init process that veclo~s are hooked.
Unload: The lm1O~1 filnrtion f~rilit~p~ release of resources. The nln~i request can be failed if a check for lmlo~l safety (CX = FE~Fh) returns a critical section status. If a mcl~ltlle is well behaved, then there is no reason to fail and a check for tlnlo~ safety returns a zero, in~ tin~ that it is safe to 20 llnlo~l for real. A request to lmlo~l for real cannot be failed. If a module fails the lmlo~l check, then all modules previously ~ ke~l are notified with an -nlo~1 cancel (i.e., CX = ~ ;h).
Version: The version fllnction obtains the major and minor version of 25 the module. This fimchion provides f )mmon~lity between modules. Other subfilnctions of this version filnctioIl also establish commor ~lity between wo 94l20905 Pcrlus94l02~
215757~ -16 modules. The other subfunctions (Olh-OBh) also h~iliPte inter-module communication (multi-casting) regarding connechon establichmPnt, ~liccorlnechorl, etc.
-For example, there is a multi-cast call at the first task termin~te (i.e., _Notify ~n~ r subfunction 01h,PSP Termin~te). This subfilnctioI is part of the pre-lPhn~-l general fllnction Statistics: The sPhctir~ filnction obtains statistics for the mo~ le This 10 fllnchon is optional. The statistics are for module debllg~ing. The statistics structure is a length-prece~ l buffer; the first word of the statistics structure table in~ir~tes the number of bytes of valid statistics i~ ti~n All other sPhcti~ i..rO....~tic!n needs to be recorded between the stat size and the stat end fieldc.
Other filnchonc can be provided specific to the n~o~l~llP and follow these pre.~ hnerl fimctiortc. The t~rmin~tin~ zero (DD0) follows the common fllnctioJI.c and all other fllnctionc rlefine~l by the module in the jump table.This lets the module m~n~r know how many fllnc~ionc are supported by the 20 module so that requests beyond this number can be ~l~nierl TRANSIENT DATA
Tr~ncient data, like tr~nci~nt code, has specific requir~m~n~c. Certain 25 types of data cannot exist in the tr~nciPnt group. These restricte(l types in~ e stacks and data which is p~Csecl to another module. ~or performance reasons, all data that is not global should be in this tr~n~ient data segmPnt- Tr~nciPnt data is swapped between ~nh~ncerl memory and convPnho~l memory.
~wo g4/20905 21 5 75 7~ PCT/US94/02~23 GLOBAL CODE AND DATA
The global region 303 stores code and data that must remain rPsiAPnt in 5 convPnho~l memory. For example, code and data that may be stored in the global region 303 include interrupt h~nAlers for global code, far call h~"AlPrs not ~ccPcsed through the moAlllP mAn~gPr, stacks, and data passed to other modules. It is possible to create a module with no mPn~ory in the global region.
STARTUP REGION
The startup region includes the inih~li7~hon code. The code provides pre-init and real-init o~alions. During pre-init, each moAllle provides a 15 module m~n~ger with a VMCB structure data block. The modules use the init routine to report the amount of initi~li7~hion mPmory required (including global and tr~n~iPnt m~Pmory ~egm~Pntc) through this VMCB structure.
Sperifi~Ally, the VMCB_TnitTm~gPparaLength par~nnet~Pr ~fines the preload total size.
The module m~n~ger uses VMCB_InitImageParaLength to determine how much m~mory to swap in and out during real init and run time. This method of deterrnining mofl~ m-omory ~llor~tioIl avoids confusion and simplifies the process of keeping m~mory segment~ separate. Keeping 25 m~mory se~nent~ s~araLe is use~ful when rllnning global and protected mode data segrn~nt~ simllltAneously. If the mo~lllP is dep~nflPnt on other modules being lo~le-l, the dep~ntlency for the module is ~erke~ during the pre-init stage. The fake init flag (AX = -1) is passed on the way into this procedure.
wo 94l2090S PCT/US94/0Z523 215~5~2 -18-During real-init, the module is required to move the global code/data from its lo~flP-l lor~tion The destin~tion of this group is rl~fine(l in the BX
register when thc morlllle m~nAger calls the l~it f-inction on a real init. After 5 this process, the module must execllte any fixups nece~siPtel1 by the moving of the global group. These fixups are performed to ensure that the data is ler~ cing the new location rather than the group k~lerl by DOS.
MODULE MANAGER
Overseeing the individual mo~ les and multiplexors is the module m~n~Pr. Appli-~tionc make all calls to the mo~lllle ~n~n~gPr, which directs requests to their ~.o~er destin~honc~ whether that be another module (child) or multiplexor. the module m~n~ger also ensures that replies return to their 15 a~.~.iate callers.
Every moAllle calls other modules via the module m~n~ger. Even when a module is calling its particular layer's multiplexor, it makes that call to the module m~n~ger~ which then calls the particular multiplexor. Likewise, 20 when a call returns from a particular mo~lllle~ that call makes its way from the multiplexor to the particular TnorllllP via the module m~n~ger.
One responsibility of the module m~n~ger is ensuring that API calls between the other pieces are ~ ~ly routed. The module mAn~ger must 25 there~ole know if the modules required by a given user applic~tion have lo~-lPrl It polices modules that call other modules. The module m~n~ger h~ncllP~ modules and fllncfion~ that are called asynchronously as well.
~wo 94/20so~ 2 1 5 7 5 7 2 K~TIUS94/02523 The module m~n~ger provides the APIs to call a function and a module by number. ~he module m~n~ger also knows who is calling that fimction, via the caller's module ID. Module IDs are pre-A~si~erl Because the module m~nager h~n~lles all APIs on a number basis, the module m~n~ger has no 5 intrin~ic depen~lenries or ties to the individual f~nctiorl~ in the modules.
~'orl~equently, modules that are not part of the specific Requester model can use the module m~n.~cr as a TSR memory m~n~ger. This is what gives the module m~n~ger the c~pAbility of supporting varied and diverse TSRs.
The mo~ le mAn~ger provides the basic services that all modules require, especially those allowing and f~rilit~ting calls between all lo~
modules. Th~l. rore, the module m~n~ger encoTnp,~ses all layers of the Requester model.
The module m~nAger not only loads and lmlo~lc each module, inr~ ing multiplexors, it also h~n~ s mPmory services (allocation and m~nA~m~nt) for all mo~ . The mo~ e m~n~ger employs memory swapping for its modules.
The module m~n~ger ~1r~r~ s whether a given mo~ e uses e~n~1e-1 m-omory, extPnfle~l memory~ conv~ntion~l nl~mory~ or any memory type su~olled~ without affecting the modules tllemcPlves. The individual child modules are therefole freed from these m~mory concerns.
-Child modules must still conform to certain requiremPntc for memory usage. Once they have done so, they gain all the advantages of having the module manager h~n~lle m~mory merll~ni~m~ for them.
w0 94/2090s Pcr/us94l02s23 ~
'' 215rlS~2 The module m~n~ger is also responsible for 10~-7time-configuration APIs. Any module may be configurable. For instance, the cor~nection table wants a certain number of co lnecti<~ns, or IPX wants to support a number of ECBs, or bigger or sm~ r buffers. In these instances, the module m~n~ger 5 does the work for the module. ~
~ of7ihior7~11y, a user may want to load a module in non-swapped m~mory~ regard ess of the memory type being used, in order to optimize perform~nce. Ideally, optimal configuration vari~tions are ~.7ministered by 10 the modu e m~nager. An API is provided for mo~7l71~s that may desire this capability.
RerAIlce the n~o~711le m~n~Pr cdnnot be aware of all possible configuration perml1Pho~s, the Requester includes an API wherein a module 15 can specify its own configuration options, int 1tlo7ing the tokens used to eco~,~,ize those options. This is a table-driven API that can be called at sldr of a moflt11e to parse configuration inform~hon from the NET.CFG file.
When the module m~n~er loads, it reads from a file, within the 20 current or other-sperifiell directory, what modules it should load. The module m~n~?r loads those modules in ~he file-specified order.
~WO 94/20905 - 21 - PCT/US94/02523 When lo~llin~ modules, the current dilecLol~ is used by default. If you want to load modules from a different directory, you can ~l~si~n~te the directory in the mo~llle = commAn-l in the configuration file. For example:
5 VLM = C:\NWCLIENT\CONN.VLM
You can also specify a path for the configuration file on the morllllP
romm~n~ line. For example:
10 VLM /C=C:\NWCLIENT\NET.CFG
A default set of modules is hard-coded into the module m~n~er for basic filnction~lity. Ho~vevel, NET.CPG can be used to override the ~lPf~t~lt options.
C~llin~ the Module Manager To find the address for the motlllle m~n~er far call hAnr~l~r, the applir~hon makes an i~ yL 2Ph with 7A20h in the AXregister and BX = Oh.
20 The module m~na~er returns an address in ES:BX that is a pointer to the far call address (the moflllle m~n~Pr). AX is æroed out to let the applirAhon know the module m~n~er h~n~lle~l the call.
Call-By-Number System:
The module m~n~er uses a call-by-number ~yslelll which uniquely i~lPntifi.os modules in the ~yslt:~n. Fllnchon~ are also called by number. This protocol requires that appli~hQns provide three essential pieces of W094/2090~ ~CTrus94lo2s23 21S75~2 informAho~l to the nlo~ le m~n~er, including CALLER_ID, DEST_ID, and DEST_FUNC. Each of these three numbers is of size WORD.
CALLER_ID and DEST_ID are nOmbers which uniquely identify a 5 particular module. The module mAnAgPr uses these nllmkers to swap in the proper module and dispatch the call a~lu~liately.
DEST_FUNC in~lirAt~s what f~lnction the caller wants to ~e~
DestinAtion filnction~ are rlefin~rl within the individual module. These 10 fllnctionc are rl~hined by the mo ~ ec jump table region 305.
These three required Plpmer~tc work together on every filnctiorl call mAnAgP~l by this sy:.Lwll. When an appli~-~tion makes a module call, a far call address for the module mAnAger mus~ be obtained. The following code is an 15 example of how an applil~Atiorl retrieves the far call address.
data s~..~
vlmCallAddress dword 0 data ends oode se~
o mov ax, 7A20h mov bx, 0 int 2Fh or ax, ax 1nZ NO VLM
mov word pk vlmCallAddress, bx mov word ptr vlmCalL~ddress + 2, ES
o NO_VLM: .
o o aode ends ~WO 94/2090S 2 1 5 7 5 7 2 PCT/US94/02523 The following code is an example of a non-module application using the far call address to make a request of _VLM Notify to rehurn the version of the module m~n~ger module.
5 mov ax,0 push ax ; CALLER_ID
mov ax, VLM_ID_VLM ;(Olh) push ax ; DEST_ID
n~v ax, VLM_NOTIFY ;(Olh) 10 push ax ; DEST_FUNC
mov bx, 0 ; GET VERSION SUB-FUNC
call VLMCallAddress In sl~mm~ry, the caller first pushes its own ID on the stack.
(CALLER_IDs are non-zero for modules and 0 for applir~ffQr c.) Then, the caller pushes the desffn~hon ID--sperihr~lly, the ID of the multiplexor module or of the specific child mo~ le it wants to call. Finally, the caller pushes thedesired filnchon n-lmh~r.
There are two reserved (or ~y~ -only) fi~nchonc~ nchnn zero and f lncfirn two, used for iniff~li7~ffQn and lmlo~ e~e~ively. Fllnchonc one and three are also used consisl~tly across the various modules. One and three are used for a generic notify hlnchcn with multiple subhmr~ions and 25 module statistics l~s~eclively.
On return, the module m~n~er dears the CALLER_ID, DEST_ID and DEST_Fl~C from the stack, so an applir~ffon must not do so. This is coInmoI~ly ~e~--ed to as the Pascal calling conv~ntion.
wog412090s 2~.Sl~rl2 Pcr/us94lo2s23 Two registers are used by the module m~nAger: AX and BP. BP is for internal use by the module m~n~ger only. Applications should not use BP for any parameter request. BP may be used only to push on the stack the three required values. Applic~horl~ should use AX for return codes only.
The module m~n~er also provides a method for h~n~3lin~
asynchronous calls. The calling fimrtion provides a pointer to a block of memory that includes the destinAtion ID, destin~tior~ function, caller ID, and also any registers that need to be set up for the call. The request can then be put 10 on hold and PYectltP~l at a later time. When the module m~nAger determines that it can't PYPCllte code that is n~PP~l~Prl, the module mAnA~Pr can put off the e~eclltion of the code. The caller of the ftlnction can receive control back before the f~mchon is actually completed.
15 Module Manager Pr~Init A flow diagram of the pre-init operation of the present i~l~,ention is illustrated in Figure 5. At step 501, the mor~ e m~na~r configures itself (NET.CPG, and VLM = files). The configuration could include a list of new or 20 ~ itior~l modules. The module mAnAger then loads each module on the current list one at a time at step 502. The module is lo~ using the load overlay API at step 503. The initi~li7Ation filnction is called with the "hke-init" flag on (in(1irAting pre-init) at step 504. The module being lo~ier7 provides to the module mArl~er a VMCB data block at step 505. At step 506, 25 the module m~n~er reads the mpmory requirement~ of the module, i.e. the inih~ tion ml~mory re~ .ents, any global memQry requir~menh, and tr~ncient memory requir~m~nt~.
~WO 94/20905 2 1 5 7 5 7 2 PCT/US94/07523 At step 507, the module mAnAger stores the parAmeters for the module in a module parameter table. The parAmetPrs include initiAli7Ati~n memory requirPment~, global nnPmory requirPmPnt~ (if any), trAnCient memory requirPmPnt~, and the number of fimchon~ of the module.
The module mAnAger proceeds to rle~i~ion block 508. At ~leri~ion block 508 the argument "last module?" is made. If the argument is false, there is more module mPmory informAtion to be obtained and the module mAnAger returns to step 505. If the argument at ~1P~ on block 508 is true, the memory 10 re~lui~ .Pntc of all modules have been obtained and the module mAnAger proceeds to step 509.
At step 509 the mo~llle mAnAger collectc the data from the module par~metPr table to determine the mPmory rlee~le~ for global data. The module 15 mAnA~er then All~AtPs address space in cc,~ ..tionAl mPmory for storing the global dat~.
At step 510, the module mAnAgPr i~lPntifips the largest trAnciPnt mPmory requirement of the mo~ lPs that have are to be loAde-l The size of the largest 20 trAncipnt block ~lpfinps the size of the t~rAncjerlt block 403 in convPTltior Al memory. At step 510, the mo~ mAnAger AllocAt~Ps RAM for the trAnCipnt mPmory block of a size at least as large as the largest block of the modules to be loAdPcl At step 511, the module m~nAger delellllilles what address space can be used for storing the trAn~ipnt blocks of each module. The order of ~ier~l~l,ce is first extended memory, then expanded memory, then convPntionAl mPmory.
The user can configure the module mAnAger to use one type of memory in wo 94/20905 Pcr/uss4/02s23 2157~72 -26-particular. The module m~n~ger determines at step 512 if one type of mPmory is enabled for use. If a type of mPmory is not enabled, the module m~n~ger selects a mPmory type using the aÇor~ PntiomP~7l heuristic.
An example of a VMCB data block is illustrated in Figure 9.
Module MaI ~er Real-Init After the pre-init routine, the ~no~'l-lPc are lo~- P~ again with the fake-init flag not set, so that the real-init routine is PYec~te-'. The operation of the real-init routine is illustrated in Pigure 6. At step 601, the morlt71P m~n~gPr sets the fake-init flag to zero. At step 602, the first modu,e is lo~f Prl At step 603, the initi~li7~tion routine is called. At step 604, any interrupt veclu~ for15 the module are hoo~cef7 At step 605, any other resources of the modu'es are pllor~tPrl At step 606, global code and data is moved to the ~1lorAtPr3 address space. At step 607, the tr~nCipnt block of the mof7l~le is copied into the address space ~ t~Pr~ for that mo~ l-le's tr~n~ipnt block (in e~ctPnflPf, exp~nf r~, or col~v~--Ron~l nl~mory). At rlPri~ion block 608 the argument "last mofllllP?" is 20 made. If the argument is true, the rea'.-init procedure e~ds at step 609, where the module m~n~Pr termin~tes and stays rP~ Pnt- If the argument at rlPri~ n block 608 is false, the system returns to step 602.
Module Loading A flow diagram illustrating module lo~ling is illustrated in Figure 7. At step 701 the module m~n~ger receives a call to access a module. At rleri~ion block 702, the argument "other request being serviced?" is made. If the ~wos4nosos ~7 PcT/uss4/o~cz3 argument is true, the module mAnAger stores the current ID at step 703 so that when the P~iting call is completed, the new call can be made.
If the argument at rlericion block 702 is false, the ~y~L~ proceeds to - 5 lP~ ion block 704 and the argument "DEST ID valid?" is made. If the argument is true, the module mAnAger proceeds to ~lericion block 705. If the argument is false, the module mAnAger returns an error. At ~lPricion block 705, the argument "Fllnctic-n # valid?" is made. If the argument is true, the ~ysL~
proceeds to rlPri~jorl block 706. If the argument is false, the mo~ le m~nAger 10 returns an error.
At rlPricion block 706 the argument "caller ID = 0?" is made. If the argument is true, the caller ID is replaced with the current moflllle ID and the~y~Le~ll proceeds to step 707. If the argument is false, the ~y~L~ll proceeds to15 step 707.
At step 707 any module :u~ lLly in the trAnci~pnt block is copied to its AllorAte-l address space in PnhAnce~l mPmory-. Any changes to code or data of the module are concer~uently updated in the "home" address space (AllorAte~
20 address space of that module). At step 708, the trAncient block of the calledmo~lllle is mapped in from its allocated address space in PnhAncPrl memclry.
At step 709, the called fllnction number is lerere~lced in the jump table now stored in trAncipnt mPmory. At step 710, the filnchon is called. On return, the caller ID is checked at 711. If nPc-pssAry~ the calling module is mapped into the 25 trAn~ipnt block. At step 712, control is returned to the calling filnchon or process.
w094/2090s PCT/US94/02 2~5rlS~ ~ -28-The above example applies when an application calls a module fllncfi- n The present ill-v~l~Lion is also used when the global mpmory of a module is calling a tr~n~iPnt n Pmory h~nction and when a module in trAnciPnt memory calls the tr~n~iPnt biock of another module. In a global to 5 trAn~iPnt call, the cs~elalion is the same as for the appli~Afion call of Figure 7.
The caller ID of the global requester is 0. For a trAn~i~nt to trAnsi~Pnt cA~l, the proper caller ID is pushed so that when the caller is mapped back in and control is returned, so that the requesting trAncipnt code is Actl~lly in mpm-ory.
Otherwise, it is possible for some other process to get mapped back into 10 mpmory~ which could result in an unstable ellvilo~ .ent for the computer ~y~
The present il~-v~:l.lion may be prA~ on any computer sy~ . A
ty-pical computer ~yslelll for pr~hrin~ the present invention is illustrated in 15 Figure 8. The computer ~y~l~ll. inrlll~lps a CPU 801, RAM (main memory) 802, ROM (read only mPrnory) 803, and I/O (input/output) 804 all coupled to ~y~lelll bus 807. The I/O block 804 provides access to other sy~ s such as mass storage 806 through bus 805.
The CPU 801 controls the colll~uLel, PYecllt~s instrll~iorC and processes data. The CPU 801 co~nntlmirAt~ps with the other com~ul-ents via the sy~l~ln bus 807. The CPU receives input data fronn the other coll-~ullents of the computer over the ~y~lem bus 807 and sends output data to the other components of the computer over the ~y~lell bus. The ~ysl~ bus 807 usually 25 includes an address bus, a data bus and various other control lines. The width of the address and data buses, as well as the number and type of control lines, varies from one computer ~yslel~ to _nother.
~wo g4/20905 2 1 5 7 ~ 7 2 PCT/US94/02523 Each component of the computer ~y~lelll, including RAM 802, ROM
803, and mPmory mapped I/O 804, rontAinC a nl-mhPr of individual mPm-ory lot~Ationc. To allow the CPU 801 to access these locAtiorl~, each location is ~csigmP l a specific address. Each address is a specific r~mbinAtion of binary 5 values which can be trAncmitte~l over the address bus. Since most memory devices include more than one location, addresses for all of the locAtions of a single mPmory device are usually ACsigne~l as a contiguous block. These blocks are often ~csign~Prl addresses (mapped into mPmory) in a contiguous mAnner~
as well. How~vel, there may be gaps of lmAssigne~ addresses or addresses 10 leselved for future use.
The computer ~yslelll of Figure 8 is given as an e~cample only. The present illv~lllion may be prAchcerl on any computer sy~lelll.
Thus, a metho~ and apparatus for mPmory m~nAgPm~nt is described.
Claims (16)
1. A method of allocating memory in a computer system comprising the steps of:
using a processing means, identifying a first portion of a first application that is required to be in a first range of memory addresses as a global block;
using said processing means, allocating address space in said first range of memory addresses for storing said global block;
using said processing means, identifying a second portion of said first application that is not required to be in said first range of memory addresses as a transient block of said first application;
using said processing means, allocating address space in a second range of memory addresses, not within said first range of memory addresses, for storing said transient block;
using said processing means, allocating transient address space in said first range of memory addresses for temporarily storing said transient block.
using a processing means, identifying a first portion of a first application that is required to be in a first range of memory addresses as a global block;
using said processing means, allocating address space in said first range of memory addresses for storing said global block;
using said processing means, identifying a second portion of said first application that is not required to be in said first range of memory addresses as a transient block of said first application;
using said processing means, allocating address space in a second range of memory addresses, not within said first range of memory addresses, for storing said transient block;
using said processing means, allocating transient address space in said first range of memory addresses for temporarily storing said transient block.
2. The method of claim 1 further including the steps of:
using said processing means, identifying a first portion of a second application that is required to be in said first range of memory addresses as a global block of said second application;
using said processing means, allocating address space in said first range of memory addresses for storing said global block of said second application;
using said processing means, identifying a second portion of said second application that is not required to be in said first range of memory addresses as a transient block of said second application;
using said processing means, allocating address space in said second range of memory addresses, not within said first range of memory addresses, for storing said transient block of said second application.
using said processing means, identifying a first portion of a second application that is required to be in said first range of memory addresses as a global block of said second application;
using said processing means, allocating address space in said first range of memory addresses for storing said global block of said second application;
using said processing means, identifying a second portion of said second application that is not required to be in said first range of memory addresses as a transient block of said second application;
using said processing means, allocating address space in said second range of memory addresses, not within said first range of memory addresses, for storing said transient block of said second application.
3. The method of claim 2 further including the step of:
using said processing means, temporarily storing said transient block of said first application in said transient address space with said first application is executed.
using said processing means, temporarily storing said transient block of said first application in said transient address space with said first application is executed.
4. The method of claim 2 further including the step of:
using said processing means, temporarily storing said transient block of said second application in said transient address space when said second application is executed.
using said processing means, temporarily storing said transient block of said second application in said transient address space when said second application is executed.
5. The method of claim 2 wherein the size of said transient address space is sufficient to hold the larger of said transient block of said first application and said transient block of said second application.
6. The method of claim 1 wherein said first range of memory addresses is conventional memory.
7. The method of claim 1 wherein said second range of memory addresses is extended memory.
8. The method of claim 1 wherein said second range of memory addresses is expanded memory.
9. The method of claim 1 wherein said first application is a terminate and stay resident application.
10. A method of allocating memory in a computer system comprising the steps of:
using a processing means, allocating address space in a first range of memory addresses for storing a first portion of a first application that is required to be in said first range;
using said processing means, allocating address space in a second range of memory addresses, not within said first range of memory addresses, for a second portion of said first application that is not required to be in said first range of memory addresses;
using said processing means, allocating address space in said first range of memory addresses for storing a first portion of a second application that is required to be in said first range of memory addresses;
using said processing means, allocating address space in said second range of memory addresses, not within said first range of memory addresses, for storing a second portion of said second application that is not required to be in said first range of memory addresses;
using said processing means, allocating transient address space in said first range of memory addresses of a size sufficient to store the larger of said second portion of said first application and said second portion of said second application, said transient address space for temporarily storing a transient block of said first application and for temporarily storing a transient block of said second application.
using a processing means, allocating address space in a first range of memory addresses for storing a first portion of a first application that is required to be in said first range;
using said processing means, allocating address space in a second range of memory addresses, not within said first range of memory addresses, for a second portion of said first application that is not required to be in said first range of memory addresses;
using said processing means, allocating address space in said first range of memory addresses for storing a first portion of a second application that is required to be in said first range of memory addresses;
using said processing means, allocating address space in said second range of memory addresses, not within said first range of memory addresses, for storing a second portion of said second application that is not required to be in said first range of memory addresses;
using said processing means, allocating transient address space in said first range of memory addresses of a size sufficient to store the larger of said second portion of said first application and said second portion of said second application, said transient address space for temporarily storing a transient block of said first application and for temporarily storing a transient block of said second application.
11. The method of claim 10 further including the step of:
using said processing means, temporarily storing said second portion of said first application in said transient address space when said first application is executed.
using said processing means, temporarily storing said second portion of said first application in said transient address space when said first application is executed.
12. The method of claim 10 further including the step of:
using said processing means, temporarily storing said second portion of said second application in said transient address space when said second application is executed.
using said processing means, temporarily storing said second portion of said second application in said transient address space when said second application is executed.
13. The method of claim 10 wherein said first range of memory addresses is conventional memory.
14. The method of claim 10 wherein said second range of memory addresses is extended memory.
15. The method of claim 10 wherein said second range of memory addresses is expanded memory.
16. The method of claim 10 wherein said first application is a terminate and stay resident application.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US2831293A | 1993-03-09 | 1993-03-09 | |
| US028,312 | 1993-03-09 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2157572A1 CA2157572A1 (en) | 1994-09-15 |
| CA2157572C true CA2157572C (en) | 1998-12-01 |
Family
ID=21842743
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA 2157572 Expired - Lifetime CA2157572C (en) | 1993-03-09 | 1994-03-08 | Method and apparatus for allocating memory to reduce conventional memory requirements |
Country Status (6)
| Country | Link |
|---|---|
| EP (1) | EP0688449A4 (en) |
| JP (1) | JPH08507630A (en) |
| CN (1) | CN1090780C (en) |
| AU (1) | AU6253794A (en) |
| CA (1) | CA2157572C (en) |
| WO (1) | WO1994020905A1 (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7143263B2 (en) * | 2003-10-16 | 2006-11-28 | International Business Machines Corporation | System and method of adaptively reconfiguring buffers |
| US7603392B2 (en) * | 2006-06-05 | 2009-10-13 | International Business Machines Corporation | System, method and computer program product for storing transient state information |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4943910A (en) * | 1987-04-14 | 1990-07-24 | Kabushiki Kaisha Toshiba | Memory system compatible with a conventional expanded memory |
| US4926322A (en) * | 1987-08-03 | 1990-05-15 | Compag Computer Corporation | Software emulation of bank-switched memory using a virtual DOS monitor and paged memory management |
| US5280599A (en) * | 1989-01-09 | 1994-01-18 | Kabushiki Kaisha Toshiba | Computer system with memory expansion function and expansion memory setting method |
| US5175830A (en) * | 1989-06-16 | 1992-12-29 | International Business Machines Corporation | Method for executing overlays in an expanded memory data processing system |
| US5167030A (en) * | 1989-08-23 | 1992-11-24 | Helix Software Company, Inc. | System for dynamically allocating main memory to facilitate swapping of terminate and stay resident communication program to increase available memory space |
| US5146580A (en) * | 1989-10-25 | 1992-09-08 | Microsoft Corporation | Method and system for using expanded memory for operating system buffers and application buffers |
| US5237669A (en) * | 1991-07-15 | 1993-08-17 | Quarterdeck Office Systems, Inc. | Memory management method |
-
1994
- 1994-03-08 CA CA 2157572 patent/CA2157572C/en not_active Expired - Lifetime
- 1994-03-08 WO PCT/US1994/002523 patent/WO1994020905A1/en not_active Application Discontinuation
- 1994-03-08 AU AU62537/94A patent/AU6253794A/en not_active Abandoned
- 1994-03-08 CN CN94191425A patent/CN1090780C/en not_active Expired - Lifetime
- 1994-03-08 JP JP6520278A patent/JPH08507630A/en active Pending
- 1994-03-08 EP EP94909862A patent/EP0688449A4/en not_active Withdrawn
Also Published As
| Publication number | Publication date |
|---|---|
| CN1090780C (en) | 2002-09-11 |
| CA2157572A1 (en) | 1994-09-15 |
| EP0688449A4 (en) | 1997-08-27 |
| CN1120867A (en) | 1996-04-17 |
| AU6253794A (en) | 1994-09-26 |
| WO1994020905A1 (en) | 1994-09-15 |
| EP0688449A1 (en) | 1995-12-27 |
| JPH08507630A (en) | 1996-08-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3074178B2 (en) | Program module loading and execution method | |
| Liedtke | Toward real microkernels | |
| AU2003279228C1 (en) | Startup and control of graph-based computation | |
| Roscoe | The structure of a multi-service operating system | |
| US6108715A (en) | Method and system for invoking remote procedure calls | |
| US7543301B2 (en) | Shared queues in shared object space | |
| EP0205945A2 (en) | Process transparent multi storage mode data transfer and buffer control | |
| JP2007128538A (en) | Method and computer program product for reducing inter-buffer data transfer between separate processing components | |
| JP2001527234A (en) | Call mechanism for static and dynamic linked functions in an object-oriented controller using a heterogeneous development tool set | |
| US5893159A (en) | Methods and apparatus for managing scratchpad memory in a multiprocessor data processing system | |
| JPH0855035A (en) | Method and equipment for separation of transmission control for microkernel data processing system | |
| JPH0328943A (en) | Overlay management method | |
| CA2157572C (en) | Method and apparatus for allocating memory to reduce conventional memory requirements | |
| US6745389B1 (en) | System of objects and program components | |
| JPS6364133A (en) | Information processing system | |
| JP2888420B2 (en) | Communication method between processes in multitasking architecture | |
| Kougiouris | A device management framework for an object-oriented operating system | |
| US6308147B1 (en) | Data structure synthesis in hardware using memory transaction translation techniques | |
| JPH0855037A (en) | Method and system for interprocess communication | |
| Messer et al. | Components for operating system design | |
| KR0170197B1 (en) | Virtual system for parallel processing of desk in high speed parallel computer | |
| AU2007202782B2 (en) | Startup and control of graph-based computation | |
| KR19980086588A (en) | System Resource Reduction Tool Using TCP / IP Socket Application | |
| JPH02195462A (en) | Information processing terminal equipment | |
| JPH02178856A (en) | Access method for graphic vram in multitask operating system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKEX | Expiry |
Effective date: 20140310 |