there Ive just recently ported ( in the nastiest dirtiest way so far ) sqlite onto another platform - that is AmigaOS version 4.0 ( powerpc ):http://www.os4depot.net/index.php?function=showfile&file=library/misc/sqlite3.tar.gz
However I had to put a health warning on it because in order to get it to work in the limited spare time I have had so far I had to remove all the locking code in os_amiga.c ( ripped straight from the os_unix.c file with a few changes to stop a few clashes in naming of #defined' variables with OS provided ones ) else any operation would just fail saying the database was locked ( which yes probably is something wrong in the C runtime library emulation ). So in order to restore sane locking I wrote an AmigaOS specific version of the os_amiga.c file, but using the Operating System locks built in. Now looking at the windows implementation it does seem to call operating system methods for locking files exclusive or shared, but specifically on a section of the file. The claim that it works over a networked drive has made me start to think that operating system specific locking mechanisms are totally the wrong way to go, and that I have misunderstood the code. Excuse me if this sounds terribly 'newbie'. So, a question, should I NOT be using operating system specific locks ( indeed my attempts to get it to work once I used OS functions to lock the file failed to work in a sqlite friendly way ) and instead be just setting various offsets in the file to certain bitpatterns to indicate to potential sharers what the state is? My implementation is the only one that attempts to store a lock descriptor in struct OsFile also. I have the feeling Ive missed a porting document or something. Anybody can set me straight as to whether or not I should be modifying byte offsets in the file, using OS provided locking systems ( and their semantics ) or should I just sit down with a pen, ignore the calls to the Windows API in the win32 one and try and work it out from the unix implementation? Regards Dave.
