I''ve tried converting and compiling the samplebot and botgen code into dlls with Borland. Conversion was fine, although (you may want to be aware of this) I had to change the linkage define as follows #define LINKAGE __stdcall __declspec(dllexport) Anyway, compiles and gets past initialisation fine. kind of anyway. Over in this peice of code extern "C" int LINKAGE QueryBotInterface(const char *iid, IPlayer **iptr) { *iptr = dynamic_cast(new SampleBot); return (*iptr != NULL); } under borland it returns the address happily. My problem is that borland (builder 5 pro anyway - I''m NOT reinstalling an older version, or msvc for that matter unless necessary - new system is a clean system .. except h: and i leaves the memory unshared. I know that, atleast in a standard DLL file you can manually set the memory sharing with a lot of fudging around in DllMain, or just use normal export values (eg if we used IPlayer declspec(dllexport) *iptr; instead), but in the way which has been used in the bot code, is there away around this? This will only leave us with option setting and linking really, but since we aren''t allowed to change the DLL export code, it''s kind of leaving a few of us (or atleast me if your all msvc users) in the lurch. Anyway, if anyone has any idea how to solve this, feel free to tell me. please

I''m not sure I understand the problem/question. Can you elaborate?

okies.

basically there is two stages

first one is easy (for anyone else trying to compile it with a non-ms compiler) using __dclspec(dll_export) won''t export the functions completely as MSVC mangles standard calls.
Adding _stdcall (single _) makes it safe.

This lets the dll export functions work so they can call the functions between MSVC and other compiler DLL files.

Thats the first one.

After that GDARENA can call the functions (such as asking for the core function) without GDARENA saying it can''t find it (similar to running an old version of the bot).


The second part is what I am still trying to work around.
One of the functions in the BOT.DLL that is called by GDARENA.EXE sends is

extern "C" int LINKAGE QueryBotInterface(const char *iid,	IPlayer **iptr){	*iptr = dynamic_cast(new SampleBot);	return (*iptr != NULL);} 

iptr is the data for the Bot that is given back to GDARENA (that or its doing bugger all when it gets there ) that is used by the program for transferring data etc.

Anyway, with shared memory (I researched the problem, but I don''t know of a work around) according to the microsoft Win32 SDK, MS website, Borland documentation and a bunch of websites, shared memory between DLLs has to be used by using a varialble defined with either __export or __declspec(dllexport) if another program is to use it. passing pointers creates problems unless both were written in MSCV. I know borland protects it, and I think most of the others do too unless they use the MSMM which doesn''t do this. some security thing. I read that one of the free compilers is able to get around thing (MING or something) but I have no idea if it can be done with borland.

I''ve also tried code similar to what follows (not cut and pasting - different machines)

IPlayer __declspec(DLL_EXPORT) *player_ex;extern "C" int LINKAGE QueryBotInterface(const char *iid,	IPlayer **iptr){	player_ex=dynamic_cast(new SampleBot);	*iptr = player_ex;	return (*iptr != NULL);} 

Something along those lines anyway.
Basically definning the player data player_ex using an export the way it has in an example in the MS W32 SDK and the Borland Builder DLL help files, then sticking its address in the iptr pointer.

Results are the same in the end, GDARENA locks up and XP asks me to send an error report to microsoft (yes I know I can disable it, but I can''t be stuffed).


Anyway, thats the problem as it stands now. If anyone who has found a way of letting other programs access non-shared memory, I would be quite happy to find out how I''m nearly completely stumped.

Anyway, back to fiddling with it. never know, it may work this time round.

Seeya later

Have you tried using SharedMem.hpp as described in the Borland help files?

yep, still to no avail.

I''ve ended up installing MSVC6 standard again so I can compile the bot (named PlunderBunny - ala Monkey Island 1 and 4) and am using winsock to transfer data to my borland interface.

Works fine, and it means I don''t have to deal with MSVC''s interface (I''m a borland user through and through... Since borland C v2.0 anyway - before then it was gwbasic, qbasic, and batch files. and the tsr80)

The interface doesn''t look the spiffiest, but it does what I want it too.

I''m about to post another thread regarding objDirection, have a look in there if you wish to see what it looks like (nothing special though)

Thanks for trying to help me,
Seeya,
James

mines still shitting itself