gamedevlists-windows — List for discussing game development on the Windows platform

RE: [GD-Windows] directx installer

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

when its released, the DX 8.1 redist retail installer will install no =
retail bits on WXP, since WXP has 8.1 retail built-in.

if you arent using our installer, or DXSetup APIs, you can detect WXP =
and do nothing for DX 8.1.

> -----Original Message-----
> From: Andrew [mailto:an...@aw...]
> Sent: Friday, October 26, 2001 8:49 AM
> To: gam...@li...
> Subject: [GD-Windows] directx installer
>=20
>=20
> hiya!
>=20
> so we gotta have some detection in our installer so we can=20
> decide whether to
> install the win2k DX file or the
> win95/98/me version...sorta sucks but I put it in there...
>=20
> now what about windowsXP?  According to MSDN its windows=20
> version 5.1(win2k
> is version 5.0 and win9x/me is version 4.x)... so it looks=20
> like windowsXP
> will use the win2k DX installer
>=20
> can anybody confirm? :))
>=20
> Andrew
>=20
> =
=3D---=3D---=3D---=3D---=3D---...---=3D---...____________________________=
_
> ______________
> __
> The next two parts are using full processor time so there is=20
> no music -
> wish/majic12
>=20
>=20
>=20
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>=20

RE: [GD-Windows] directx installer

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

I would have a look at the "DirectSetup" portion of the DX8 docs. :-)

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: Andrew [mailto:an...@aw...]
> Sent: 26 October 2001 16:49
> To: gam...@li...
> Subject: [GD-Windows] directx installer
> 
> 
> hiya!
> 
> so we gotta have some detection in our installer so we can 
> decide whether to
> install the win2k DX file or the
> win95/98/me version...sorta sucks but I put it in there...
> 
> now what about windowsXP?  According to MSDN its windows 
> version 5.1(win2k
> is version 5.0 and win9x/me is version 4.x)... so it looks 
> like windowsXP
> will use the win2k DX installer
> 
> can anybody confirm? :))
> 
> Andrew
> 
> =---=---=---=---=---...---=---..._____________________________
> ______________
> __
> The next two parts are using full processor time so there is 
> no music -
> wish/majic12
> 
> 
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> 

[GD-Windows] directx installer

[Andrew <an...@aw...>]

hiya!

so we gotta have some detection in our installer so we can decide whether to
install the win2k DX file or the
win95/98/me version...sorta sucks but I put it in there...

now what about windowsXP?  According to MSDN its windows version 5.1(win2k
is version 5.0 and win9x/me is version 4.x)... so it looks like windowsXP
will use the win2k DX installer

can anybody confirm? :))

Andrew

=---=---=---=---=---...---=---...___________________________________________
__
The next two parts are using full processor time so there is no music -
wish/majic12

RE: [GD-Windows] autodocument max stack usage

[Roland <ro...@wi...>]

> -- So, back to the _TOPIC_. Is there a linker output for
> it, or not. (even
> on the module level).

I don't know, if there's a linker output for it... (now I'm gonna get
flamed...:-))... but ....

I did a little app a while back, where I totally removed the C runtime
from the final executable. (The purpose was to get a tiny tiny Win32
app). Without linking to the C runtime, I had to implement all runtime
functions used myself or let the compiler generate intrinsic
functions. Somehow there was one function missing in DEBUG or RELEASE
builds (don't remember which one it was, but I guess it was DEBUG):
_chkesp()

I looked at the assembly source and as far as I know this function was
called on almost every function leave. I think it's used to verify
that a function didn't mess with the stackframe...

Below is my implementation to get the linker happy, but I think you
might blow this function up a bit and monitor the ESP/EBP contents a
get some idea on stack usage from that...

Just a thought
roland


SmallIO.cpp:
.....
extern "C" {
__declspec(naked) void __cdecl _chkesp(void)
{
    _asm
    {
        ret 0;
    }
}
};
.....

[GD-Windows] _heap_term

[<cas...@ya...>]

Hi,
when i unload a dll with FreeLibrary I always get this error with bounds
checker:

Invalid argument
HeapFree, HANDLE: 0x##..##
Bad handle.

the stack trace is the following:

FreeLibrary
_DllMainCRTStartup
_CRT_INIT
_heap_term

and the function that causes the error is:

HeapFree(_crtheap, 0, __sbh_pHeaderList);

where _crtheap is supposed to cause the error.

This happens with all the dlls that have been created by my (not with
external dlls) and even with a minimal dll that does absolutely nothing. The
app doesn't crash and runs fine, so i've been living with that during a long
time. However, when i get an unexpected crash, i always think that that
error maybe its reason. Does somebody know what can be causing this error?


Ignacio Castaño
ca...@as...



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

[GD-Windows] Object Animation

[Weston F. <we...@ml...>]

I'm a beginner to DirectX 8 and trying to stay one step ahead of our =
artist.  (He's currently design some characters and object in 3D Studio =
Max.)

How do you animate an object?  (ie: move legs, head arms etc?)

I know I just need more RTFM time in the DirectX 8 SDK.. But is a large =
and complex SDK.. And was just hoping for some pointers where to start?

Thanks
Weston Fryatt

Re: [GD-Windows] edit control (or CEdit) when is the text drawn ?

[<bwa...@bt...>]

You wrote:

>What message is send to the edit window when some text is selected ? I =
have
>try to catch the message with Spy++, but I don't understand why WM_PAINT=
 is
>not called.

You want to catch the EM_SETSEL message. (start in wParam, end in =
lParam).=20

if start is -1 the selection is being removed. If end is -1 and start is =
0
then the whole edit control is being selected.

HTH

Benedict

--
Reality is Insanity

[GD-Windows] edit control (or CEdit) when is the text drawn ?

[Lionel F. <li...@mi...>]

Hello,

I want to make a (very basic) CEdit with custom colors and syntax parsing.

I can change the whole text & bkgnd colors using OnGetDlgCode,
WM_CTLCOLORDLG, WM_CTLCOLORSTATIC and WM_CTLCOLOREDIT but it's not enough,
because the whole text is drawn with the same colors.

So, I rewrote OnPaint to draw the text myself with DrawText. Fine.

BUT, when I just select some text in the edit control, the text is drawn
without any WM_PAINT message, (using the colors provided by
WM_CTLCOLORSTATIC).
What message is send to the edit window when some text is selected ? I have
try to catch the message with Spy++, but I don't understand why WM_PAINT is
not called.

Thank you for any help !
Lionel.

Re: [GD-Windows] dialogbox color

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

----- Original Message -----
From: "Benedict Walmisley" <bwa...@bt...>
To: <gam...@li...>
Sent: Friday, October 19, 2001 5:53 AM
Subject: Re: [GD-Windows] dialogbox color


You want to handle the WM_CTLCOLOR* messages. This allows your dialog
process to adjust the colours used within various parts of the dialogbox.

IE
WM_CTLCOLORBTN
WM_CTLCOLORDLG
WM_CTLCOLOREDIT
WM_CTLCOLORLISTBOX
WM_CTLCOLORMSGBOX
WM_CTLCOLORSCROLLBAR
WM_CTLCOLORSTATIC

To handle the dialogbox background you need to handle the WM_CTLCOLORDLG
message.

HTH

Benedict

-- Yup.
-- If you change the background colors, you may want to specify your
foreground and text colors as well, even if it looks legible on your system
without setting them.
-- Since the user can customize to a different scheme, you can't assume
their choice of foreground and text colors would be "typical" or "readable"
with your choice of background.

-- Better to set the entire scheme than just the colors you have in mind
(that goes with the "normal" or "default" text and foreground.)

Re: [GD-Windows] dialogbox color

[<bwa...@bt...>]

You wrote:

>hi,
>
>VC6 doesn't seem to have built in ability to change the color of a =
dialog
>box..
>Does anyone know of a way?  perhaps something to be added in the =
script.rc
>file,
>or even a sendmessage() command?

You want to handle the WM_CTLCOLOR* messages. This allows your dialog
process to adjust the colours used within various parts of the dialogbox.=
=20

IE
WM_CTLCOLORBTN
WM_CTLCOLORDLG
WM_CTLCOLOREDIT
WM_CTLCOLORLISTBOX
WM_CTLCOLORMSGBOX
WM_CTLCOLORSCROLLBAR
WM_CTLCOLORSTATIC

To handle the dialogbox background you need to handle the WM_CTLCOLORDLG
message.=20

HTH

Benedict
--
Reality is Insanity

[GD-Windows] dialogbox color

[Andrew <an...@aw...>]

hi,

VC6 doesn't seem to have built in ability to change the color of a dialog
box..
Does anyone know of a way?  perhaps something to be added in the script.rc
file,
or even a sendmessage() command?

thanks
Andrew

=---=---=---=---=---...---=---...___________________________________________
__
The next two parts are using full processor time so there is no music -
wish/majic12

RE: [GD-Windows] autodocument max stack usage

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

 
> I know it happens to everyone, Brian included, with his hash 
> distribution posts. But wonder if we can ask people can hold 
> that back a bit?

People are trying to help.  Often someone asks a question and the proper
answer may not be a direct answer, but instead "Why are you trying to do
this?" to perhaps solve it a different.  For example, if someone says
"How do I optimize my bubble sort?" it would be reasonable to ask in
return "Why are you using bubble sort?" =)

Brian

Re: [GD-Windows] GetProcAddress()

[Alain H. <ah...@re...>]

use either: SymEnumerateSymbols or SymGetSymNext. Although
SymEnumerateSymbols sounds more like what you wanted. Unless you wanted the
light version of COM that was suggested in a later response.

----- Original Message -----
From: "Erwin de Vries" <er...@vo...>
To: "GDWindows" <gam...@li...>
Sent: Tuesday, October 16, 2001 9:33 AM
Subject: [GD-Windows] GetProcAddress()


> Hi,
>
> I'm splitting our engine in several parts, and i'd like to use dll's in
some
> places using dynamic linking.
>
> 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?
>
> Thanks,
> Erwin
>
>
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>

Re: [GD-Windows] autodocument max stack usage

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

----- Original Message -----
From: "Brian Hook" <bri...@py...>
To: "'Gamedevlists-Windows@Lists. Sourceforge. Net'"
<gam...@li...>
Sent: Thursday, October 18, 2001 2:36 PM
Subject: RE: [GD-Windows] autodocument max stack usage


> More important, why is the size of the stack an issue, other than for
> informative reasons?  I generally just crank the hell out of my stack in
> the linker settings.  It shouldn't have any side effects, assuming I
> don't use all of it.

-- Mmm ... there appears to be possibly some misunderstanding of why stack
watching is important in this day and age. Apologies if the information
below is elementary, but just in case either of you are not aware, the
following are some of the reasons stack watching yields a better user
experience.

-- The information I have collated is overall stack usage distribution
during runtime during development of the project as it grows bigger. It is
also interesting to see where it is using too much stack and maybe it can be
taken down.

-- Therefore it is _extremely possible_, and _extremely informative_ , to
find out how much stack the modules are using, not counting that used by
other libs, and windows dll.

-- An application user should not ever experience stack fault, or failure to
start app on their system because there is not enough initial stack.

-- (Unless their machine really sucks. :) )

-- The other thing I want to minimize for both performance and robustness
reasons is any runtime stack frame allocation.

-- On XP, as an example, accidental excessive stack frame locks can be a
performance hit. As well as a robustness concern (i.e., it can fail).

-- Another reason is (since I had programmed on consoles as well as PC
applications) cross console and cross platform behavior. One can assume
pushing and popping of stack frames for most PC operating systems, but one
cannot assume the same or similar performances on other operating systems
and consoles.

-- By being able to have a snap and a report how how much stack (and how it
is distributed) on 1 platform (i.e., in Visual C). I can very easily move it
to other platforms that may have more limited memory requirements.

-- I generate the same anal autodocumentation for my memory heap as well.
Not only how big my full heap is and needs to be, but also traces of which
modules is using how much at what time.

-- This information is very helpful when moving to platforms and giving a
quick idea where and how to cut.

-- Still looking for posts that actually _ANSWER_ the post _TOPIC_!

-- Not looking for or reading more posts on why it shouldn't be done or
can't be done.

-- I guess this is similar to Brian asking about if his distribution is
normal, and getting hundreds of hash function back. :)

-- As for _alloca, it can be used as the fallback for obtaining scratch
memory, but before your scratch queue is initialized.

-- _alloca can be a handy function for temp buffer.

-- But if you roll your own (temp buffer allocation), you can do even more
range safe checks on all your memory situations.

-- Again, in XP, it is highly naughty to read memory one does not own. If
some of your memory comes from _alloca, you would not have the real "pointer
min" and "pointer max" for a heap range check before walking it, or before
reading your "magic." Since _alloca can come from (relatively) anywhere.

-- But if you roll your own temp stack, you can safely read your magic since
you know for sure you own that.

-- I have recently become a big fan of handle as much of your own memory as
you can, in the simplest manner possible (i.e., no fancy realtime inplace
compaction schemes).

-- No, and I hold back in custom frame stack allocation schemes as well ...
though it is possible, though again too naughty. :)

-- So, back to the _TOPIC_. Is there a linker output for it, or not. (even
on the module level).

P.S. Hate to be cross, but I hate that at this list and some other places,
one posts a question, and gets a lot of posts explaining really simple and
obvious things that we should all already know.

I know it happens to everyone, Brian included, with his hash distribution
posts. But wonder if we can ask people can hold that back a bit?

RE: [GD-Windows] autodocument max stack usage

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

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

Speaking of alloca(), I'm on the record for thinking it's one of the
least understood and most underutilized functions out there.  Incredibly
handy when you're worried about memory fragmentation.

> 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).

More important, why is the size of the stack an issue, other than for
informative reasons?  I generally just crank the hell out of my stack in
the linker settings.  It shouldn't have any side effects, assuming I
don't use all of it.

Brian

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+

[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] 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

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()

[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()

[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()

[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()

[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()

[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()

[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