GlobalAlloc, CoTaskMemAlloc ??? Advice needed

[jeroen brouwers]

Hi,

I'm getting lost. I'm reading stuff on the forum but I don't know what to conclude.

What I need is this: I have several Dlls that I (preferably) load dynamically (LoadLibrary). Even if this is not used, I would like to keep the code in a seperate dll (if possible).
Anyway, I need some global data that are available for all threads in my program, for all dlls.

This is called Memory Mapping I believe but I also saw something on CoTaskMemoryAlloc that could also be used for this.... I don't know for sure if I'm understanding this right though.
I already use this function to pass a UDT to a (inner-process) thread. I thought this was 'local' to the instance of the DLL, i.e. the thread (as seen from IIS) of my app.

The be exact: My app is running within IIS and linked via an ISAPI extension. I 'initialise' my app by a command that loads all variables into memory. The data mostly come from a database and are static during the running of the program. Updates to these variables would be done by shutting down IIS and restarting the app.
I basically pass the content of a table to an array which I would like to have available.


Hope someone can help.

Regards
Jeroen Brouwers



------------------

[Michael Mattias]

well,a memory-mapped file is certainly one way to go. see the win sdk calls "createfilemapping" and "mapviewoffile" for more info, and for code, you can check this out:
http://www.powerbasic.com/support/pb...ad.php?t=23001 ]http://www.powerbasic.com/support/pbforums/showthread.php?t=23001[/url]

but in your case, it might be easier to write functions into the dll to explitly retrieve the "global" datanames your main program needs.

$compile dll
...
  global a as long, b as short


function libmain....
  baddabing, baddabang, baddaboom
end function

function geta () export as long
  function = a
end function

function getb () export as short
 function = b
end function

function realfunction () export as reallong

  (do stuff to keep a and b current)

end function

your main program now uses a function instead of a global when it needs the data.

mcm



[this message has been edited by michael mattias (edited august 31, 2001).]

[jeroen brouwers]

Thanks Michael! That's a really good idea. I'm gonna try it right away!

Please explain one more thing:
I read in Rector & something that Global Heaps and Local Heaps are essentially the same for win32 (as compared to win16), but maybe I misunderstood.

The subject for me is: memory allocation, how and to whom?
Please explain if I use the terms right and how it would be done. I'm trying to learn the different options.

1) application level : all instances of the process, so also to the threads that are created from within this progress.
For instance, a multi-user app can have many instances (i.e. calls from clients) and threads are part of the program.
How do you allocate 'global' memory for the complete application, all it's instances and threads.
I would expect something like GlobalAlloc, GlobalHeap or Memory mapped files / resources.

2) dll / exe level: all 'global' data that are present for all instances of the piece of program as well as to all threads. Data are not shared with other program, even when explictly linked (i.e. declare function x lib a.dll ...)
These would be GLOBAL variables.

3) inter-application level: I read that it is even possible to allocate memory that is excessible from other applications.
This is where I get confused. Is this where you use GlobalHeap and is option 1 then LocalHeap
I'm thinking of an example in the lines of a CGI application that is copied all the time but can use 'global' data that are available to all. Or a set of independent app's that share data, i.e. memory is loaded once.

The confusion is where to use what.
Also, where does CoTaskMemAlloc fit in??

If you could spare the time to explain a little....? The start is always the most difficult.


Kind regards,

Jeroen



------------------

[Michael Mattias]

I never use CoTaskMemoryAlloc. I rarely even use the Global/Heap/LocalAlloc functions, as I prefer to let the compiler handle it.

Windows(r) memory handles as well as the corresponding addresses (the "VARPTR" or "STRPTR") from the "xxxAlloc" functions are common to all threads within a process. They are not usable outside a process unless you take some special steps when creating that process (beyond scope of this note).

However, datanames referring to handles are limited to the current defined scope (LOCAL, STATIC, GLOBAL) of what is compiled at a single time.

Since a DLL is compiled separately, you cannot share data BY DATANAME with a separately-compiled exe or dll; but you CAN pass a Windows handle as a parameter to a function in that DLL in the same process. However, if you have multiple processes call that DLL, the passed handle is only valid when the DLL is called from the process in which it was created.

That's it.

MCM

[jeroen brouwers]

Thanks Michael, I'll have a look further into it.

BTW, the 'trick' with Set and Get (which I completely overlooked!!) works great.

Thanks
Jeroen

------------------

[Michael Mattias]

BTW, the 'trick' with Set and Get ....

If something works, it's a 'technique.'

It's a 'trick' when it fails in some situations.

MCM

[jeroen brouwers]

Good one!

In the analogy of 'if a bug produces interesting results, it's a feature' (courtesy of MS).

Regards
Jeroen

------------------