Mike and or Lee, and the general interests of people who are willing to provide information
I've created this thread in the hope that some very cool information can be obtained and used for the greater good of us mere C/C++ and .NET developers. Suffice to say, there is some information that would be extremely useful to know, if either Mike, Lee or anybody familiar with the codebase, can answer.
Now, it's known that the DGSDK is a derived set of static libraries generated from the DBP core DLLs. The libs also have a WinMain entry point which Windows calls to fire up our DGSDK application. Now what I would like to know, is if the WinMain function embedded in the lib files, calls a series of initialisation functions which WE can call ourselves? For example, the WinMain function must call a function to create the single GlobStruct object shared by all the other libs. The WinMain creates a windows class and sets it to the default size etc, but then what functions does it call to initialize the rest of DGSDK? If there is a single function, or maybe two or three, are they available to call if the libs are placed into a DLL which has it's own entry point so that the DGSDK can be initialized this way.
Also, if the init functions are available, would it not be logical to assume that they are called in a similiar fashion by the DBP compiler when it creates the .EXE stub? My thinking is that if DBP DLLs, more specifically DBProCore.dll can be loaded dynamically at runtime from another EXE (say a .NET app using DLLImport) Is there an init function(s) that can be called to fire up the DBP dlls. I assume that there's a SetupDLLs function in DBProCore.dll which scans the working folder, generates a list of DLL files and probes each DLL for the Constructor function? The DBP compiler parses the source code, therefore knowing which DLLs the EXE stub requires based on what commands were used in the code.
If either one of you guys can specify which function or functions is used to initialize the core system, either for DGSDK or DBP dlls. This will prove invaluable for making the dlls accessible from .NET and other platforms.
Now, I will stress that this is not a ploy to try reverse engineer or anything sinister. I've been a loyal member of the forums for a few years now and have contributed to some extent in the development of tools for DBP and the DGSDK, so if you've followed what I've written above, you'll probably see where this is leading. Especially for .NET users.
Many thanks guys.
Paul.
Home of the Cartography Shop - DarkBASIC Professional map importer
