home *** CD-ROM | disk | FTP | other *** search
/ Programmer 7500 / MAX_PROGRAMMERS.iso / CLIPPER / MISC / WPJV1N.ZIP / ROD.ZIP / ROD.TXT < prev    next >
Encoding:
Text File  |  1993-02-22  |  5.8 KB  |  122 lines
  1.  
  2.  
  3.  
  4.         Accessing Global Variables Across DLL
  5.         --------------------------------------
  6.  
  7.     In lasts months WPJ I wrote an introductory DLL article. This
  8. month I wish to share with the many readers of the WPJ (at least that's
  9. what Pete and Mike keep telling us) of a way that I discovered by necessity
  10. of handling global variables across DLLs. I describe my approach as a 'kludge'
  11. but, to me it is a fairly good 'kludge'. Like anything done against the norm
  12. there are some risks; like receiving flammable E-mail about going against
  13. Windows standards, and possibilities that Microsoft will change some things 
  14. and therefore in later versions my approach will not work. All of these are
  15. possibilities but, I can live with those for now. Why? Because I think that
  16. it is a feasible kludge and what I will show you is nothing that Windows has
  17. not been doing since version 2.0 and it has not changed yet. That is not to
  18. say that they will not change, but that for now it seems safe to say that 
  19. they will not.
  20.  
  21.     Here's some background information on why I chose to use the method
  22. I came up with. Windows already supplies ways of handling global variables 
  23. across DLLs, for instance, shared memory, passing far pointers and redeclaring 
  24. the variables in the DLL. These methods are workable and I strongly suggest 
  25. that they be used. Well, here's the background. I was given the task of
  26. converting two DOS applications over to Windows and making them into one 
  27. package. My mission was to get it up and running as quickly as possible. The
  28. original DOS application made use of numerous global variables. So, I decided
  29. to do a straight port, and after demoing the port and management making their
  30. decision, I would convert the App over to DLLs. Well, the first two steps
  31. (ported and mgmt. decision) were completed 7 months later. So, now the big
  32. job was to fix up everything over to DLLs. This was no problem except for
  33. the numerous global variables. Hind sight told me I was stupid for not 
  34. dealing with them initially. Handling the global variables the way
  35. Microsoft suggests would mean that a great portion of the code would have
  36. to be rewritten, and you know that there just is never any time to do that.
  37. So, I began to think to myself, and I remembered reading about Micheal Geary's
  38. FIXDS. The same logic he applied to not having to call 'MakeProcInstance' also
  39. applied to what I was thinking.
  40.  
  41.     The stack segment (SS) for DLLs is that of the calling application.
  42. And, the calling apps. DS == SS. Therefore, any global variables (CONST and 
  43. BSS) defined in the application is shared with the DLL via SS. The only 
  44. problem is that you have no clear way of accessing those variables. In 
  45. Windows global variables in segments do not change their offsets, only the
  46. segments can be changed due to memory management. Thus, the offset values of
  47. the global variables will always be at the same location inside the 
  48. segment. Knowing this, how do we determine those offsets? The answer is the
  49. MAP file that the compiler will supply for you. The MAP file lists all
  50. global symbols defined in the object file(s), sorted by name and a list 
  51. sorted by address. With this information in hand we can make a file of all
  52. the global variables used in the program. The global list should use the
  53. same case as the actual definitions. Also, since the MAP file sorts the variables
  54. by name and thats what we are looking for, the matching variable names and
  55. their offsets, our list file should be sorted, this will speed the search.
  56. I wrote a utility program that I call "getoff.exe", that searches the MAP
  57. file and creates an output constants file of the variables, i.e.,
  58.  
  59. GLOBAL HEADER FILE    INPUT FILE FORMAT    OUTPUT FILE FORMAT
  60. ------------------    -----------------    -------------------
  61. int variableA;        variableA        #define VARIABLEA 0x0001
  62. int variableB;        variableB        #define VARIABLEB 0x0002
  63. int variableC;        variableC        #define VARIABLEC 0x0003
  64.  
  65. The outputed constant file is to be inlcuded in the DLL modules. 
  66. I forgot to mention one thing. The global variables must be declared inside 
  67. the DLLs also. The cleanest way would be to include them in a
  68. global header file. Now with the use of some in-line assembly code the global 
  69. variables can be accessed and updated inside the DLL.
  70.  
  71.             #include "consts.h"
  72.             #include "global.h"
  73.             .
  74.             .
  75.             .
  76.  
  77.             /* this code sets up the variables inside the DLL */
  78.             _asm    mov    ax, ss:[VARIABLEA]
  79.             _asm    mov    [variableA], ax
  80.  
  81.             _asm    mov    ax, ss:[VARIABLEB]
  82.             _asm    mov    [variableB], ax
  83.             
  84.             _asm    mov    ax, ss:[VARIABLEC]
  85.             _asm    mov    [variableC], ax
  86.     
  87.             /* now use the variables like normal */
  88.             variableC= variableB;
  89.             variableB= variableA;
  90.             variableA= variableC;
  91.  
  92.             /* when finish reasign the values to the global */
  93.             /* variables defined in the application     */
  94.             _asm    mov    ax, [variableA]
  95.             _asm    mov    ss:[VARIABLEA], ax
  96.  
  97.             _asm    mov    ax, [variableB]
  98.             _asm    mov    ss:[VARIABLEB], ax
  99.  
  100.             _asm    mov    ax, [variableC]
  101.             _asm    mov    ss:[VARIABLEC], ax
  102.  
  103.  
  104.     This is all it takes to accomplish the task of using global variables
  105. across DLLs. I created for my companies purposes entry/exit routines that
  106. handle the assigning and re-assigning of the variables, only because our
  107. application has over some 75 to 100 global variables. 
  108.  
  109.     Included with this document is the "getoff.exe" utility and its
  110. source, and source and executable example of a DLL accessing a global
  111. variable. To run "getoff" type 'getoff <mapfile name> <input file>'.
  112. As I stated this is only a kludge, this method should only be
  113. used if you do not have time to rewrite code and you have too many global
  114. variables. If you have the fortunate pleasure of creating your own application
  115. try to stay away from global variables, and if you must handle them the way
  116. Microsoft suggests.
  117.  
  118. Rod Haxton can be reached at (703) 883-0226 or (202) 269-3780.
  119.  
  120.  
  121.     
  122.