🚀 go-pugleaf

I have just discovered that my recent posting about having an all-new 
toolbar library available was a little bit premature and need help to put
things right:

I compiled the source code for the library in the large memory model.  To 
test the resulting module, I then wrote an application that used all the 
module's features.  I compiled this application in the large memory model 
too.  Everything worked fine.  But I then compiled the application in the 
small memory model and things were not fine.  Not fine at all, in fact.

OK.  Let module A (really my toolbar library) be the result of compiling 
source code in the large memory model and module B (really my test 
application) be the result of compiling source code in the small memory 
model.  I'm distinguishing here between compiling and linking, of course!  
Let Z be the interface for module A #included in the source for both 
module A and module B - standard technique.

Now, module A may have several code segments and several data segments, 
right?  And module B is guaranteed to have one code segment and one data 
segment, yes?

OK.  Now suppose we link together A and B.  Uh-oh! unless Z is very 
specific about near and far types, there are going to be difficulties.  
And what if Z declares classes (some derived) whose member functions are 
defined in module A's source code?

Z is really the interface to my toolbar library - part of it (the part 
which captures all my difficulties) looks like this:

_CLASSDEF(TToolbarBtnInfo)

struct TToolbarBtnInfo
{
	char * Disabled;
	char * Unpressed;
	char * Activated;
	char * Clicking;
};

_CLASSDEF(TBaseWindow)

class  TBaseWindow
{
protected:
	HWND HWindow;
public:
	HWND GetHandle(void) { return HWindow; }
	virtual long WndProc(UINT message, WPARAM wParam, LPARAM lParam) = 0;
};

_CLASSDEF(TToolbarButton)

class TToolbarButton : public TBaseWindow
{
	PTToolbarBtnInfo TheDescriptor;		

public:
	TToolbarButton(HWND hwndParent, PTToolbarBtnInfo ADescriptor,
		HINSTANCE hInstance);
	PTToolbarBtnInfo GetInfo(void);
	void SetInfo(PTToolbarBtnInfo ADescriptor);
	long WndProc(UINT message, WPARAM wParam, LPARAM lParam);
};

(For non-Borland C++ fans, _CLASSDEF(classname) is a macro that 
typedef's a class according to the memory model that the source is being 
compiled in [near for small and medium, far for compact and huge].  It
also declares a type called Pclassname, e.g. Pchar to allow the declaration of the 
classname pointer type with similar considerations for the memory model.)

What changes do I have to make to this code to ensure that my toolbar 
library will be compatible with applications compiled using the small - 
and other - memory models?  And why?

Does the TBaseWindow have to be changed as a result of any changes to 
TToolbarButton?

Does the TToolbarBtnInfo structure have to be treated in the same way as 
a class - even though it doesn't define any member functions?

One other (unrelated but) interesting question: from where does the new 
operator allocate memory? From the heap of course, but can it allocate 
memory from the far heap too - or is it, like most of these things, 
dependent on which memory model it is compiled in?

Whoever invented segmented memory wants a bullet in the brain.  I'd be 
happy to oblige.

The reason I'm not writing the library as a DLL, by the way, is because I don't
think the size of the final code warrants it. Besides, I'm awkward.

PLEASE PLEASE PLEASE send EMAIL on these questions TO   

JCA17@phx.cam.ac.uk

P.S. I know this is rather long.  I hope it is concise.  I hope it reads 
clearly.  I hope that some guru out there will take the trouble to help 
me out if he has deep knowledge about these matters.  Respect due.