In article <[EMAIL PROTECTED]>, Alan Pinstein <[EMAIL PROTECTED]> wrote:
> I am having a problem nailing a bug, and would like some help with the > way the OS deals with ROM-based chunks... > > I am on OS 3.5, and using a chunk of code as a plugin. This bug only > occurs when the plugin DB (a resource DB containing this chunk of code) > is in FLASH ROM. I am using FlashPro 1.08. > > The code works like this: > > DmOpenDatabase(...); > gH = DmGetResource(...); > gP = MemHandleLock(gH); > err = DmProtectDatabase(dbR, true); // for FLASHED plugins, this returns an ERROR! > DmCloseDatabase(dbR); > > Then, later on, in the code that FREES the plugin chunk, I get the error: > > MemHandleUnlock(gH); // error occurs here, either 'Invalid Handle' or 'Free Handle' > DmReleaseResource(gH); > > The OS docs say that if you want to keep a record locked in a closed > database to PROTECT the DB so that it won't be deleted and thus pull > your data out from under the pointer. Is this a legitimate use of > DmDatabaseProtect()? > > I make the assumption that a pointer to a locked record in a closed > DB will be fine. Is this a valid assumption? Or does the memory > manager unlock records upon DB closing? It is my understanding that > this is generally how HackMaster works, by keeping a ptr to a locked > code resource after closing the db... > > If the above assumptions are correct, and what I'm trying to achieve > is legitimate, then what is going on which makes the handle invalid, > or free? I would appreciate any explanations, debug strategies, etc. > I am at a total loss. >From the Palm OS Companion: <http://www.palmos.com/dev/tech/docs/palmos/FilesAndDatabases.html#925007> "A special situation occurs with ROM-based databases. Because ROM-based heaps use nonmovable chunks exclusively, the local IDs to records in a ROM-based database are local IDs of pointers, not handles. So, when an application opens a ROM-based database, the data manager allocates and initializes a fake handle for each record and returns the appropriate fake handle when the application requests a record. Because of this, applications can use handles to access both RAM- and ROM-based database records." So it looks like these fake handles are freed, when you close the DB. This would explain, why you can't unlock the handle, when you want to free the plugin, because there is no handle there at that time. The documentation about DmDatabaseProtect says nothing about ROM-based DBs except, that it lists dmErrROMBased as a possible error return value. This leads to the assumtion, that ROM-based DBs can't be protected. Why should they be protected anymay, since they are in ROM and can't be deleted (ignoring the fact that FlashPro exists). You probably have to deal explicitly with the situation, that your plugin is in ROM (FlashPro or a special ROM version). But to test if your plugin is in ROM or not in a supported way, is not that easy. You could test, if the local id of your DB is a handle or a pointer with MemLocalIDKind, or you could check, if the heap of your DB is ROM-based with MemHeapFlags. Hope this helps. -- Remo Hofer <[EMAIL PROTECTED]> http://www.geocities.com/SiliconValley/Cable/5206/ -- For information on using the ACCESS Developer Forums, or to unsubscribe, please see http://www.access-company.com/developers/forums/
