Hi all,
I've been scratching my head over this problem for what seems like an age.
Basically, I'm working on a complete, start from scratch, rewrite of our competition entry from last year. One of the issues we had was with the scripts executing a little too slowly causing everything to just go *clunk* stop *clunk* start again.
Now, my cunning plan to stop this, is to put the 'scripts' in a DLL and have the IDE generate the source for this DLL which can then be compiled and loaded by the play engine. Sounds great doesn't it ;-)
One of my favourite mechanisms for data storage is INI files. I already have an INI implementation that is totally memory based, so its nice and fast, BUT, it relies on TStringList so I can't use this to pass data across the app/DLL boundary.
So, I've created a new variety of TStringList called TExposedStringList. This is basically is a rewrite of TStringList, but with some subtle differences. Where TStringList uses private variables (fCount, fList, fDuplicates etc.) these are held in a packed record in memory by TExposedStringList. This allows me to create an instance on one side of the boundary, and simply pass across a pointer to this data structure allowing an instance on the other side of the boundary to connect to this datastore.
This is then used as the basis for my new favourite toy... TExposedMemoryINI. This basically uses one of my TExposedStringLists to hold the list of sections. The section name is in the items and the list of keys is created by creating an instance of TExposedStringList and stuffing its datastore pointer into the sections objects list. I can then detach the object from its datastore and free it so the object gets cleaned up, but the data store remains intact.
All of this is working great in isolation. But its not so hot when I actually use it as its going to be used in the finished product.
I create an instance of TExposedMemoryINI, write a string into it, load a DLL, pass its data store into the DLL, which reads the value I just wrote into it and then proceeds to write another value in and read it back. I then drop out of the DLL, read the value I wrote into the INI inside the DLL, free up the INI and finally unload the library.
The first run through is sweet. No problems whatsoever.
The second run (and all subsequent runs) however, I get an access violation when I try and read the value written into the INI by the DLL.
The problem goes away when I build the exe and library with ShareMem.
So, my question is this... if I'm using getMem and freeMem for all my memory allocation/deallocation, and I'm only transferring strings using pchars (with data allocated by getmem)... why is it that this problem occurs?
Any thoughts, comments or suggestions? I know its a bit tricky without source code, but I've followed the instructions about shared memory and long strings and I am using pointers only, so I just don't get it.
Bookmarks