Berkeley DB Reference Guide: Windows notes

Berkeley DB Reference Guide:
Building Berkeley DB for Windows systems

Windows notes

Berkeley DB does not support the Windows/95 platform.
Berkeley DB does not support replication on the Windows/98 or Windows/ME platforms.
On Windows/98 and Windows/ME, files opened by multiple processes do not share data correctly. For this reason, the DB_SYSTEM_MEM flag is implied for any application not specifying the DB_PRIVATE flag, causing the system paging file to be used for sharing data.
On Windows/98 and Windows/ME, removing or renaming a file using the DB_ENV->dbremove, DB_ENV->dbrename, DB->remove or DB->rename methods may fail if another thread of control has the file open for any reason, including checkpointing or flushing pages from the underlying shared database environment cache. There is no workaround for this problem other than re-attempting the operation after the other thread of control has closed its Berkeley DB handles.
On Windows, system paging file memory is freed on last close. For this reason, multiple processes sharing a database environment created using the DB_SYSTEM_MEM flag must arrange for at least one process to always have the environment open, or alternatively that any process joining the environment be prepared to re-create it.
If a system memory environment is closed by all processes, subsequent attempts to open it will return an error. To successfully open a transactional environment in this state, recovery must be run by the next process to open the environment. For non-transactional environments, applications should remove the existing environment and then create a new database environment.
When using the DB_SYSTEM_MEM flag, Berkeley DB shared regions are created without ACLs, which means that the regions are only accessible to a single user. If wider sharing is appropriate (for example, both user applications and Windows/NT service applications need to access the Berkeley DB regions), the Berkeley DB code will need to be modified to create the shared regions with the correct ACLs. Alternatively, by not specifying the DB_SYSTEM_MEM flag, filesystem-backed regions will be created instead, and the permissions on those files may be directly specified through the DB_ENV->open method.
Applications that operate on wide character strings can use the Windows function WideCharToMultiByte with the code page CP_UTF8 to convert paths to the form expected by Berkeley DB. Internally, Berkeley DB calls MultiByteToWideChar on paths before calling Windows functions.
Various Berkeley DB methods take a mode argument, which is intended to specify the underlying file permissions for created files. Berkeley DB currently ignores this argument on Windows systems.
It would be possible to construct a set of security attributes to pass to CreateFile that accurately represents the mode. In the worst case, this would involve looking up user and all group names, and creating an entry for each. Alternatively, we could call the _chmod (partial emulation) function after file creation, although this leaves us with an obvious race.

Practically speaking, however, these efforts would be largely meaningless on a FAT file system, which only has a "readable" and "writable" flag, applying to all users.