Sorry your browser is not supported!

Hi all. Been a while since I've posted on here, but I've got a question regarding the DGSDK. Basically, I've converted all my XScape source over to use the DGSDK instead of what used to be the interface library based on the DBP core DLLs. All well and good, and so far, the conversion worked without a hitch.... until it came to XScape's plugins.

I won't bore you with the mundane details for plugin architecture except that they are DLLs. The problem is that linking EXE projects with the DGSDK static libaries is great, but I can't do the same for my DLL projects because it appears that 'Core.lib' already contains a DLLMain entry point. Now I can appreciate that the static libs were basically modified versions of the existing DBP core libraries, but can the redundent DLLMain entry be hash defined out of the compile process if they are being generated as static libs for the DGSDK.

Also, can someone provide me a solution that will allow me to compile my normal XScape plugin DLLs which reference the static libraries without having linker conflicts with DLLMain.

Cheers guys.

Paul.

[EDIT] It occurred to me that even though linking to static libraries in a DLL is possible, there should be an additional function available in the libraries that allows for a GlobalStruct *g_pGlob value to be set via the DLL. The application that invoked the DLL, i.e. my XScape plugin would then be responsible for setting this *g_pGlob pointer to the same one that was issued to the original EXE. Hence all DLLs would still use the same Global structure and function pointers etc. Surely this is possible? Mike, Lee, anyone.

As you've discovered DarkSDK cant be used in DLL's - due to DLLMain...

I'm not sure of an easy way around it - the usual thing to do is to /ignore libraries or modify the order the modules are compiled it - however I dont think that works in this case. LIBC especially cant be ignored...

Yeah I agree, I'm just confused as to why there would be a DLLMain entry point in static libraries. Surely this would only apply to DLL compiled files for the DBP system. In this case, it only needs to be #define'd out of the build. The core libraries must have a WinMain entry point since void DarkSDK( void ) is the entry point for our EXEs. If we are to use DLLs, it's only important that the EXE that instantiated the DLL, passes the pGlob structure from the main EXE, to the DLL, e.g. via a required default exported function from the DLL called

void SetGlobPtr( GlobStruct *pGlob );

I did try to ignore the core.lib file as part of the DLL build but this IMO isn't a good idea anyway, since there are other global dependencies that the other static libraries depend on.

If Mike could make a minor modification that applies to the above hypothesis, this would solve the problem. Release 1.1.2 or something.

Paul.

I will add defines to ensure anything related to DLLs aren't included in the source.

Fantastic Mike, many thanks. I look forward to the update

Paul.