🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.windows.ms.programmer
Article #2289

Far pointers to app data in DLLs; also a question re. preemption.

#2289
From: Mike Leibensperger
Date: Wed, 24 Apr 1991 19:20
51 lines
3000 bytes
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
Technical Details
Message-ID: <23792@oolong.la.locus.com>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!prodnet.la.locus.com!lccma.bos.locus.com!mjl
References: <672462508wkn10109@edmund.cs.andrews.edu> <1991Apr24.141501.12641@mnemosyne.cs.du.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!turnkey!orchard.la.locus.com!prodnet.la.locus.com!lccma.bos.locus.com!mjl
From: mjl@lccma.bos.locus.com (Mike Leibensperger)
Newsgroups: comp.windows.ms.programmer
Subject: Far pointers to app data in DLLs; also a question re. preemption.
Summary: How to best to keep track of app data addresses?  How best to
 relinquish the processor?
Keywords: DLL, far, memory management, memory handles, preemption
Message-ID: <23792@oolong.la.locus.com>
Date: 24 Apr 91 19:20:23 GMT
References: <672462508wkn10109@edmund.cs.andrews.edu> <1991Apr24.141501.12641@mnemosyne.cs.du.edu>
Sender: news@locus.com
Organization: Locus Computing Corp --- Boston office
Lines: 51