Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!timbuk!cs.umn.edu!uc!noc.MR.NET!msi.umn.edu!umeecs!umich!ox.com!tbomb.ice.com!time
From: time@tbomb.ice.com (Tim Endres)
Newsgroups: comp.sys.mac.programmer
Subject: Re: RAM DRVRs, resLocked, dNeedLock
Message-ID: <1CE00001.e5yoxt@tbomb.ice.com>
Date: 25 Jan 91 01:55:41 GMT
Reply-To: time@ice.com
Organization: ICE Engineering, Inc.
Lines: 31
X-Mailer: uAccess - Mac Release: 1.0.5+


In article <1991Jan22.230133.19377@midway.uchicago.edu>, martin@cs.uchicago.edu writes:
> I'm unclear about the relationship between RAM DRVRs, resLocked, and
> dNeedLock.  Specifically:
> 
>     Does a resLocked DRVR effectively have dNeedLock?
>     Does a dNeedLock DRVR effectively have resLocked?
>     Isn't a DRVR always locked anyway between OpenDriver and CloseDriver?

RAM drivers and ROM drivers have only one difference:
	RAM based drivers are expected to provide a HANDLE in the dCtlDriver
    field of the driver control entry. ROM based drivers are expected
    to provide a POINTER in the dCtlDriver field.

	The driver control entry field "dCtlFlags" RAM-Based bit determines
    whether or not the driver is RAM based (1) or not (0).

    As for the dNeedLock bit, if you are ROM based, set this bit.
    This tells the Device Mgr to not lock the driver code. If you
    are RAM based un-set this bit, so the Mgr knows to lock you down.
    This is not intuitive, and you have to read the comment on page
    II-188 very carefully.

    Don't worry about the ResLocked bit.

tim.

-------------------------------------------------------------
Tim Endres                |  time@ice.com
ICE Engineering           |  uupsi!ice.com!time
8840 Main Street          |
Whitmore Lake MI. 48189   |  (313) 449 8288