circa 9/26/02 10:23 AM, Barry Twycross <email@hidden> wrote:
>> The point which makes me wonder is that HLockHi says that I shall not HLockHi
>> Block in the system heap - but this where they go if they are loaded from an
>> ndrv... Or does preload and locked last ?
>
> I don't know about HLockHi, why not just HLock? If the resource is
> marked "System Heap" and "Locked" then it should be safe. If it isn't
> marked System Heap it'll go away whenever what the current
> application is quits, if that's at startup it'll go away at then end
> of the Init parade.
If the resource's pre-load bit is set in the resource file, the resource
will be loaded when the resource's file is opened. If the resource's lock
bit is set in the resource file, then its handle will be locked whenever the
resource is loaded. If *both* the resource's pre-load bit *and* the
resource's lock bit are set, the resource will be loaded into the lowest
possible block of appropriate size and locked there when the resource's file
is opened. Such resource handles won't cause fragmentation, which is why you
would want to move them high, so there's no need to call MoveHHi on them.
(MoveHHi and HLockHi will fail anyway because the handle is already locked,
which prevents it from being moved.)
You probably want your resource handles to survive as long as your driver
does, and your driver's lifetime is independent of the lifetime of any
particular application's heap. [For the purposes of this discussion, you can
pretend the system extension loading process ("the INIT parade") is an
application. (The real story is substantially more complicated.)] So you
probably want your resource handles in the system heap. The simplest way to
ensure this is to set the resource's system heap bit in the resource file.
If for some reason you can't set the resource's system heap bit, you have
two choices. I can't remember what the current heap is when a USB driver is
called at task time, but the system heap would be a good guess. If that's
the case, you could choose to assume that it is always the case. If you're
less foolhardy, uou should call GetZone (to cache the current heap),
SystemZone (to get the address of the system heap), SetZone (to set the
current heap to the system heap), get the resource, and finally call SetZone
again (to restore the heap you cached earlier).
You should also be aware that MoveHHi does nothing if the handle you pass is
in the system heap. This means the best you can do is call HLock, which may
fragment the system heap unless you call ReserveMem, which is even more
busywork than setting the current zone to be the system zone. For this
reason, you should make an effort to enable yourself set both the pre-load
and lock bits for your driver's resources.
Finally, also remember that resources are released implicitly when their
resource file is closed. In order for a resource handle to survive its
resource file being closed, you need to call DetachResource. This
essentially transforms the resource handle into a plain old Memory Manager
handle. After passing a handle to DetachResource, you can no longer pass the
handle to Resource Manager functions, but the handle will exist as long as
its heap does.
I'm a dinosaur for remembering all this stuff.
And now back to your regularly scheduled kernel extension.
--
Pete Gontier -- pete at m-audio dot com -- <http://www.m-audio.com/>
_______________________________________________
usb mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/usb
Do not post admin requests to the list. They will be ignored.
