home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / mswindo / programm / misc / 4685 < prev    next >
Encoding:
Text File  |  1993-01-07  |  4.1 KB  |  111 lines
  1. Path: sparky!uunet!pipex!warwick!uknet!pavo.csi.cam.ac.uk!jca17
  2. From: jca17@phx.cam.ac.uk (J.C. Ashworth)
  3. Newsgroups: comp.os.ms-windows.programmer.misc
  4. Subject: Help! Memory Model Genius Required
  5. Keywords: toolbar
  6. Message-ID: <1993Jan7.143025.23771@infodev.cam.ac.uk>
  7. Date: 7 Jan 93 14:30:25 GMT
  8. Sender: jca17@cl.cam.ac.uk (J.C. Ashworth)
  9. Organization: U of Cambridge Computer Lab, UK
  10. Lines: 98
  11. Nntp-Posting-Host: barway.cl.cam.ac.uk
  12.  
  13. I have just discovered that my recent posting about having an all-new 
  14. toolbar library available was a little bit premature and need help to put
  15. things right:
  16.  
  17. I compiled the source code for the library in the large memory model.  To 
  18. test the resulting module, I then wrote an application that used all the 
  19. module's features.  I compiled this application in the large memory model 
  20. too.  Everything worked fine.  But I then compiled the application in the 
  21. small memory model and things were not fine.  Not fine at all, in fact.
  22.  
  23. OK.  Let module A (really my toolbar library) be the result of compiling 
  24. source code in the large memory model and module B (really my test 
  25. application) be the result of compiling source code in the small memory 
  26. model.  I'm distinguishing here between compiling and linking, of course!  
  27. Let Z be the interface for module A #included in the source for both 
  28. module A and module B - standard technique.
  29.  
  30. Now, module A may have several code segments and several data segments, 
  31. right?  And module B is guaranteed to have one code segment and one data 
  32. segment, yes?
  33.  
  34. OK.  Now suppose we link together A and B.  Uh-oh! unless Z is very 
  35. specific about near and far types, there are going to be difficulties.  
  36. And what if Z declares classes (some derived) whose member functions are 
  37. defined in module A's source code?
  38.  
  39. Z is really the interface to my toolbar library - part of it (the part 
  40. which captures all my difficulties) looks like this:
  41.  
  42. _CLASSDEF(TToolbarBtnInfo)
  43.  
  44. struct TToolbarBtnInfo
  45. {
  46.     char * Disabled;
  47.     char * Unpressed;
  48.     char * Activated;
  49.     char * Clicking;
  50. };
  51.  
  52. _CLASSDEF(TBaseWindow)
  53.  
  54. class  TBaseWindow
  55. {
  56. protected:
  57.     HWND HWindow;
  58. public:
  59.     HWND GetHandle(void) { return HWindow; }
  60.     virtual long WndProc(UINT message, WPARAM wParam, LPARAM lParam) = 0;
  61. };
  62.  
  63. _CLASSDEF(TToolbarButton)
  64.  
  65. class TToolbarButton : public TBaseWindow
  66. {
  67.     PTToolbarBtnInfo TheDescriptor;        
  68.  
  69. public:
  70.     TToolbarButton(HWND hwndParent, PTToolbarBtnInfo ADescriptor,
  71.         HINSTANCE hInstance);
  72.     PTToolbarBtnInfo GetInfo(void);
  73.     void SetInfo(PTToolbarBtnInfo ADescriptor);
  74.     long WndProc(UINT message, WPARAM wParam, LPARAM lParam);
  75. };
  76.  
  77. (For non-Borland C++ fans, _CLASSDEF(classname) is a macro that 
  78. typedef's a class according to the memory model that the source is being 
  79. compiled in [near for small and medium, far for compact and huge].  It
  80. also declares a type called Pclassname, e.g. Pchar to allow the declaration of the 
  81. classname pointer type with similar considerations for the memory model.)
  82.  
  83. What changes do I have to make to this code to ensure that my toolbar 
  84. library will be compatible with applications compiled using the small - 
  85. and other - memory models?  And why?
  86.  
  87. Does the TBaseWindow have to be changed as a result of any changes to 
  88. TToolbarButton?
  89.  
  90. Does the TToolbarBtnInfo structure have to be treated in the same way as 
  91. a class - even though it doesn't define any member functions?
  92.  
  93. One other (unrelated but) interesting question: from where does the new 
  94. operator allocate memory? From the heap of course, but can it allocate 
  95. memory from the far heap too - or is it, like most of these things, 
  96. dependent on which memory model it is compiled in?
  97.  
  98. Whoever invented segmented memory wants a bullet in the brain.  I'd be 
  99. happy to oblige.
  100.  
  101. The reason I'm not writing the library as a DLL, by the way, is because I don't
  102. think the size of the final code warrants it. Besides, I'm awkward.
  103.  
  104. PLEASE PLEASE PLEASE send EMAIL on these questions TO   
  105.  
  106. JCA17@phx.cam.ac.uk
  107.  
  108. P.S. I know this is rather long.  I hope it is concise.  I hope it reads 
  109. clearly.  I hope that some guru out there will take the trouble to help 
  110. me out if he has deep knowledge about these matters.  Respect due.
  111.