Tony, when you build any of the DLLs in Delphi/Pascal do you actually specify to the compiler that it must "link" your DLL to the WinHarpoon32 executable? I tried to obtain via cdecl the pointer to the function lists (using Mingw, not MSVC) and had no luck... then tried using dumpbin and a few other tools to inspect the executable to see if I was missing something but couldn't find anything there to help me.

 

I will try later today a few other tricks, however I was curious with regards to the building process and decided to ask you. I know you're busy with other more interesting priorities... don't want to sound like a pushy guy with that C sample code... I can wait :-)

 

THanks again

-E

Enrique,

 

I think you have the process somewhat backwards, you would interrogate a DLL for which functions it exports, not the GE (Winharp32.exe).

 

Here is a link to my old (and outdated) C example DLL for visual studio (2008). It might give you a starting point but it doesn't have the more capable exports worked in. I imagine you can glean the other exports from the Pascal code.

Hi Tony, thanks for your reply. I definitely think I got it wrong. Since I couldn't see/find a particular DLL to ask for "symbols", I imagined the process was something like this:

Winharp32 being a 16bit application, used the rather old Windows API "__export" function to expose it's inner functions to the outside. It then would look in the "ExportDLL" directory for any existing DLL files. It would then load these available DLLs at runtime (that is, they would share the same Winharp32 process memory... specially since working with the stack due to the use of cdecl is a "delicate" issue), and then I would be able to "talk" to the GE via its exposed functions using the cdecl.

 

Maybe I went a bit too far with this and should have asked you first... but I remember doing this in the past (specially in the UNIX world). As a matter of fact, my initial intention is to get these Winharp32 internals exposed through an TCP socket (or through a less stateful UDP implementation if the case requires it).

 

So please... let me know how bad I got the way it works!!!

 

Also... you forgot to include the link to your C example

 

Thanks again Tony! Take care

-E

Oops, http://harpgamer.com/downloads/HCDLLv2.zip

Hehe, Winharp32 , 32-bit application not that names haven't lied before but in this case it doesn't.

 

I'm wondering if your memory is a bit hazy, __export would be used in the DLL, not the GE so you are consistently backwards anyway . My example uses a .def file instead of __export to list the exports.

 

My HC Remote Viewer ran a TCP server in the DLL that was accessed by one or more client applications http://www.matrixgames.com/forums/fb.asp?m=1507362 . That post also shows the Google Earth ExportDLL which runs a little http server in the DLL that serves .kml files to Google Earth via network link.

 

Yes, the DLL's are in the memory space of the GE but that is just how DLLs operate.

I'm wondering if your memory is a bit hazy

You can bet a million bucks on that! Hazy and fubar due to the lack of sleep the last few weeks

 

I misread your post with regards to the 16-bit limitations... it's now clear to me that it's about the SE not the GE! My bad.

 

Btw, I remember doing what I mentioned in my post above both in SCO (using it's C compiler) and in Visual C++ (VC6 not .NET, long ago tho')... you actually just made me Google such a thing because I swear I'm not nuts

 

So here goes:

 

http://stackoverflow.com/questions/594703/exporting-class-from-executable-to-dll/597344#597344

 

Errata (yeah, another): I meant to say "a more stateful UDP" in my last post... I cannot imagine an even less stateful UDP

 

Anyway, I will take a look at your sample code... thanks again! I promise to write here only after my caffeine levels have become nominal, not before!

 

-E

Tony, just to let you know that your C sample worked great under Qt/Mingw. Next will be to translate the samples in Pascal to C.

 

Thanks for the help!!!

-E

Great Enrique! If you start to write code that really does something make sure to use the StartGroup pointer to grab unit and group information and not the SLOW UnitAlt, UnitSpeed, UnitLatLon, etc. calls. A solid approach is to note StartGroup when it is called and operate on any Groups/Units in the GameTime call. The GE will lock during the GameTime call for you to do any operations that you want to do each game second.

Expose the Harpoon events. These are things like Intercept events, path changing events, sinking events, and many more. These events are really the heart of the game.

These have been exposed in 2009.087 and the related structures have been defined in uHCTypeDefs.pas in the StratsimsOSS SVN repository. I don't have the lazGUI example ExportDLL updated yet though (it is started but far from complete). Feel free to take a look at the code as always.

Looks like August is a good month

Hi Tony, quick question for you: does the current version of the ExportDLL allow the control of sub-units, like a cruise missile for example?

Yes, Missiles and Aircraft work in a similar manner, a single Aircraft unit may have an aircraft quantity > 1.

 

Look at Unit->Air

 

HomeUnit 0x0226c610 Unit *

Endurance 46803 long

DropTanks 5308 long

PlatStart 2 '' unsigned char

PlatNow 2 '' unsigned char

Ammo_c 0 unsigned char

Throttle 1 '' unsigned char

DATA 205 'Í' unsigned char

OATA 205 'Í' unsigned char

 

Endurance should be seconds at Cruise though I haven't verified it works correctly in any regimes, let alone all regimes. Same with DropTanks.

 

Sorry I haven't posted the next build yet, I'm having a very difficult time enabling the GE and DLL to both be responsive while the DLLs are doing heavy computations. Well, that works but lots of nasty crashing happens if you try to close the GE when the DLL has everything stopped up (reentrant windows message processing).

Implemented: Expose the Harpoon events. These are things like Intercept events, path changing events, sinking events, and many more. These events are really the heart of the game. (2009.088)

 

Implemented: Ability to pause the game so that the game structures will be in a consistent state for the DLLs to do processing. The DLLs should register with a callback function so that each DLL can have exclusive use of the game data structures when it requests and prevents other DLLs from modifying the structures at the same time. Without this capability, each ExportDLL cannot be sure a unit, group, etc. will still exist or be in the same state when the DLL starts and finishes operating on that item (and bam, crash the GE).(2009.088)

lazGUI has been updated and the updated source code has been checked in. See the GameTime tab for an example of working some of the magic.

Implemented: Fix the del_HarpoonEvent_list function pointer so that it actually points to the right function (2009.089)

 

Sorry for any confusion this caused, del_HarpoonEvent_list was actually pointing to DisposPtr in earlier builds. The only real affect would have been some memory leak but still...

Implemented: Allow the DLL to say that it wants to over-ride each of the GE "effects" individually. Effects are things like MoveUnits, Submarine AI, Weather, ... The first DLL to over-ride each effect will be the only one to do so (so you won't be able to have two DLLs successfully MoveUnits).(2009.089)

 

Implemented: Allow the DLL to call each stock GE "effect". This is for if you write a DLL and want to re-order the effects processing, throw them into threads, add additional effects, or whatever else.(2009.089)