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

Re: [GD-Windows] GetProcAddress()

[Erwin de V. <er...@vo...>]

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

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

If you use __cdecl and extern "C" declaration for the functions, their name
mangling will be C compatible, which is simpler. It is, however, not
possible to use function overloading with "C" linkage.

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.

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.

Cheers,

				/ h+



> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Erwin de Vries
> Sent: Tuesday, October 16, 2001 9:34 AM
> To: GDWindows
> 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] 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()

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

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

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

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

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

[Erwin de V. <er...@vo...>]

> Three possibilities:
> 
> 1. Export as extern "C" which will remove most of the mangling.

Hmmm. I could try this.

> 2. Use a .def file to name the exports how you like, just like the good
> old Win3 days.

I try to prevent that!

> 3. Write a tool that postprocesses an exe to rename the entries in the
> export table.

Hmm. That seems like an excessive amount of work.

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

Erwin

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

[Scott B. <gas...@nw...>]

Three possibilities:

1. Export as extern "C" which will remove most of the mangling.
2. Use a .def file to name the exports how you like, just like the good
old Win3 days.
3. Write a tool that postprocesses an exe to rename the entries in the
export table.

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On
> Behalf Of Erwin de Vries
> Sent: Tuesday, October 16, 2001 9:34 AM
> To: GDWindows
> 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
>

[GD-Windows] GetProcAddress()

[Erwin de V. <er...@vo...>]

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

RE: [GD-Windows] DDE Event not showing up

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

My old question:

> It seems weird if DDE is fundamentally broken; it's used by a lot of apps
> and has been around forever... but that doesn't mean much these days :-/

DDE isn't fundamentally broken, the code I was working with was :-)

The solution was to remove PM_NOYIELD from the call to PeekMessage(), as the
ONLY use for this flag these days is to not cause WaitForInputIdle() to
return, and DDE uses precisely that to determine when to send the app its
message. D'oh!

Cheers,

				/ h+

[GD-Windows] Copyprotection

[Erwin de V. <er...@vo...>]

Hi there,

I'm adding a little security check. I have a few questions:

- Is a CDROM drive guaranteed to show up when calling
GetLogicalDriveStrings()?
- Is GetDriveType() guaranteed to return DRIVE_CDROM for a cdrom?
- Is GetVolumeInformation() guaranteed to succeed if my buffers are large
enough?

Even on non administrator accounts ect? In Win95, 98, ME, XP, and 2k?

Thanks,
Erwin

RE: [GD-Windows] DDE Event not showing up

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

Thanks. The following MSDN article talks about the Mutex approach.

http://support.microsoft.com/support/kb/articles/Q243/9/53.ASP

Note that if the mutex already exists, you don't get back some convenient
handle to the other instance; this specific technique is only useful to
determine _whether_ another instance is running.


It seems weird if DDE is fundamentally broken; it's used by a lot of apps
and has been around forever... but that doesn't mean much these days :-/

Cheers,

			/ h+


> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Aaron Hilton
> Sent: Sunday, October 07, 2001 4:42 AM
> To: GDWindows
> Subject: Re: [GD-Windows] DDE Event not showing up
>
>
> Oops.. darn reply-to crap.
> Here's my proper message.
> ----
> For the case of not using a DDE I understand a mutex is used. I'm not
> entirely sure of the details, but essentially if a mutex (semaphore) is
> already locked, then you get what application locked the mutex (the
> other instance) and send that app the activation message then close.
>
> It's a quick 10-15 lines of code.  I've seen it used a long while back,
> so I'm fuzzy on how it all works.
>
> The benefit, You guarantee the app refuses to launch twice, unless
> specifically requested. And it appears to be the official way MS deals
> with the double-launch problem too.  Could one of the MS experts help
> elaborate?  I would really like to refresh here too.
>
> I don't trust the DDE implementation because of some flaky problems I've
> had writing remote control stuff for WinAmp's DDE interface.  Yuck.. I
> think DDE is either broken on some versions of windows, therefore
> undependable and useless, or maybe I was struck with WinAmp misbehaving
> on certain platforms.
>
> Good luck...
> - Aaron.
>
> Jon Watte wrote:
> >
> > This has puzzled me and some other fellows for a while; I hope
> some of you
> > smart people know the answer!
> >
> > In an app we're working on, a regular Windows app is started
> from a web page
> > by registering a MIME type to IE, which starts the app, and having the
> > browser send DDE data to the application.
> >
> > However, sometimes when the app gets started from the link, it
> takes about
> > 30-60 seconds until the DDE data arrives. However, if I click
> the window,
> > the data will arrive immediately. This is a major drag, as the
> application
> > will just sit idle and dull until the data arrives.
> >
> > I'd prefer to stay with DDE because it handles the case of
> clicking a link
> > while the app is already open. However, if you can think of
> some other way
> > of accomplishing something similar, including some kind of gross hack,
> > that'd be swell too, as this is only an in-house tool kind of thing.
> >
> > Cheers,
> >
> >                                 / h+
> >
> > _______________________________________________
> > Gamedevlists-windows mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>

Re: [GD-Windows] DDE Event not showing up

[Aaron H. <Vid...@ho...>]

Oops.. darn reply-to crap.
Here's my proper message.
----
For the case of not using a DDE I understand a mutex is used. I'm not
entirely sure of the details, but essentially if a mutex (semaphore) is
already locked, then you get what application locked the mutex (the
other instance) and send that app the activation message then close.

It's a quick 10-15 lines of code.  I've seen it used a long while back,
so I'm fuzzy on how it all works.

The benefit, You guarantee the app refuses to launch twice, unless
specifically requested. And it appears to be the official way MS deals
with the double-launch problem too.  Could one of the MS experts help
elaborate?  I would really like to refresh here too.

I don't trust the DDE implementation because of some flaky problems I've
had writing remote control stuff for WinAmp's DDE interface.  Yuck.. I
think DDE is either broken on some versions of windows, therefore
undependable and useless, or maybe I was struck with WinAmp misbehaving
on certain platforms.

Good luck...
- Aaron.

Jon Watte wrote:
> 
> This has puzzled me and some other fellows for a while; I hope some of you
> smart people know the answer!
> 
> In an app we're working on, a regular Windows app is started from a web page
> by registering a MIME type to IE, which starts the app, and having the
> browser send DDE data to the application.
> 
> However, sometimes when the app gets started from the link, it takes about
> 30-60 seconds until the DDE data arrives. However, if I click the window,
> the data will arrive immediately. This is a major drag, as the application
> will just sit idle and dull until the data arrives.
> 
> I'd prefer to stay with DDE because it handles the case of clicking a link
> while the app is already open. However, if you can think of some other way
> of accomplishing something similar, including some kind of gross hack,
> that'd be swell too, as this is only an in-house tool kind of thing.
> 
> Cheers,
> 
>                                 / h+
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows

[GD-Windows] DDE Event not showing up

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

This has puzzled me and some other fellows for a while; I hope some of you
smart people know the answer!

In an app we're working on, a regular Windows app is started from a web page
by registering a MIME type to IE, which starts the app, and having the
browser send DDE data to the application.

However, sometimes when the app gets started from the link, it takes about
30-60 seconds until the DDE data arrives. However, if I click the window,
the data will arrive immediately. This is a major drag, as the application
will just sit idle and dull until the data arrives.

I'd prefer to stay with DDE because it handles the case of clicking a link
while the app is already open. However, if you can think of some other way
of accomplishing something similar, including some kind of gross hack,
that'd be swell too, as this is only an in-house tool kind of thing.

Cheers,

				/ h+

Re: [GD-Windows] Win2K SP2 debugging slowdown?

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

Plus it seems to have some issues when called by different threads. Thank
god we have our own log window. :)

Javier Arevalo
Pyro Studios

----- Original Message -----
From: "gaspow20" <gas...@nw...>
To: "'GDWindows'" <gam...@li...>
Sent: Wednesday, October 03, 2001 7:39 PM
Subject: RE: [GD-Windows] Win2K SP2 debugging slowdown?


> Debug strings are passed to the debugger via a message queue of some
> kind. There is no blocking issue involved that would slow down the game
> - in other words, the game is never waiting for the debugger to catch
> up. That's why the debugger can drop debug strings when it gets flooded.
>
> The API function and queueing code is probably just really slow.
> Short-circuits if no debugger is attached too.

[GD-Windows] List Reply Issues

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

OK, I've gotten some information back from SourceForge. The change was part 
of a recent global policy change. We were not consulted before it happened, 
it was just made for us because they feel this is the way lists should be 
run. Needless to say I don't agree with them.

I've gotten the email address of the person we'll need to talk to in order 
to get this changed (all I want it the ability to specify it on a per-list 
basis .. which is what we used to have) but he is on vacation for the rest 
of the week. Unfortunately, I'll be gone on my honeymoon next week so I 
won't be able to talk to him until around the 16th. I'm gonna drop the guy 
an email now and leave him contact information for Brian. We'll take this 
one step at a time, but hopefully we'll get things changed back to normal soon.

Tom

RE: [GD-Windows] Win2K SP2 debugging slowdown?

[gaspow20 <gas...@nw...>]

Debug strings are passed to the debugger via a message queue of some
kind. There is no blocking issue involved that would slow down the game
- in other words, the game is never waiting for the debugger to catch
up. That's why the debugger can drop debug strings when it gets flooded.

The API function and queueing code is probably just really slow.
Short-circuits if no debugger is attached too.

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On
> Behalf Of Tom Forsyth
> Sent: Wednesday, October 03, 2001 8:42 AM
> To: GDWindows
> Subject: RE: [GD-Windows] Win2K SP2 debugging slowdown?
>
>
> [grrr... reply-to-person thing is getting annoying now]
>
> The debugger sets up a debug string handler that is usually
> very very slow. So if you're outputting a lot of info to the
> debug output, that will cause serious slowdowns when the
> debugger is active. Remember that DirectX also throws a lot
> of stuff into the debug stream if you have the debug level set high.
>
> 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

RE: [GD-Windows] Win2K SP2 debugging slowdown?

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

Hum, I meant MY game console...

But as I don't know all the internals of python, and I'm derouting the
stderr and stdout in order to print to the game console, perhaps the
debugger gets involved in this pipe (but I think the python stdout is
not the real one...)

Thanks anyway,=20

Emmanuel

> -----Original Message-----
> From: Tom Forsyth [mailto:to...@mu...]
> Sent: mercredi 3 octobre 2001 19:26
> To: GDWindows
> Subject: RE: [GD-Windows] Win2K SP2 debugging slowdown?
>=20
>=20
> Because the debugger captures console output as well. And it=20
> does it really
> slowly - 180 times a second is easily enough to make it chug.
>=20
> Tom Forsyth - Muckyfoot bloke.
>=20
> What's he up to now (and can I have a go)?
> http://www.eidosinteractive.com/downloads/search.html?gmid=3D86

RE: [GD-Windows] Win2K SP2 debugging slowdown?

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

Because the debugger captures console output as well. And it does it really
slowly - 180 times a second is easily enough to make it chug.

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: Emmanuel Astier [mailto:emm...@wi...]
> Sent: 03 October 2001 18:18
> To: GDWindows
> Subject: RE: [GD-Windows] Win2K SP2 debugging slowdown?
> 
> 
> Actually, it was another thing :
> I'm using Python as a script, and it was a 'print ' to the 
> console that
> occured three time every 1/60 seconde that was slowing down the
> Release-from-the-Debugger version...
> 
> But I still don't know why !!
> 
> Emmanuel
> 
> > -----Original Message-----
> > From: Javier Arevalo [mailto:ja...@py...]
> > Sent: mercredi 3 octobre 2001 18:33
> > To: GDWindows
> > Subject: Re: [GD-Windows] Win2K SP2 debugging slowdown?
> > 
> > 
> > No debug strings (we #ifdef out all our OutputDebugString 
> > calls in Release
> > builds), and DirectX retail runtime. :)
> > 
> > Javier Arevalo
> > Pyro Studios
> > 
> > ----- Original Message -----
> > From: "Tom Forsyth" <to...@mu...>
> > To: "GDWindows" <gam...@li...>
> > Sent: Wednesday, October 03, 2001 5:41 PM
> > Subject: RE: [GD-Windows] Win2K SP2 debugging slowdown?
> > 
> > 
> > > [grrr... reply-to-person thing is getting annoying now]
> > >
> > > The debugger sets up a debug string handler that is usually 
> > very very
> > slow.
> > > So if you're outputting a lot of info to the debug output, 
> > that will cause
> > > serious slowdowns when the debugger is active. Remember 
> > that DirectX also
> > > throws a lot of stuff into the debug stream if you have the 
> > debug level
> > set
> > > high.
> > >
> > > 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: Emmanuel Astier [mailto:emm...@wi...]
> > > > Sent: 03 October 2001 14:00
> > > > To: GDWindows
> > > > Subject: RE: [GD-Windows] Win2K SP2 debugging slowdown?
> > > >
> > > >
> > > > I have also a strange problem...
> > > >
> > > > My game (it is at a very early stage) runs at 1-2 fps in 
> > release mode
> > > > when I launch it under the debugger.
> > > > When I launch it without the debugger, it runs at 90 fps...
> > > >
> > > > There's no massive deallocations, no use of exceptions...
> > > >
> > > > I know a launch in the debugger should be slower than a real
> > > > launch, but
> > > > not that much ???
> > > >
> > > > Emmanuel
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Javier Arevalo [mailto:ja...@py...]
> > > > > Sent: mercredi 3 octobre 2001 14:29
> > > > > To: GDWindows
> > > > > Subject: Re: [GD-Windows] Win2K SP2 debugging slowdown?
> > > > >
> > > > >
> > > > > If only it were that easy. :)
> > > > >
> > > > > The situation happens when the game is run under the
> > > > > debugger, using the
> > > > > debug runtime or not doesn't make a difference. The slowdown
> > > > > magnitude is
> > > > > huge, about is a few seconds (5-7) versus a couple tenths of
> > > > > a second so I
> > > > > have ruled out cache, fragmentation and similar issues.
> > > > >
> > > > > Besides, why does it happen only after installing the Win2K
> > > > > Service Pack 2?
> > > > > I guess it has something to do with additional security
> > > > > features of the SP2
> > > > > for processes that run under a debugger, but that's just my
> > > > > own elaboration,
> > > > > and still leaves me with no idea what triggers the slowdown
> > > > > and how to fix
> > > > > it.
> > > > >
> > > > > The hardware configuration doesn't matter, since it's
> > > > > happened everywhere
> > > > > from 2-year-old P3-450's to brand-new 1.4GHz AMDs, 256 or
> > > > > 512Mb RAM. Heh all
> > > > > machines have NVidia cards but I really doubt that has
> > > > > anything to do, since
> > > > > the slowdown happens in areas with zero D3D interaction -
> > > > > sound and massive
> > > > > memory deallocations so far.
> > > > >
> > > > > Javier Arevalo
> > > > > Pyro Studios
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Tom Forsyth" <to...@mu...>
> > > > > To: "GDWindows" <gam...@li...>
> > > > > Sent: Wednesday, October 03, 2001 1:47 PM
> > > > > Subject: RE: [GD-Windows] Win2K SP2 debugging slowdown?
> > > > >
> > > > >
> > > > > > Sounds like the debug runtime is checking every freed block
> > > > > to make sure
> > > > > you
> > > > > > haven't scribbled off the ends. When you allocate stuff, it
> > > > > pads the start
> > > > > > and end with some special characters. IIRC, it pads 16
> > > > > bytes off start and
> > > > > > end with FD. When you call free() or delete() or whatever,
> > > > > it checks that
> > > > > > the FDs are still there.
> > > > > >
> > > > > > I have no idea hy it does this more or less than normal
> > > > > though - maybe
> > > > > > because your memory is heavily fragmented on those runs, so
> > > > > cleanup is
> > > > > quite
> > > > > > messy?
> > > > > >
> > > > > > 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: Javier Arevalo [mailto:ja...@py...]
> > > > > > > Sent: 03 October 2001 08:28
> > > > > > > To: GDWindows
> > > > > > > Subject: [GD-Windows] Win2K SP2 debugging slowdown?
> > > > > > >
> > > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > We have been tracking a weird situation we have, where on
> > > > > > > some of our dev.
> > > > > > > machines our game takes several seconds to shut down. We
> > > > > > > eventually found
> > > > > > > out the following:
> > > > > > >
> > > > > > > - The game must be running in a debugging session 
> under MSVC
> > > > > > > (haven't tried
> > > > > > > other debuggers).
> > > > > > > - The computer must have Windows 2000 _with_ service pack
> > > > > 2 installed.
> > > > > > >
> > > > > > > The slowdown happens during a loop that deletes several
> > > > > > > thousand dynamic
> > > > > > > memory blocks. Most of the time, sometimes it doesn't.
> > > > > > > Similar symptoms also
> > > > > > > appear in other places, like our streaming music
> > > > decoding thread.
> > > > > > >
> > > > > > > Running MSDEV under VTune we found that, when the slowdown
> > > > > > > happens, most of
> > > > > > > the time during that loop is spent inside the operating
> > > > > system, spread
> > > > > > > half-and-half in two functions: 
> RtlCompareMemoryUlong() and
> > > > > > > RtlFillMemoryUlong().
> > 
> > 
> > 
> > _______________________________________________
> > Gamedevlists-windows mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> > 
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> 

RE: [GD-Windows] Win2K SP2 debugging slowdown?

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

Actually, it was another thing :
I'm using Python as a script, and it was a 'print ' to the console that
occured three time every 1/60 seconde that was slowing down the
Release-from-the-Debugger version...

But I still don't know why !!

Emmanuel

> -----Original Message-----
> From: Javier Arevalo [mailto:ja...@py...]
> Sent: mercredi 3 octobre 2001 18:33
> To: GDWindows
> Subject: Re: [GD-Windows] Win2K SP2 debugging slowdown?
>=20
>=20
> No debug strings (we #ifdef out all our OutputDebugString=20
> calls in Release
> builds), and DirectX retail runtime. :)
>=20
> Javier Arevalo
> Pyro Studios
>=20
> ----- Original Message -----
> From: "Tom Forsyth" <to...@mu...>
> To: "GDWindows" <gam...@li...>
> Sent: Wednesday, October 03, 2001 5:41 PM
> Subject: RE: [GD-Windows] Win2K SP2 debugging slowdown?
>=20
>=20
> > [grrr... reply-to-person thing is getting annoying now]
> >
> > The debugger sets up a debug string handler that is usually=20
> very very
> slow.
> > So if you're outputting a lot of info to the debug output,=20
> that will cause
> > serious slowdowns when the debugger is active. Remember=20
> that DirectX also
> > throws a lot of stuff into the debug stream if you have the=20
> debug level
> set
> > high.
> >
> > Tom Forsyth - Muckyfoot bloke.
> >
> > What's he up to now (and can I have a go)?
> > http://www.eidosinteractive.com/downloads/search.html?gmid=3D86
> >
> > > -----Original Message-----
> > > From: Emmanuel Astier [mailto:emm...@wi...]
> > > Sent: 03 October 2001 14:00
> > > To: GDWindows
> > > Subject: RE: [GD-Windows] Win2K SP2 debugging slowdown?
> > >
> > >
> > > I have also a strange problem...
> > >
> > > My game (it is at a very early stage) runs at 1-2 fps in=20
> release mode
> > > when I launch it under the debugger.
> > > When I launch it without the debugger, it runs at 90 fps...
> > >
> > > There's no massive deallocations, no use of exceptions...
> > >
> > > I know a launch in the debugger should be slower than a real
> > > launch, but
> > > not that much ???
> > >
> > > Emmanuel
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Javier Arevalo [mailto:ja...@py...]
> > > > Sent: mercredi 3 octobre 2001 14:29
> > > > To: GDWindows
> > > > Subject: Re: [GD-Windows] Win2K SP2 debugging slowdown?
> > > >
> > > >
> > > > If only it were that easy. :)
> > > >
> > > > The situation happens when the game is run under the
> > > > debugger, using the
> > > > debug runtime or not doesn't make a difference. The slowdown
> > > > magnitude is
> > > > huge, about is a few seconds (5-7) versus a couple tenths of
> > > > a second so I
> > > > have ruled out cache, fragmentation and similar issues.
> > > >
> > > > Besides, why does it happen only after installing the Win2K
> > > > Service Pack 2?
> > > > I guess it has something to do with additional security
> > > > features of the SP2
> > > > for processes that run under a debugger, but that's just my
> > > > own elaboration,
> > > > and still leaves me with no idea what triggers the slowdown
> > > > and how to fix
> > > > it.
> > > >
> > > > The hardware configuration doesn't matter, since it's
> > > > happened everywhere
> > > > from 2-year-old P3-450's to brand-new 1.4GHz AMDs, 256 or
> > > > 512Mb RAM. Heh all
> > > > machines have NVidia cards but I really doubt that has
> > > > anything to do, since
> > > > the slowdown happens in areas with zero D3D interaction -
> > > > sound and massive
> > > > memory deallocations so far.
> > > >
> > > > Javier Arevalo
> > > > Pyro Studios
> > > >
> > > > ----- Original Message -----
> > > > From: "Tom Forsyth" <to...@mu...>
> > > > To: "GDWindows" <gam...@li...>
> > > > Sent: Wednesday, October 03, 2001 1:47 PM
> > > > Subject: RE: [GD-Windows] Win2K SP2 debugging slowdown?
> > > >
> > > >
> > > > > Sounds like the debug runtime is checking every freed block
> > > > to make sure
> > > > you
> > > > > haven't scribbled off the ends. When you allocate stuff, it
> > > > pads the start
> > > > > and end with some special characters. IIRC, it pads 16
> > > > bytes off start and
> > > > > end with FD. When you call free() or delete() or whatever,
> > > > it checks that
> > > > > the FDs are still there.
> > > > >
> > > > > I have no idea hy it does this more or less than normal
> > > > though - maybe
> > > > > because your memory is heavily fragmented on those runs, so
> > > > cleanup is
> > > > quite
> > > > > messy?
> > > > >
> > > > > Tom Forsyth - Muckyfoot bloke.
> > > > >
> > > > > What's he up to now (and can I have a go)?
> > > > > =
http://www.eidosinteractive.com/downloads/search.html?gmid=3D86
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Javier Arevalo [mailto:ja...@py...]
> > > > > > Sent: 03 October 2001 08:28
> > > > > > To: GDWindows
> > > > > > Subject: [GD-Windows] Win2K SP2 debugging slowdown?
> > > > > >
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > We have been tracking a weird situation we have, where on
> > > > > > some of our dev.
> > > > > > machines our game takes several seconds to shut down. We
> > > > > > eventually found
> > > > > > out the following:
> > > > > >
> > > > > > - The game must be running in a debugging session under MSVC
> > > > > > (haven't tried
> > > > > > other debuggers).
> > > > > > - The computer must have Windows 2000 _with_ service pack
> > > > 2 installed.
> > > > > >
> > > > > > The slowdown happens during a loop that deletes several
> > > > > > thousand dynamic
> > > > > > memory blocks. Most of the time, sometimes it doesn't.
> > > > > > Similar symptoms also
> > > > > > appear in other places, like our streaming music
> > > decoding thread.
> > > > > >
> > > > > > Running MSDEV under VTune we found that, when the slowdown
> > > > > > happens, most of
> > > > > > the time during that loop is spent inside the operating
> > > > system, spread
> > > > > > half-and-half in two functions: RtlCompareMemoryUlong() and
> > > > > > RtlFillMemoryUlong().
>=20
>=20
>=20
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>=20

Re: [GD-Windows] Win2K SP2 debugging slowdown?

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

No debug strings (we #ifdef out all our OutputDebugString calls in Release
builds), and DirectX retail runtime. :)

Javier Arevalo
Pyro Studios

----- Original Message -----
From: "Tom Forsyth" <to...@mu...>
To: "GDWindows" <gam...@li...>
Sent: Wednesday, October 03, 2001 5:41 PM
Subject: RE: [GD-Windows] Win2K SP2 debugging slowdown?


> [grrr... reply-to-person thing is getting annoying now]
>
> The debugger sets up a debug string handler that is usually very very
slow.
> So if you're outputting a lot of info to the debug output, that will cause
> serious slowdowns when the debugger is active. Remember that DirectX also
> throws a lot of stuff into the debug stream if you have the debug level
set
> high.
>
> 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: Emmanuel Astier [mailto:emm...@wi...]
> > Sent: 03 October 2001 14:00
> > To: GDWindows
> > Subject: RE: [GD-Windows] Win2K SP2 debugging slowdown?
> >
> >
> > I have also a strange problem...
> >
> > My game (it is at a very early stage) runs at 1-2 fps in release mode
> > when I launch it under the debugger.
> > When I launch it without the debugger, it runs at 90 fps...
> >
> > There's no massive deallocations, no use of exceptions...
> >
> > I know a launch in the debugger should be slower than a real
> > launch, but
> > not that much ???
> >
> > Emmanuel
> >
> >
> >
> > > -----Original Message-----
> > > From: Javier Arevalo [mailto:ja...@py...]
> > > Sent: mercredi 3 octobre 2001 14:29
> > > To: GDWindows
> > > Subject: Re: [GD-Windows] Win2K SP2 debugging slowdown?
> > >
> > >
> > > If only it were that easy. :)
> > >
> > > The situation happens when the game is run under the
> > > debugger, using the
> > > debug runtime or not doesn't make a difference. The slowdown
> > > magnitude is
> > > huge, about is a few seconds (5-7) versus a couple tenths of
> > > a second so I
> > > have ruled out cache, fragmentation and similar issues.
> > >
> > > Besides, why does it happen only after installing the Win2K
> > > Service Pack 2?
> > > I guess it has something to do with additional security
> > > features of the SP2
> > > for processes that run under a debugger, but that's just my
> > > own elaboration,
> > > and still leaves me with no idea what triggers the slowdown
> > > and how to fix
> > > it.
> > >
> > > The hardware configuration doesn't matter, since it's
> > > happened everywhere
> > > from 2-year-old P3-450's to brand-new 1.4GHz AMDs, 256 or
> > > 512Mb RAM. Heh all
> > > machines have NVidia cards but I really doubt that has
> > > anything to do, since
> > > the slowdown happens in areas with zero D3D interaction -
> > > sound and massive
> > > memory deallocations so far.
> > >
> > > Javier Arevalo
> > > Pyro Studios
> > >
> > > ----- Original Message -----
> > > From: "Tom Forsyth" <to...@mu...>
> > > To: "GDWindows" <gam...@li...>
> > > Sent: Wednesday, October 03, 2001 1:47 PM
> > > Subject: RE: [GD-Windows] Win2K SP2 debugging slowdown?
> > >
> > >
> > > > Sounds like the debug runtime is checking every freed block
> > > to make sure
> > > you
> > > > haven't scribbled off the ends. When you allocate stuff, it
> > > pads the start
> > > > and end with some special characters. IIRC, it pads 16
> > > bytes off start and
> > > > end with FD. When you call free() or delete() or whatever,
> > > it checks that
> > > > the FDs are still there.
> > > >
> > > > I have no idea hy it does this more or less than normal
> > > though - maybe
> > > > because your memory is heavily fragmented on those runs, so
> > > cleanup is
> > > quite
> > > > messy?
> > > >
> > > > 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: Javier Arevalo [mailto:ja...@py...]
> > > > > Sent: 03 October 2001 08:28
> > > > > To: GDWindows
> > > > > Subject: [GD-Windows] Win2K SP2 debugging slowdown?
> > > > >
> > > > >
> > > > > Hi all,
> > > > >
> > > > > We have been tracking a weird situation we have, where on
> > > > > some of our dev.
> > > > > machines our game takes several seconds to shut down. We
> > > > > eventually found
> > > > > out the following:
> > > > >
> > > > > - The game must be running in a debugging session under MSVC
> > > > > (haven't tried
> > > > > other debuggers).
> > > > > - The computer must have Windows 2000 _with_ service pack
> > > 2 installed.
> > > > >
> > > > > The slowdown happens during a loop that deletes several
> > > > > thousand dynamic
> > > > > memory blocks. Most of the time, sometimes it doesn't.
> > > > > Similar symptoms also
> > > > > appear in other places, like our streaming music
> > decoding thread.
> > > > >
> > > > > Running MSDEV under VTune we found that, when the slowdown
> > > > > happens, most of
> > > > > the time during that loop is spent inside the operating
> > > system, spread
> > > > > half-and-half in two functions: RtlCompareMemoryUlong() and
> > > > > RtlFillMemoryUlong().

RE: [GD-Windows] Win2K SP2 debugging slowdown?

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

[grrr... reply-to-person thing is getting annoying now]

The debugger sets up a debug string handler that is usually very very slow.
So if you're outputting a lot of info to the debug output, that will cause
serious slowdowns when the debugger is active. Remember that DirectX also
throws a lot of stuff into the debug stream if you have the debug level set
high.

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: Emmanuel Astier [mailto:emm...@wi...]
> Sent: 03 October 2001 14:00
> To: GDWindows
> Subject: RE: [GD-Windows] Win2K SP2 debugging slowdown?
> 
> 
> I have also a strange problem...
> 
> My game (it is at a very early stage) runs at 1-2 fps in release mode
> when I launch it under the debugger.
> When I launch it without the debugger, it runs at 90 fps...
> 
> There's no massive deallocations, no use of exceptions...
> 
> I know a launch in the debugger should be slower than a real 
> launch, but
> not that much ???
> 
> Emmanuel
> 
> 
> 
> > -----Original Message-----
> > From: Javier Arevalo [mailto:ja...@py...]
> > Sent: mercredi 3 octobre 2001 14:29
> > To: GDWindows
> > Subject: Re: [GD-Windows] Win2K SP2 debugging slowdown?
> > 
> > 
> > If only it were that easy. :)
> > 
> > The situation happens when the game is run under the 
> > debugger, using the
> > debug runtime or not doesn't make a difference. The slowdown 
> > magnitude is
> > huge, about is a few seconds (5-7) versus a couple tenths of 
> > a second so I
> > have ruled out cache, fragmentation and similar issues.
> > 
> > Besides, why does it happen only after installing the Win2K 
> > Service Pack 2?
> > I guess it has something to do with additional security 
> > features of the SP2
> > for processes that run under a debugger, but that's just my 
> > own elaboration,
> > and still leaves me with no idea what triggers the slowdown 
> > and how to fix
> > it.
> > 
> > The hardware configuration doesn't matter, since it's 
> > happened everywhere
> > from 2-year-old P3-450's to brand-new 1.4GHz AMDs, 256 or 
> > 512Mb RAM. Heh all
> > machines have NVidia cards but I really doubt that has 
> > anything to do, since
> > the slowdown happens in areas with zero D3D interaction - 
> > sound and massive
> > memory deallocations so far.
> > 
> > Javier Arevalo
> > Pyro Studios
> > 
> > ----- Original Message -----
> > From: "Tom Forsyth" <to...@mu...>
> > To: "GDWindows" <gam...@li...>
> > Sent: Wednesday, October 03, 2001 1:47 PM
> > Subject: RE: [GD-Windows] Win2K SP2 debugging slowdown?
> > 
> > 
> > > Sounds like the debug runtime is checking every freed block 
> > to make sure
> > you
> > > haven't scribbled off the ends. When you allocate stuff, it 
> > pads the start
> > > and end with some special characters. IIRC, it pads 16 
> > bytes off start and
> > > end with FD. When you call free() or delete() or whatever, 
> > it checks that
> > > the FDs are still there.
> > >
> > > I have no idea hy it does this more or less than normal 
> > though - maybe
> > > because your memory is heavily fragmented on those runs, so 
> > cleanup is
> > quite
> > > messy?
> > >
> > > 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: Javier Arevalo [mailto:ja...@py...]
> > > > Sent: 03 October 2001 08:28
> > > > To: GDWindows
> > > > Subject: [GD-Windows] Win2K SP2 debugging slowdown?
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > We have been tracking a weird situation we have, where on
> > > > some of our dev.
> > > > machines our game takes several seconds to shut down. We
> > > > eventually found
> > > > out the following:
> > > >
> > > > - The game must be running in a debugging session under MSVC
> > > > (haven't tried
> > > > other debuggers).
> > > > - The computer must have Windows 2000 _with_ service pack 
> > 2 installed.
> > > >
> > > > The slowdown happens during a loop that deletes several
> > > > thousand dynamic
> > > > memory blocks. Most of the time, sometimes it doesn't.
> > > > Similar symptoms also
> > > > appear in other places, like our streaming music 
> decoding thread.
> > > >
> > > > Running MSDEV under VTune we found that, when the slowdown
> > > > happens, most of
> > > > the time during that loop is spent inside the operating 
> > system, spread
> > > > half-and-half in two functions: RtlCompareMemoryUlong() and
> > > > RtlFillMemoryUlong().
> > 
> > 
> > 
> > _______________________________________________
> > Gamedevlists-windows mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> > 
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> 

RE: [GD-Windows] Win2K SP2 debugging slowdown?

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

I have also a strange problem...

My game (it is at a very early stage) runs at 1-2 fps in release mode
when I launch it under the debugger.
When I launch it without the debugger, it runs at 90 fps...

There's no massive deallocations, no use of exceptions...

I know a launch in the debugger should be slower than a real launch, but
not that much ???

Emmanuel



> -----Original Message-----
> From: Javier Arevalo [mailto:ja...@py...]
> Sent: mercredi 3 octobre 2001 14:29
> To: GDWindows
> Subject: Re: [GD-Windows] Win2K SP2 debugging slowdown?
>=20
>=20
> If only it were that easy. :)
>=20
> The situation happens when the game is run under the=20
> debugger, using the
> debug runtime or not doesn't make a difference. The slowdown=20
> magnitude is
> huge, about is a few seconds (5-7) versus a couple tenths of=20
> a second so I
> have ruled out cache, fragmentation and similar issues.
>=20
> Besides, why does it happen only after installing the Win2K=20
> Service Pack 2?
> I guess it has something to do with additional security=20
> features of the SP2
> for processes that run under a debugger, but that's just my=20
> own elaboration,
> and still leaves me with no idea what triggers the slowdown=20
> and how to fix
> it.
>=20
> The hardware configuration doesn't matter, since it's=20
> happened everywhere
> from 2-year-old P3-450's to brand-new 1.4GHz AMDs, 256 or=20
> 512Mb RAM. Heh all
> machines have NVidia cards but I really doubt that has=20
> anything to do, since
> the slowdown happens in areas with zero D3D interaction -=20
> sound and massive
> memory deallocations so far.
>=20
> Javier Arevalo
> Pyro Studios
>=20
> ----- Original Message -----
> From: "Tom Forsyth" <to...@mu...>
> To: "GDWindows" <gam...@li...>
> Sent: Wednesday, October 03, 2001 1:47 PM
> Subject: RE: [GD-Windows] Win2K SP2 debugging slowdown?
>=20
>=20
> > Sounds like the debug runtime is checking every freed block=20
> to make sure
> you
> > haven't scribbled off the ends. When you allocate stuff, it=20
> pads the start
> > and end with some special characters. IIRC, it pads 16=20
> bytes off start and
> > end with FD. When you call free() or delete() or whatever,=20
> it checks that
> > the FDs are still there.
> >
> > I have no idea hy it does this more or less than normal=20
> though - maybe
> > because your memory is heavily fragmented on those runs, so=20
> cleanup is
> quite
> > messy?
> >
> > Tom Forsyth - Muckyfoot bloke.
> >
> > What's he up to now (and can I have a go)?
> > http://www.eidosinteractive.com/downloads/search.html?gmid=3D86
> >
> > > -----Original Message-----
> > > From: Javier Arevalo [mailto:ja...@py...]
> > > Sent: 03 October 2001 08:28
> > > To: GDWindows
> > > Subject: [GD-Windows] Win2K SP2 debugging slowdown?
> > >
> > >
> > > Hi all,
> > >
> > > We have been tracking a weird situation we have, where on
> > > some of our dev.
> > > machines our game takes several seconds to shut down. We
> > > eventually found
> > > out the following:
> > >
> > > - The game must be running in a debugging session under MSVC
> > > (haven't tried
> > > other debuggers).
> > > - The computer must have Windows 2000 _with_ service pack=20
> 2 installed.
> > >
> > > The slowdown happens during a loop that deletes several
> > > thousand dynamic
> > > memory blocks. Most of the time, sometimes it doesn't.
> > > Similar symptoms also
> > > appear in other places, like our streaming music decoding thread.
> > >
> > > Running MSDEV under VTune we found that, when the slowdown
> > > happens, most of
> > > the time during that loop is spent inside the operating=20
> system, spread
> > > half-and-half in two functions: RtlCompareMemoryUlong() and
> > > RtlFillMemoryUlong().
>=20
>=20
>=20
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>=20