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

RE: [GD-Windows] Multimon compile/link hell (WINVER)

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

You need to download the entire Platform SDK, and install=20
it for your language of choice. Note that you need to separately=20
re-configure MSDEV to point at the new headers/libs rather than=20
the ones that it comes with. Platform SDK is not a component of=20
MSDEV, in Microsoft parlance, AFAICT.

It may be that there's actually EnumDisplayDevicesA and=20
EnumDisplayDevicesU, and you need to pick up the appropriate=20
#define to get it linked.

Cheers,

			/ h+

RE: [GD-Windows] (no subject)

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

I absolutely set dmSize correctly -- after I memset() the=20
entire structure to 0.

In fact, the constructor for foo calls memset to 0 and=20
then sets dmSize to sizeof( DEVMODE ).

Cheers,

			/ h+

[GD-Windows] More multimon

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

Multi-monitor support is a bit of a mess.

Disregarding NT4 and Win95, which simply compound problems across=
 the 
board because of lack of native multi-monitor support, it's still=
 a 
mess.

I don't even really have questions, I'm just posting this to see=
 if 
anyone has an opinion.

Using a GF4 Ti4200 w/ dual-head as my reference on Win2K, I have=
 
found out the following.

In a default installation, the NVidia driver reports to the=
 system 
that it's actually a single device with a single monitor.  This=
 means 
GetSystemMetrics( SM_CMONITORS ) returns 1; and=
 EnumDisplayMonitors() 
also only finds a single monitor.  EnumDisplayDevices() will only=
 
show a single display device, and within that device you will=
 only 
find a single monitor represented.

For all intents and purposes, the default dual-head install with=
 the 
NVidia drivers looks exactly like a widescreen single head system=
 
(2560x1024 in my case).  Thus any window that is centered will=
 end up 
getting chopped in half (although there are options in the=
 control 
panel to force dialogs, etc. to go to one monitor or another).

In addition, going "full screen" will shut off one monitor.  Not=
 to 
mention that trying to infer the right "native" resolution is=
 going 
to be tough.  For example, if you want to run 1024x768 but=
 centered 
in a 1280x1024 LCD fullscreen session (to avoid interpolation 
artifacts) there's simply no way to really to do that.  The best=
 you 
can do is run in a window and hope the user doesn't mind; or=
 force to 
1024x768 and hope it's not too ugly; or try to infer with some 
complicated heuristics what the best video resolution might be,=
 but 
even then you're never quite sure which monitor it's going to=
 select 
(e.g. I have a 17" LCD and a 21" CRT, the former supports up to 
1280x1024 and the latter goes up to 1600x1200).

Now, all that ugliness aside, if you solve it there you're still=
 in 
for trouble if the drivers have the "Treat each display as a=
 separate 
device" check box enabled in the control panel.

When THAT is enabled you can see that there are multiple monitors=
 
(thankfully).  Both GetSystemMetrics and EnumDisplayMonitors=
 report 
the right information.

Unfortunately there are now duplicated entries in the global=
 device 
list.  The display adapter will show up twice, with identical 
properties, one time as primary and another time as secondary. =
 And 
each of these instances will think it has FOUR monitors attached,=
 two 
for standard and two for Plug'n'Play.

I haven't figured out a clean way to discard a secondary if I=
 know 
that it's just an alias for the primary (there aren't any=
 duplicated 
fields).  Limiting to primary only then turns around and hoses=
 those 
people with an AGP + PCI configuration and who want stuff to run=
 on 
the secondary.

If I limit to primary only, then a lot of things get simplified,=
 but 
I'm not sure if that's really a good thing, since on some systems=
 the 
BIOS defaults to making PCI the primary device, which obviously=
 is 
not what you'd want in most cases.

I haven't even sat down and tried to sort out what happens on a 
Matrox G550 or Parhelia, or an AGP + PCI configuration.  

I also haven't investigated DirectX's capabilities either, since=
 it 
varies depending on the version (and just browsing the docs, it=
 seems 
like it assumes a 1:1 correlation between adapter and monitors,=
 so 
I'm guessing multihead cards have to present "virtual" adapters=
 to 
the system).

Bah.

When I get this all sorted I'll work out a flow chart.  It won't=
 be 
pretty.

Brian

Re: [GD-Windows] Multimon compile/link hell (WINVER)

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

Well, I take that back.  I installed the SDK, but it's default 
installation location is C:\Program Files\Microsoft SDK, it does=
 NOT 
overwrite your existing set of files.  So to get it to work, I=
 had to 
manually go in and prioritize the header and link paths for the 
above.

Yay, it now works.  I'm not sure how Microsoft could have made=
 this 
any harder...

Brian

On Sun, 30 Mar 2003 11:40:42 -0800, Brian Hook wrote:
>Oh, and for what it's worth, I downloaded the latest and=
 greatest
>Platform SDK to no avail.
>
>Brian

Re: [GD-Windows] Multimon compile/link hell (WINVER)

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

Oh, and for what it's worth, I downloaded the latest and greatest=
 
Platform SDK to no avail.

Brian

[GD-Windows] Multimon compile/link hell (WINVER)

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

Well this is new.  I'm still using MSVC 6 since I've heard too=
 many 
horror stories about 7 at this point.

To gain access to Win98/2K+ functions, you have to set WINVER to=
 
0x0500, except that generates a huge warning during compile:

"NOTE: WINVER has been defined as 0x0500 or greater which=
 enables
Windows NT 5.0 and Windows 98 features. When these headers were 
released, Windows NT 5.0 beta 1 and Windows 98 beta 2.1 were the=
 
current versions.

For this release when WINVER is defined as 0x0500 or greater, you=
 can 
only build beta or test applications.  To build a retail=
 application,
set WINVER to 0x0400 or visit http://www.microsoft.com/msdn/sdk
to see if retail Windows NT 5.0 or Windows 98 headers are=
 available.
See the SDK release notes for more information."

I have SP5 installed, and that hasn't updated the headers.  I=
 can't 
find any other downloads that would be relevant, but the MSDN=
 site is 
so huge that I'm not even sure what I'm looking for.  There's=
 nothing 
new under MSVC++ 6.0 updates though.

A second problem is that even though it compiles, it doesn't link=
 in 
EnumDisplayDevices -- I'm linking to user32.lib, but it's way out=
 of 
date.  I can GetProcAddress directly, but that's not the ideal 
solution (especially if I'm going to continue to run into more of=
 
these types of problems).

Anyone deal with this yet?

Brian

RE: [GD-Windows] (no subject)

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

>Interesting. I would do it with EnumDisplaySettings passing in
>something like ENUM_CURRENT_SETTINGS:
>
>struct foo { DEVMODE dm; char driversSuck[ 1024 ]; }; foo f;=
 BOOL b
>=3D EnumDisplaySettings( NULL, ENUM_CURRENT_SETTINGS, &f.dm );
>
>Look at f.dm.dmPelsWidth, f.dm.dmPelsHeight and=
 f.dm.dmBitsPerPel.
>
>The "driversSuck" field is empirically determined to be=
 necessary on
>some systems to avoid stack overwrites.

I'm assuming you actually set dm.dmSize =3D sizeof( DEVMODE )?  If=
 not, 
that could cause stuff to explode I would imagine.

Brian

RE: [GD-Windows] (no subject)

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

> HDC hDC =3D GetDC( GetDesktopWindow() );
> int bitspixel =3D GetDeviceCaps( hDC, BITSPIXEL );
> ReleaseDC( GetDesktopWindow(), hDC );


Interesting. I would do it with EnumDisplaySettings passing=20
in something like ENUM_CURRENT_SETTINGS:

  struct foo {
    DEVMODE dm;
    char driversSuck[ 1024 ];
  };
  foo f;
  BOOL b =3D EnumDisplaySettings( NULL, ENUM_CURRENT_SETTINGS, &f.dm );

Look at f.dm.dmPelsWidth, f.dm.dmPelsHeight and f.dm.dmBitsPerPel.

The "driversSuck" field is empirically determined to be necessary=20
on some systems to avoid stack overwrites.

Cheers,

				/ h+

Re: [GD-Windows] (no subject)

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

Off the top of my head:

HDC hDC =3D GetDC( GetDesktopWindow() );

int bitspixel =3D GetDeviceCaps( hDC, BITSPIXEL );

ReleaseDC( GetDesktopWindow(), hDC );


On Sat, 29 Mar 2003 23:20:37 +0200, Doru Stoenescu wrote:
>Hello and welcome to my first post on this  list:
> 
>how do you obtain the current color depth? I  managed to obtain=
 
current width and height of the screen using the =
 GetSystemMetrics 
but I seem to have no solution for the BPP.
> 
>Can anyone help me?
> 
>thx
>

[GD-Windows] (no subject)

[Doru S. <do...@pc...>]

Hello and welcome to my first post on this list:

how do you obtain the current color depth? I managed to obtain current =
width and height of the screen using the GetSystemMetrics but I seem to =
have no solution for the BPP.

Can anyone help me?

thx

Re: [GD-Windows] new/delete across DLL's

[Adrian C. <ce...@ce...>]

Sorry I didn't read all the replies to tis message, I just had to take the
chance that this was already solved.

The way we solved this in OGRE (which is a library that links dynamically)
was to create our own memory manager class (based in the debug version  on
Paul Nettle's *very* *very* nice one) which makes sure that all the calls to
*alloc/free and new/delete are mapped to static member functions of this
memory manager class I told you about later. The end product is that all the
memory gets (de)allocated only in the main DLL's thread.
The side-effect is that you have to include the memory manager's header file
in all the other DLL's as well as in the client application.

My 2c,
Adrian 'cearny' Cearnau

----- Original Message -----
From: "Ben Hawes" <cr...@ca...>
To: <gam...@li...>
Sent: Monday, March 24, 2003 7:07 PM
Subject: [GD-Windows] new/delete across DLL's


Am I doing something wrong, or is this correct behaviour:

in core.dll I have a class CFooBar.

in the game exe, I call wibble = new CFooBar;
Later on, within the exe, I call delete wibble; and get an Assert warning
because I'm deallocating from the wrong heap.

This seems very strange, that I can only deallocate a class defined in a DLL
from within that DLL, even if the instance was allocated somewhere else. Am
I understanding this correctly, or am I doing something else to cause the
problem? Is there any way round this?

[ cruise / casual-tempest.net / transference.org ]



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU5

RE: [GD-Windows] new/delete across DLL's

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

Absolutely.

The "delete this" is last in the release() code path, by=20
the way, not touching members after it :-)

Cheers,

				/ h+


> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Hook
> Sent: Monday, March 24, 2003 12:18 PM
> To: gam...@li...
> Subject: RE: [GD-Windows] new/delete across DLL's
>=20
>=20
> >Foo * f =3D gFooFactory->newFoo();
> >f->release();
>=20
> is there a "delete this" somewhere in there?  And I assume the=20
> destructor and constructor are made private, etc.?
>=20
> Brian
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU5
>=20

RE: [GD-Windows] new/delete across DLL's

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

> Or do I now need a FactoryFactory ?

Factories are singletons, right?
They can be static members of themselves, and live somewhere=20
in globals space, rather than being dynamically allocated.

Cheers,

				/ h+

Re: [GD-Windows] new/delete across DLL's

[Rich <leg...@xm...>]

In article <3E7...@po...>,
    brian sharon <pud...@po...>  writes:

> Finally, DLLs (and memory allocated in them by your process) do NOT 
> survive the death of your process.  How can they?

OK, I misspoke slightly.  DLL code can survive your process, but data
allocated to your process by the DLL won't survive.  At any rate, the
factory approach is a good one if you're using DLLs.
-- 
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
          <http://www.xmission.com/~legalize/book/>
        izfree: Open source tools for Windows Installer
                <http://izfree.sourceforge.net>

RE: [GD-Windows] new/delete across DLL's

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

>Foo * f =3D gFooFactory->newFoo();
>f->release();

is there a "delete this" somewhere in there?  And I assume the 
destructor and constructor are made private, etc.?

Brian

RE: [GD-Windows] new/delete across DLL's

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

> Just to be clear, you're saying this is bad:
>=20
> foo *f =3D Foo::newFoo();
> delete f;

Yes. Unless operator new/delete are overridden in Foo, but=20
evenso, there's other problems you'll run into.

> but that this is good:
>=20
> foo *f =3D Foo::newFoo();
> Foo::deleteFoo(f);

Yes.

I'd prefer something like:

Foo * f =3D gFooFactory->newFoo();
f->release();

> >Un-balanced allocations/deletions really are a bad idea for a
> >variety of reasons; this being just one.
>=20
> Well, a big part of me pretty much blames the language, but that's a=20
> bit too convenient given that Microsoft's DLL idiosyncracies seem to=20
> be rather unique in the world of operating systems (although you do=20
> point out some interesting cases on Unix).

Actually, AIX, MacOS and Windows all have the "sealed container"=20
linkage model, and most other UNIX-es have the "merged global symbol=20
table" model. I like "sealed container" because it makes it possible=20
for me to prove that I tested in the same environment that I will=20
run. (Don't know about MacOS X though -- maybe they went over to the=20
dark side with their new linkage model)

Cheers,

				/ h+

Re: [GD-Windows] new/delete across DLL's

[brian s. <pud...@po...>]

Whoa, nellie! 

I think people need to be careful when they use the word "heap" in this 
discussion.  The heap that can't be shared is the statically linked C 
runtime heap - those data structures are allocated per DLL/EXE and 
memory allocated from one C runtime heap can't be freed by another.  
Imagine that you passed a pointer from a linked list into the remove 
routine of another linked list and you should get the picture.  
Confusion (at best) results.

The dynamically-linked C runtime solves some of these problems, assuming 
you can be sure that all your code uses the same version of the 
MSVCRT*.DLL - but as Jon points out there's more than one flavor of that 
DLL, so you'll probably end up in hell anyway once you alloc from one 
flavor and free from another.

A Windows heap doesn't have these issues.  The data structures for the 
Windows heap are stored once *per process* in the single instance of 
Kernel32.dll that's mapped in your process.  So you could implement 
operator new globally by just inlining it as GlobalAlloc or 
HeapAlloc(GetProcessHeap()...).  It might not be the most 
space-efficient allocator for small blocks, but it's perfectly 
functional...and why should you PC guys and gals care about running out 
of memory, you've got VM. :) 

Finally, DLLs (and memory allocated in them by your process) do NOT 
survive the death of your process.  How can they?  The DLL is a part of 
your process.  The code might still be mapped into memory if another 
process is using it, but when the process goes down, the data segment of 
the DLL that your process was using goes bye-bye.  Remember, the real 
problem with mixing allocations is because a separate C runtime heap is 
maintained in each module that statically links the C runtime.

--brian

p.s. If I wanted to avoid this problem, I would do exactly what Jon said.

Rich wrote:

>In article <005b01c2f233$ede559c0$7b02000a@mcaf.local>,
>    "Javier Arevalo" <ja...@py...>  writes:
>
>  
>
>>If both the EXE and your DLL link with the MSVC DLL runtime, it will work
>>correctly because all allocations are physically performed inside the
>>(single instance of the) runtime DLL.
>>    
>>
>
>I don't think this is true.  Its not a matter of what runtime you use,
>its a matter of where you perform the allocation.  We used the DLL
>runtime and had the exact same sort of issue reported by the original
>poster.  Putting the deallocation inside the DLL via a helper function
>fixed the problem.  However, the specifics are a fuzzy memory at this
>point.  The one thing I remembered was that allocations performed by
>DLL code are allocated from a distinct heap.  It has to be this way
>for the memory dynamically allocated by a DLL to survive the death of
>your process.
>  
>

Re: [GD-Windows] new/delete across DLL's

[Ben H. <cr...@ca...>]

>...The one thing I remembered was that
>allocations performed by DLL code are allocated from a distinct
>heap.  It has to be this way for the memory dynamically=
 allocated by
>a DLL to survive the death of your process.

Now, if I was trying to deallocate memory I'd allocated in the=
 DLL, 
then I could understand it (I've already encountered that one).

But I'm deallocating memory (I thought) I'd allocated in the 
exe...just happens to be a class declared in the DLL...or does=
 that 
end up amounting to the same thing?

And, wrt Jon Watte's comments...I'm already heavily doing an 
Interface/Factory structure...this is one of my Factories I'm=
 trying 
to create within Game::Game(), and then deallocate in ~Game()

Or do I now need a FactoryFactory ?

[ cruise / casual-tempest.net / transference.org ]

Re: [GD-Windows] new/delete across DLL's

[Pierre T. <p.t...@wa...>]

>Just to be clear, you're saying this is bad:
>
>foo *f = Foo::newFoo();
>delete f;
>
>but that this is good:
>
>foo *f = Foo::newFoo();
>Foo::deleteFoo(f);

Definitely.

Exactly what Javier said.

I ran into a ridiculously high amount of nasty bugs in Flexporter, because
of this issue. (MAX + MFC + my own engine in multiple DLLs, inlining all the
time, overring new/delete, mixing various versions of MSVCRT => blam ! blam!
more blam!)

Factories, factories, and some more factories. Don't even try fighting it,
you'll only regret it later ........ :)

Note that BoundsChecker usually detects the new/delete mismatch (and blame
you rightfully).

- Pierre
www.codercorner.com

RE: [GD-Windows] new/delete across DLL's

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

>Repeat after me: Factories. Interfaces. Bliss. :-)

Just to be clear, you're saying this is bad:

foo *f =3D Foo::newFoo();
delete f;

but that this is good:

foo *f =3D Foo::newFoo();
Foo::deleteFoo(f);

?

>Un-balanced allocations/deletions really are a bad idea for a
>variety of reasons; this being just one.

Well, a big part of me pretty much blames the language, but=
 that's a 
bit too convenient given that Microsoft's DLL idiosyncracies seem=
 to 
be rather unique in the world of operating systems (although you=
 do 
point out some interesting cases on Unix).

This is one reason why overloading global operator new seems like=
 a 
pipe dream in everything but the most specific cases (e.g. I can=
 get 
away with it because I don't use DLLs for anything on Windows --=
 but 
I can't get away with it at all using GCC for various reasons I=
 never 
bothered to figure out).

Brian

Re: [GD-Windows] new/delete across DLL's

[Javier A. <ja...@py...>]

I never had to use this myself since we always have virtualized and/or
strong-ownership interfaces in our DLLs. IIRC the idea was like this: every
module has its own Windows heap. EXE and DLL files are distinct modules,
thus have different heaps. If you use the runtime in its DLL form, your
new/malloc calls (and delete/free) end up being processed by the runtime
DLL, thus only one heap is ever used for this purpose.

Rich wrote:
> In article <005b01c2f233$ede559c0$7b02000a@mcaf.local>,
>     "Javier Arevalo" <ja...@py...>  writes:
>
>> If both the EXE and your DLL link with the MSVC DLL runtime, it will
>> work correctly because all allocations are physically performed
>> inside the (single instance of the) runtime DLL.
>
> I don't think this is true.  Its not a matter of what runtime you use,
> its a matter of where you perform the allocation.  We used the DLL
> runtime and had the exact same sort of issue reported by the original
> poster.  Putting the deallocation inside the DLL via a helper function
> fixed the problem.  However, the specifics are a fuzzy memory at this
> point.  The one thing I remembered was that allocations performed by
> DLL code are allocated from a distinct heap.  It has to be this way
> for the memory dynamically allocated by a DLL to survive the death of
> your process.

  Javier Arevalo
  Pyro Studios

RE: [GD-Windows] new/delete across DLL's

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

Virtual destructor has nothing to do with memory allocation.

Virtual destructor and override of operator new and delete may=20
help a little bit, but you still get into trouble with templates=20
and other inline functions.

Repeat after me: Factories. Interfaces. Bliss. :-)

Un-balanced allocations/deletions really are a bad idea for a=20
variety of reasons; this being just one.

If you link your DLLs and your EXEs against the same runtime DLL=20
then they will share a heap, and things will appear to work,=20
until such time as someone wants to write a plug-in for your app=20
using Borland, or some other version of MSVC, or you want to run=20
a debug plug-in with the release EXE (debug and release MSVCRT=20
libs are not compatible).

And things get worse with MSVCPRT, which is needed for the MS=20
implementation of STL. It suffers all the problems of unbalanced=20
allocations already -- if you implement your own operator new,=20
then some template instances inside MSVCPRT will use the old=20
operator delete anyway, 'cause that's what was in effect when=20
that DLL was built.

Cheers,

			/ h+


> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Grills, Jeff
> Sent: Monday, March 24, 2003 10:49 AM
> To: 'gam...@li...'
> Subject: RE: [GD-Windows] new/delete across DLL's=20
>=20
>=20
>=20
> Assuming C++, shouldn't a virtual destructor be sufficient to solve =
this
> problem?  At the very most, you might have to have the virtual =
destructor
> and overload new and delete per class, but those could trivially=20
> turn around
> and call the global versions.
>=20
> I load our graphics interface from a DLL, and it does allocate memory =
that
> is released from the client.  I've hooked the memory management=20
> functions in
> the DLL to call back into the main game executable so that I really =
only
> have one heap.  My intent wasn't to work around this issue, but rather =
to
> make sure that I had all memory in a single heap so that I could=20
> monitor the
> game's memory usage and fragmentation.
>=20
> j
>=20
> -----Original Message-----
> From: Rich [mailto:leg...@xm...]
> Sent: Monday, March 24, 2003 12:08 PM
> To: gam...@li...
> Subject: Re: [GD-Windows] new/delete across DLL's=20
>=20
>=20
>=20
> In article <E18...@sc...>,
>     Ben Hawes <cr...@ca...>  writes:
>=20
> > in the game exe, I call wibble =3D3D new CFooBar;
> > Later on, within the exe, I call delete wibble; and get an Assert=3D
> >  warning because I'm deallocating from the wrong heap.
>=20
> Yep.  That's the way Windows DLLs work.  Allocations inside a DLL are
> done on the heap belonging to the DLL (because the DLL can live in
> memory longer than your process, it must use its own heap for
> allocations).
>=20
> You can deal with it in one of several ways:
> - use a static library, not a DLL
> - use a helper function in the DLL that does the deallocation for you
>=20
> I'd use a static library unless there really is some overriding
> reason to use a DLL.  "It just works" that way.
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D555
>=20

Re: [GD-Windows] new/delete across DLL's

[Rich <leg...@xm...>]

In article <BD6...@ma...>,
    "Grills, Jeff" <jg...@so...>  writes:

> Assuming C++, shouldn't a virtual destructor be sufficient to solve this
> problem?

That's an interesting point.  It might work, but I'm not sure, I
haven't tried it.
-- 
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
          <http://www.xmission.com/~legalize/book/>
        izfree: Open source tools for Windows Installer
                <http://izfree.sourceforge.net>

Re: [GD-Windows] new/delete across DLL's

[Rich <leg...@xm...>]

In article <005b01c2f233$ede559c0$7b02000a@mcaf.local>,
    "Javier Arevalo" <ja...@py...>  writes:

> If both the EXE and your DLL link with the MSVC DLL runtime, it will work
> correctly because all allocations are physically performed inside the
> (single instance of the) runtime DLL.

I don't think this is true.  Its not a matter of what runtime you use,
its a matter of where you perform the allocation.  We used the DLL
runtime and had the exact same sort of issue reported by the original
poster.  Putting the deallocation inside the DLL via a helper function
fixed the problem.  However, the specifics are a fuzzy memory at this
point.  The one thing I remembered was that allocations performed by
DLL code are allocated from a distinct heap.  It has to be this way
for the memory dynamically allocated by a DLL to survive the death of
your process.
-- 
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
          <http://www.xmission.com/~legalize/book/>
        izfree: Open source tools for Windows Installer
                <http://izfree.sourceforge.net>

Re: [GD-Windows] new/delete across DLL's

[Rich <leg...@xm...>]

In article <HEE...@mi...>,
    "Jon Watte" <hp...@mi...>  writes:

> You may note that COM does a lot of these things, btw :-)

Oh, that's a very good point.  You can encapsulate your objects as COM
objects.  If you're careful in designing your interfaces, you can use
them from VB, C++, or a .NET language as well.
-- 
"The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ:
          <http://www.xmission.com/~legalize/book/>
        izfree: Open source tools for Windows Installer
                <http://izfree.sourceforge.net>