gamedevlists-windows

RE: [GD-Windows] GetProcAddress()

[Wayne C. <wc...@re...>]

> Now i've created a function called MyDLLFunc(). If i want to 
> access this
> function in my main app using GetProcAddress() i specify 
> "MyDLLFunc" as
> function name, but this fails. After looking into the listing 
> of the dll i
> gave it a try to use " ?MyDLLFunc@@YAXXZ " as name. That 
> worked. How on
> earth am i supposed to export 20 functions in a decent 
> manner? Look them up
> all up in the listing? I must be doing something wrong. Could 
> anyone help me
> out?

The function is being exported with C++ decoration on the names, the easiest
way to avoid this is by externing them as C functions....

extern "C"
{
	// exported functions....
};

Most headers I've seen wrap the 'extern "C"' in a #ifdef cplusplus or
something similar but as I always use C++ I just put the extern "C" in
there. Enjoy your exporting ;)

Wayne
-Virus scanned and cleared ok

RE: [GD-Windows] GetProcAddress()

[Michael L. <ml...@mi...>]

>Isnt there some way to look into a dll and check what functions it
exports?

From the command line:

dumpbin /exports mydll.dll

RE: [GD-Windows] GetProcAddress()

[Philip T. <pt...@mi...>]

depends, the VS tool, will show this in the "Export Function List View", =
as well as the imports used by a module.

> -----Original Message-----
> From: Michael Lyons [mailto:ml...@mi...]
> Sent: Tuesday, October 16, 2001 11:50 AM
> To: Erwin de Vries; GDWindows
> Subject: RE: [GD-Windows] GetProcAddress()
>=20
>=20
> >Isnt there some way to look into a dll and check what functions it
> exports?
>=20
> From the command line:
>=20
> dumpbin /exports mydll.dll
>=20
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>=20

RE: [GD-Windows] GetProcAddress()

[Michael L. <ml...@mi...>]

Dependencies and exports are not the same thing. Dependencies are other
DLLs that have "exports" that the particular EXE/DLL "imports".

-----Original Message-----
From: Tom Hubina [mailto:to...@3d...]=20
Sent: Tuesday, October 16, 2001 12:02 PM
To: gam...@li...
Subject: Re: [GD-Windows] GetProcAddress()


At 11:38 AM 10/16/2001, Erwin de Vries wrote:
>Isnt there some way to look into a dll and check what functions it=20
>exports?

Right-click on DLL / EXE in explorer ... View Dependencies.

Works in Win2k at least :)

Tom


_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows

RE: [GD-Windows] GetProcAddress()

[Tom H. <to...@3d...>]

At 12:09 PM 10/16/2001, Michael Lyons wrote:
>Dependencies and exports are not the same thing. Dependencies are other
>DLLs that have "exports" that the particular EXE/DLL "imports".

The tool shows exports and imports for DLLs/EXEs in a very nice tree 
format. In other words, it shows you everything. Right click on a DLL and 
check it out :)

Tom

RE: [GD-Windows] GetProcAddress()

[Tom F. <to...@mu...>]

You have to have run the "Depends"/"Dependency Walker" proggie (part of
MSDev) at least once - then it hooks into Windows and gives you that option
when you right-click on DLLs. It's not an OS-specific thing.

Why doesn't it install this hook when you install MSDev? Curious...

Tom Forsyth - Muckyfoot bloke.

What's he up to now (and can I have a go)?
http://www.eidosinteractive.com/downloads/search.html?gmid=86

> -----Original Message-----
> From: Tom Hubina [mailto:to...@3d...]
> Sent: 16 October 2001 20:02
> To: gam...@li...
> Subject: Re: [GD-Windows] GetProcAddress()
> 
> 
> At 11:38 AM 10/16/2001, Erwin de Vries wrote:
> >Isnt there some way to look into a dll and check what 
> functions it exports?
> 
> Right-click on DLL / EXE in explorer ... View Dependencies.
> 
> Works in Win2k at least :)
> 
> Tom

RE: [GD-Windows] GetProcAddress()

[Jon W. <hp...@mi...>]

> Why doesn't it install this hook when you install MSDev? Curious...

Probably for the same reason MSPDB60.DLL doesn't go into your path when you
install.

Cheers,

				/ h+

RE: [GD-Windows] GetProcAddress()

[Grills, J. <jg...@so...>]

I do pretty much the same thing -- I have a render layer that I explicitly
load from a DLL.  One of my problems was that I needed my renderer to be
able to use a few functions out of the application that loaded it (warning
logging, etc).  It's actually possible to have a DLL load symbols from an
executable, but the executable name has to be known at link time.  The
problem I ran into is that I wanted to be able to use this one rasterizer
DLL with multiple executables (the game itself, world builder tools, asset
viewers, etc).  I did some research and ended up using the techniques
involved in hooking DLL functions to actually allow the DLL to rebind the
imported functions into the executable that loaded it.  Very nifty.  If
anyone wants more info, I'd be glad to type some more stuff up.  It took me
several days to figure out this trickery, but in the end it cleaned up a lot
of crufty code.

jefftep
Jeff Grills
Star Wars Galaxies
Technical Director, Austin Studio
Sony Online Entertainment Inc.

-----Original Message-----
From: Erwin de Vries [mailto:er...@vo...]
Sent: Wednesday, October 17, 2001 4:58 AM
To: Gamedevlists-Windows@Lists. Sourceforge. Net
Subject: Re: [GD-Windows] GetProcAddress()


> A perhaps better way of using DLLs is to have each DLL export one factory
> function for the kind of services it implements, and return an interface
> implementing all the services. All function calls into the DLL will then
be
> routed through this one interface. The interface could consist of a simple
> aggregation of a procedural API, or factory functions for the kinds of
> classes the DLL exports, or something fancier (such as something you can
> query for other interfaces by name). In effect, you'd be hand-rolling
> something COM-like, without the additional management/installation
overhead
> of COM.

Yes! Thanks for the idea. I just tested it, and it is exactly what i wanted,
except for the factory create function, but i can obviously live with that.
=) I knew there must be some way to use DLL's in a normal manner.

> Another approach, if you don't need the run-time loading, is to just let
> your app link against the .LIB link library at link time, and reference
all
> the functions directly. This is still a win compared to statically linking
> everything if you expect some parts of the system to rev much more often
> than others.

Thats not what i want, because i want to dynamically link to our renderer.

Erwin

RE: [GD-Windows] GetProcAddress()

[Awen L. <ali...@ed...>]

Another way to do that, is to create a common.dll/core.dll with the common
routines of your application, and your renderer plugin. Mmmh. Am i beginning
to talk about client-server, stuff ?
Anyway, explore the 3dsmax sdk/dlls: a very smart reading when you're diving
into plugin-mechanisms headache :)

-----Message d'origine-----
De : gam...@li...
[mailto:gam...@li...]De la part de
Grills, Jeff
Envoyé : mercredi 17 octobre 2001 18:12
À : 'Erwin de Vries'; Gamedevlists-Windows@Lists. Sourceforge. Net
Objet : RE: [GD-Windows] GetProcAddress()



I do pretty much the same thing -- I have a render layer that I explicitly
load from a DLL.  One of my problems was that I needed my renderer to be
able to use a few functions out of the application that loaded it (warning
logging, etc).  It's actually possible to have a DLL load symbols from an
executable, but the executable name has to be known at link time.  The
problem I ran into is that I wanted to be able to use this one rasterizer
DLL with multiple executables (the game itself, world builder tools, asset
viewers, etc).  I did some research and ended up using the techniques
involved in hooking DLL functions to actually allow the DLL to rebind the
imported functions into the executable that loaded it.  Very nifty.  If
anyone wants more info, I'd be glad to type some more stuff up.  It took me
several days to figure out this trickery, but in the end it cleaned up a lot
of crufty code.

jefftep
Jeff Grills
Star Wars Galaxies
Technical Director, Austin Studio
Sony Online Entertainment Inc.

-----Original Message-----
From: Erwin de Vries [mailto:er...@vo...]
Sent: Wednesday, October 17, 2001 4:58 AM
To: Gamedevlists-Windows@Lists. Sourceforge. Net
Subject: Re: [GD-Windows] GetProcAddress()


> A perhaps better way of using DLLs is to have each DLL export one factory
> function for the kind of services it implements, and return an interface
> implementing all the services. All function calls into the DLL will then
be
> routed through this one interface. The interface could consist of a simple
> aggregation of a procedural API, or factory functions for the kinds of
> classes the DLL exports, or something fancier (such as something you can
> query for other interfaces by name). In effect, you'd be hand-rolling
> something COM-like, without the additional management/installation
overhead
> of COM.

Yes! Thanks for the idea. I just tested it, and it is exactly what i wanted,
except for the factory create function, but i can obviously live with that.
=) I knew there must be some way to use DLL's in a normal manner.

> Another approach, if you don't need the run-time loading, is to just let
> your app link against the .LIB link library at link time, and reference
all
> the functions directly. This is still a win compared to statically linking
> everything if you expect some parts of the system to rev much more often
> than others.

Thats not what i want, because i want to dynamically link to our renderer.

Erwin

_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows

RE: [GD-Windows] GetProcAddress()

[Jon W. <hp...@mi...>]

> logging, etc).  It's actually possible to have a DLL load symbols from an
> executable, but the executable name has to be known at link time.  The
> problem I ran into is that I wanted to be able to use this one rasterizer
> DLL with multiple executables (the game itself, world builder tools, asset

The MacOS and BeOS linkage models allowed a magic name to be used for
linking, meaning "whatever application is loading me". That was very
convenient.

> viewers, etc).  I did some research and ended up using the techniques
> involved in hooking DLL functions to actually allow the DLL to rebind the
> imported functions into the executable that loaded it.  Very nifty.  If

The approach I've ended up using on platforms that don't have the magic host
linkage capability, is simply to configure the interface gotten out of the
DLL with a callback interface.

class SomeDllInterface;

class HostCallbacks {
public:
  virtual void LogAMessage( SomeDllInterface * source, char const * fmt,
... ) = 0;
  ...
};

class SomeDLLInterface {
public:
  virtual void setHostCallbacks( HostCallbacks * cb ) = 0;
  ...
};

This has the benefit of not requiring you to find the main module handle and
start picking out symbols by name from there (although that works, too).

Cheers,

			/ h +

RE: [GD-Windows] GetProcAddress()

[Emmanuel A. <emm...@wi...>]

I'm interested by more info on this stuff...

I'd like to create 'mod' dll that would use the core engine fonction.

For the moment, I'm using Python as the script language, but I will have
to get back to plain C/C++ because our games are distributed by Web, and
I can't afford the extra weight of Python ( about 700 ko ) (sic...).

So any more info would be really appreciated...

Thanks,=20

Emmanuel


> -----Original Message-----
> From: Grills, Jeff [mailto:jg...@so...]
> Sent: mercredi 17 octobre 2001 18:12
> To: 'Erwin de Vries'; Gamedevlists-Windows@Lists. Sourceforge. Net
> Subject: RE: [GD-Windows] GetProcAddress()
>=20
>=20
>=20
> I do pretty much the same thing -- I have a render layer that=20
> I explicitly
> load from a DLL.  One of my problems was that I needed my=20
> renderer to be
> able to use a few functions out of the application that=20
> loaded it (warning
> logging, etc).  It's actually possible to have a DLL load=20
> symbols from an
> executable, but the executable name has to be known at link time.  The
> problem I ran into is that I wanted to be able to use this=20
> one rasterizer
> DLL with multiple executables (the game itself, world builder=20
> tools, asset
> viewers, etc).  I did some research and ended up using the techniques
> involved in hooking DLL functions to actually allow the DLL=20
> to rebind the
> imported functions into the executable that loaded it.  Very=20
> nifty.  If
> anyone wants more info, I'd be glad to type some more stuff=20
> up.  It took me
> several days to figure out this trickery, but in the end it=20
> cleaned up a lot
> of crufty code.
>=20
> jefftep
> Jeff Grills
> Star Wars Galaxies
> Technical Director, Austin Studio
> Sony Online Entertainment Inc.
>=20
> -----Original Message-----
> From: Erwin de Vries [mailto:er...@vo...]
> Sent: Wednesday, October 17, 2001 4:58 AM
> To: Gamedevlists-Windows@Lists. Sourceforge. Net
> Subject: Re: [GD-Windows] GetProcAddress()
>=20
>=20
> > A perhaps better way of using DLLs is to have each DLL=20
> export one factory
> > function for the kind of services it implements, and return=20
> an interface
> > implementing all the services. All function calls into the=20
> DLL will then
> be
> > routed through this one interface. The interface could=20
> consist of a simple
> > aggregation of a procedural API, or factory functions for=20
> the kinds of
> > classes the DLL exports, or something fancier (such as=20
> something you can
> > query for other interfaces by name). In effect, you'd be=20
> hand-rolling
> > something COM-like, without the additional management/installation
> overhead
> > of COM.
>=20
> Yes! Thanks for the idea. I just tested it, and it is exactly=20
> what i wanted,
> except for the factory create function, but i can obviously=20
> live with that.
> =3D) I knew there must be some way to use DLL's in a normal manner.
>=20
> > Another approach, if you don't need the run-time loading,=20
> is to just let
> > your app link against the .LIB link library at link time,=20
> and reference
> all
> > the functions directly. This is still a win compared to=20
> statically linking
> > everything if you expect some parts of the system to rev=20
> much more often
> > than others.
>=20
> Thats not what i want, because i want to dynamically link to=20
> our renderer.
>=20
> Erwin
>=20
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>=20

RE: [GD-Windows] GetProcAddress()

[Brian H. <bri...@py...>]

>>> Jeff Grills

> I do pretty much the same thing -- I have a render layer that 
> I explicitly load from a DLL.  One of my problems was that I 
> needed my renderer to be able to use a few functions out of 
> the application that loaded it (warning logging, etc).

At the risk of sounding stupid, why didn't you just pass those in as
parameters?  Quake3 operates this way -- you load the render DLL and
pass it a refimport_t and receive a refexport_t.  Everybody can talk,
but no one is overly dependent on the other.

Brian

RE: [GD-Windows] GetProcAddress()

[Grills, J. <jg...@so...>]

I did that until I figured out this new technique.  There are also cases
where I need to access data, and in the main game engine the data are actual
objects, but in the graphics DLL they have to be accessed via pointers.
Fortunately, in most cases I was using pointers, and C++ allows you to call
function pointers with normal function call syntax.  Now I have uniformity
of access everywhere.

jefftep


-----Original Message-----
From: Brian Hook [mailto:bri...@py...]
Sent: Wednesday, October 17, 2001 11:59 AM
To: 'Gamedevlists-Windows@Lists. Sourceforge. Net'
Subject: RE: [GD-Windows] GetProcAddress()


>>> Jeff Grills

> I do pretty much the same thing -- I have a render layer that 
> I explicitly load from a DLL.  One of my problems was that I 
> needed my renderer to be able to use a few functions out of 
> the application that loaded it (warning logging, etc).

At the risk of sounding stupid, why didn't you just pass those in as
parameters?  Quake3 operates this way -- you load the render DLL and
pass it a refimport_t and receive a refexport_t.  Everybody can talk,
but no one is overly dependent on the other.

Brian


_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows

[GD-Windows] autodocument max stack usage

[Corrinne Y. <cor...@sp...>]

Is there a way to make Visual C linker output the maximum stack allocation
(including local stack locks and unlocks within function calls) of an entire
linked executable?

I had written an autodocumentation tool that parses source code of all the
modules and generate a worst case estimate of stack usage report. It is
quite accurate for C modules, it works on even local stacks inside
functions, and has trouble estimating stack and memory usage for C++ classes
as there are hidden stack locks and allocations during instantiations and
even executions (if one steps into the assembly and watch all the stack
locks).

Given the compiler and linker would need to know the executable's stack
usage better than a programmer like myself would, I suspect this information
I seek (interactively) should be spittable by the compiler and linker
somewhere.

RE: [GD-Windows] autodocument max stack usage

[Jon W. <hp...@mi...>]

> Is there a way to make Visual C linker output the maximum stack allocation
> (including local stack locks and unlocks within function calls)
> of an entire
> linked executable?

I take it you're not a fan of alloca() :-)

Unfortunately, pretty much any executable will link against the standard C
library, which uses recursion in parts, so even if your program doesn't use
recursion, there's no way of proving that your stack size is enough (and no
way for a tool to report on potential maximum stack usage).

Cheers,

				/ h+