[comp.windows.ms.programmer] Far pointers to app data in DLLs; also a question re. preemption.

mjl@lccma.bos.locus.com (Mike Leibensperger) (04/25/91)

Greetings!

I'm about to embark on writing a DLL that must keep track of various
data addresses in application data segments across task preemptions.
Basically the app will pass me a far pointer to some data buffer, and
my DLL will do some processing, followed by a "mini message loop"
preemption point to allow other tasks to run, followed by some more
processing and finally a return to the app.

I seek your collective wisdom on two points:

1)  What's the best way to keep track of the far data pointers, given that
    Windows may "reshuffle" the app's memory while its task is preempted?
    My current plan is to obtain the memory handle using LockSegment() and
    maintain the pointer as a <handle, offset> pair within the DLL, locking
    it as necessary.  For example,

		LPSTR lpAppDataPtr;
		HANDLE hAppDataHndl;
		WORD wAppDataOffset, seg;
		...
		wAppDataOffset = LOWORD(lpAppDataPtr);
		hAppDataHndl = LockSegment( seg = HIWORD(lpAppDataPtr) );
		/* Check for error return from LockSegment() */
		/* and possibly... */
		UnlockSegment(seg);

    Is this the approved method for doing what I'm trying to
    accomplish?  Is there a better way?  Oh how I long for a flat
    32-bit virtual address space....

2)  Does anyone know of any better documentation/have any better advice
    on how to write preemption points than that given in Petzold's
    discussion of abort procedures in chapter 15?  I want to write
    an internal DLL routine PreemptionPoint() that will give up
    control of the processor to another task without altering the
    state of the application message queue (i.e. without having to
    post a bogus "awake from preemption loop" message and then
    waiting for it to appear in a PeekMessage()/WaitMessage() loop).

I'm new to Windows so please don't kill me yet.  (Besides, Gates et. al.
are already inflicting more than enough pain.)

Thanks mucho in advance with sugar on top.

	mjl
--
Michael J. Leibensperger <mjl@locus.com>       "None are so deeply enslaved
Locus Computing Corp./Boston			as those who falsely believe
25 Burlington Mall Road				they are free."
Burlington MA 01803, (617)229-4980 x169			-- J. W. von Goethe