Hi, Just threw this together as an idea of what we might want to do for abstracting the configuration files out a little, such that it's up to the front end for any given platform to store the data.
See attached. -- Rob Kendrick <[EMAIL PROTECTED]>
Suggestion for config file abstraction interface ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Four calls must be provided, most likely in the frontend's directory of other platform-specific code. These are: 1. const char* Config_Get(const char *key); 2. void Config_Set(const char *key, const char *value); 3. const char* Config_Enumerate(const char *prefix, const char *key); 4. void Config_Free(const char *str); Config_Get ~~~~~~~~~~ This call looks up a key in the configuration storage, and returns the value assoiated with it, or NULL if the key was not found. The Config_Getfunction must allocate the memory to store the value itself. Config_Set ~~~~~~~~~~ This call sets a key/value pair in the configuration storage, overwriting any previous data stored with the same key. Config_Enumerate ~~~~~~~~~~~~~~~~ This call enumerates all the keys in the configuration storage that have the given prefix. It returns the next matching key, or NULL if no more are found. To get the next matching key, pass the previous return value back in as value. value should be NULL on the initial call. This call frees the previous key string automatically for you when you call it again. However, you must call Config_Free on its return value if you give up enumerating before it returns NULL. Config_Free ~~~~~~~~~~~ This call frees memory associated with any string returned from the other calls in the interface. Note that the enumeration call automatically frees its strings unless you bail out before it has returned all matching keys. Implementation Notes ~~~~~~~~~~~~~~~~~~~~ The Config_Free calls exists instead of just asking the user to call the standard C library's free() call as on some platforms with shared objects, different SOs may have different memory management libraries. This is especially true of Windows, where this kind of problem can very rapidly get messy. Futhermore, implementations should make it difficult for users to call free() on the data returned by the other calls, as well as making it difficult for users to call Config_Free on blocks aquired from elsewhere. One possible way of doing this is for the calls to allocate 4 bytes more than they need, fill in the first four bytes with some magic data, and return a pointer to where the string starts. This should make it easy to warn about such errors instantly. Key Namespacing ~~~~~~~~~~~~~~~ As the interface doesn't allow for any specifically stored structure, any structure you wish to apply must be stored in the key part of an entry. It is suggested that we use periods to namespace the keys. For example, a config file might have the following: RAM=16MB ROM=/home/rjek/arcem/ROM ST506.4.Image=/home/rjek/arcem/HardDisc4 ST506.4.Shape=612 4 32 256 ST506.5.Image=/home/rjek/arcem/HardDisc5 ST506.5.Shape=1024 8 32 256 IDEFS.4=/home/rjek/arcem/IDEFS4 HostFS=/home/rjek/arcem/hostfs extnrom.1=/usr/local/arcem/extnrom extnrom.2=/home/rjek/arcem/extnrom X.FullScreen=true OSX.PointlessPrettyness=true The emulator can then find out about the hard discs by enumerating using "ST506." as the prefix. The namespacing by using periods is entirely a convention. The enumerate call returns whole keys, not part of them, so it would return: "ST506.4.Image", "ST506.4.Shape", "ST506.5.Image", "ST506.5.Shape", NULL
