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

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

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

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 turn around
and call the global versions.

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 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 monitor the
game's memory usage and fragmentation.

j

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



In article <E18...@sc...>,
    Ben Hawes <cr...@ca...>  writes:

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

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

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

I'd use a static library unless there really is some overriding
reason to use a DLL.  "It just works" that way.

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

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

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.

Rich wrote:
>
>> in the game exe, I call wibble =3D new CFooBar;
>> Later on, within the exe, I call delete wibble; and get an Assert=
>>  warning because I'm deallocating from the wrong heap.
>
> 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).
>
> 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
>
> I'd use a static library unless there really is some overriding
> reason to use a DLL.  "It just works" that way.

  Javier Arevalo
  Pyro Studios

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

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

Welcome to DLL hell.

There are two kinds of DLL hell: the Unix hell, where some library can=20
decide to replace malloc() in the global symbol table, and suddenly=20
you're running with some other allocator than you tested your code=20
with; and the Windows hell, where each DLL can run with its own=20
allocator (say, debug vs release vs version 7.0), which means that you=20
have to balance all allocations and deletions.

The only sane way around this that I've found is to base your cross-
DLL object model on factory functions and abstract interfaces, and use=20
"deleteYourself()" as a virtual function to delete an instance (or go=20
all the way and acquire()/release() with ref counting).

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

Also, for the same reasons, inline functions are often a very bad idea=20
for objects that are supposed to live in DLLs. First, because you have=20
to re-compile the user when you change the implementation of the object=20
(so you can't rev the DLL separately unless you take a LOT of care).=20
Second, because if you happen to allocate memory, then the inline may=20
live in one of many different modules. This is especially bad with STL=20
style containers.

Cheers,

				/ h+



> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Ben Hawes
> Sent: Monday, March 24, 2003 9:08 AM
> To: gam...@li...
> Subject: [GD-Windows] new/delete across DLL's
>=20
>=20
> Am I doing something wrong, or is this correct behaviour:
>=20
> in core.dll I have a class CFooBar.
>=20
> in the game exe, I call wibble =3D new CFooBar;
> Later on, within the exe, I call delete wibble; and get an Assert=20
> warning because I'm deallocating from the wrong heap.
>=20
> This seems very strange, that I can only deallocate a class=20
> defined in a DLL from within that DLL, even if the instance was=20
> allocated somewhere else. Am I understanding this correctly, or=20
> am I doing something else to cause the problem? Is there any way=20
> round this?
>=20
> [ cruise / casual-tempest.net / transference.org ]
>=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

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

In article <E18...@sc...>,
    Ben Hawes <cr...@ca...>  writes:

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

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

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

I'd use a static library unless there really is some overriding
reason to use a DLL.  "It just works" that way.
-- 
"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>

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

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

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 =3D 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 ]

RE: [GD-Windows] PDB files

[Matt N. <mat...@ni...>]

Thanks, that seems to be what I'm looking for.

Matt.

> -----Original Message-----
> From: Paul Bleisch [mailto:pa...@mi...]=20
> Sent: 27 February 2003 15:09
> To: gam...@li...
> Subject: RE: [GD-Windows] PDB files
>=20
>=20
>=20
> You might look at John Robbins crash finder stuff:
>=20
> http://www.wintellect.com/about/instructors/robbins/default.aspx
>=20
> > -----Original Message-----
> > From: Matt Newport [mailto:mat...@ni...]
> > Sent: Thursday, February 27, 2003 5:20 AM
> > To: gam...@li...
> > Subject: [GD-Windows] PDB files
> >=20
> >=20
> > Given a .PDB file and a Windows crash report containing the
> > values of the CS and EIP pointers what's the easiest way of=20
> > finding the associated function and line number? I know you=20
> > can do this by loading the project into Visual Studio and=20
> > setting a breakpoint but it seems there ought to be an easier=20
> > / more direct way of doing this.
> >=20
> > Thanks,
> >=20
> > Matt.
> >=20
> > ---
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.458 / Virus Database: 257 - Release Date: 24/02/2003
> > =20
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.NET email is sponsored by:
> > SourceForge Enterprise Edition + IBM + LinuxWorld =3Domething 2 See! =

> > http://www.vasoftware.com=20
> > _______________________________________________
> > Gamedevlists-windows mailing list=20
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> > Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU5
> >=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf=20
> _______________________________________________
> Gamedevlists-windows mailing list=20
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU5
>=20
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.458 / Virus Database: 257 - Release Date: 24/02/2003
> =20
>=20

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.458 / Virus Database: 257 - Release Date: 24/02/2003
=20

RE: [GD-Windows] PDB files

[Paul B. <pa...@mi...>]

You might look at John Robbins crash finder stuff:

http://www.wintellect.com/about/instructors/robbins/default.aspx

> -----Original Message-----
> From: Matt Newport [mailto:mat...@ni...]=20
> Sent: Thursday, February 27, 2003 5:20 AM
> To: gam...@li...
> Subject: [GD-Windows] PDB files
>=20
>=20
> Given a .PDB file and a Windows crash report containing the=20
> values of the CS and EIP pointers what's the easiest way of=20
> finding the associated function and line number? I know you=20
> can do this by loading the project into Visual Studio and=20
> setting a breakpoint but it seems there ought to be an easier=20
> / more direct way of doing this.
>=20
> Thanks,
>=20
> Matt.
>=20
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.458 / Virus Database: 257 - Release Date: 24/02/2003
> =20
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =3Domething 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU5
>=20

[GD-Windows] PDB files

[Matt N. <mat...@ni...>]

Given a .PDB file and a Windows crash report containing the values of =
the CS and EIP pointers what's the easiest way of finding the associated =
function and line number? I know you can do this by loading the project =
into Visual Studio and setting a breakpoint but it seems there ought to =
be an easier / more direct way of doing this.

Thanks,

Matt.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.458 / Virus Database: 257 - Release Date: 24/02/2003
=20

Re: [GD-Windows] CreateFontIndirect strage behaviour

[Grisha S. <_g...@tu...>]

I get this results only with lfFaceName set to "Courier New". With "Lucida
Console" all works if antialiasing not disabled in
DisplayProperties/Appearance/Effects. Both fonts is OpenType fonts, there is
no other Courier New fonts in system (only bold&italic versions) and it
supports antialiasing - i can get ClearType antialiasing on it, but can't
get standard antialiasing.

And I can't get antialiasig in any form if it is disabled in
DisplayProperties/Appearance/Effects.

Display is 32-bit color. And I select font into device context:
 HGDIOBJ hFontOld2 = SelectObject( GetDC( 0 ), (HGDIOBJ)hFont );
 HGDIOBJ hFontOld1 = SelectObject( hDC, (HGDIOBJ)hFont );
 HGDIOBJ hFontOld = SelectObject( hMemoryDC, (HGDIOBJ)hFont );

-grisha

RE: [GD-Windows] CreateFontIndirect strage behaviour

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

> When I set lfQuality in LOGFONT structure to ANTIALIASED_QUALITY 
> I get NONantialiased font.

Select it into a real screen (physical device) DC before selecting 
it into your offscreen DC.

Cheers,

                                / h+

Re: [GD-Windows] CreateFontIndirect strage behaviour

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

>From MSDN:
-------------
Windows NT 4.0 and later: Font is antialiased, or smoothed, if the font
supports it and the size of the font is not too small or too large.

Windows 95 with Plus!, Windows 98/Me: The display must greater than 8-bit
color, it must be a single plane device, it cannot be a palette display, and
it cannot be in a multiple display monitor setup. In addition, you must
select a TrueType font into a screen DC prior to using it in a DIBSection,
otherwise antialiasing does not happen.
-------------

Also check this out, he talks a bit about situations where Windows
will/won't honor the flag:

http://unreal.epicgames.com/TTFImport.htm

Hope this helps.

Grisha Spivak wrote:
> Hi,
> During writing the routine on creating font texture I have faced with
> strange behaviour of CreateFontIndirect.
> When I set lfQuality in LOGFONT structure to ANTIALIASED_QUALITY I get
> NONantialiased font.
>
> With over values of lfQuality I get following results:
>
> with antialiasing settings set to ClearType in
> DisplayProperties/Appearance/Effects:
>
> DEFAULT_QUALITY - ClearType (color pixels)
> DRAFT_QUALITY - antialiased font (grayscale)
> PROOF_QUALITY - ClearType
> NONANTIALIASED_QUALITY - nonantialiased
> ANTIALIASED_QUALITY - nonantialiased - WHY????
> CLEARTYPE_QUALITY - ClearType
>
> with antialiasing settings set to Standard:
> all - nonantialiased, only CLEARTYPE_QUALITY - ClearType
>
> with antialiasing settings set to Off:
> all - nonantialiased
>
> lfFaceName is "Courier New"
> lfHeight = -20
>
> Is it normal?
>
> -grisha
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555

[GD-Windows] CreateFontIndirect strage behaviour

[Grisha S. <_g...@tu...>]

Hi,
During writing the routine on creating font texture I have faced with
strange behaviour of CreateFontIndirect.
When I set lfQuality in LOGFONT structure to ANTIALIASED_QUALITY I get
NONantialiased font.

With over values of lfQuality I get following results:

with antialiasing settings set to ClearType in
DisplayProperties/Appearance/Effects:

DEFAULT_QUALITY - ClearType (color pixels)
DRAFT_QUALITY - antialiased font (grayscale)
PROOF_QUALITY - ClearType
NONANTIALIASED_QUALITY - nonantialiased
ANTIALIASED_QUALITY - nonantialiased - WHY????
CLEARTYPE_QUALITY - ClearType

with antialiasing settings set to Standard:
all - nonantialiased, only CLEARTYPE_QUALITY - ClearType

with antialiasing settings set to Off:
all - nonantialiased

lfFaceName is "Courier New"
lfHeight = -20

Is it normal?

-grisha

[GD-Windows] IME question

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

Hi,

our IME support seems to be working well, but we're still unable to prevent
the F5 key from popping up the IME pad window - right now the window shows
ups with the usual fullscreen flickering.

Any ideas?

  Javier Arevalo
  Pyro Studios

Re: [GD-Windows] Security/access when writing to registry

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

I thought you would use SHGetSpecialFolderPath() instead.

Dale Freya <df...@op...> wrote:
>> Are you sure this is true for Windows 98? From MSDN, "Shell and
>> Common Controls Versions"
>> (MSDN\Shellcc.chm::/shellcc/Shell/versions.htm): 
>> 
>> "All Windows 98 systems have version 4.72 of Shell32.dll."
>> 
>> It _is_ true for Windfows 95, though.
> 
> SHGetFolderPath requires shell32.dll version 5.0 or later.
> SHGetFolderPath can only be accessed on Windows 98 through the
> ShFolder.dll redistributable.
> 
> http://msdn.microsoft.com/library/en-
> us/shellcc/platform/shell/reference
> /functions/shgetfolderpath.asp?frame=true 
> 
> - Dale
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555


  Javier Arevalo
  Pyro Studios

RE: [GD-Windows] Security/access when writing to registry

[Dale F. <df...@op...>]

> Are you sure this is true for Windows 98? From MSDN, "Shell and Common
> Controls Versions" (MSDN\Shellcc.chm::/shellcc/Shell/versions.htm):
> 
> "All Windows 98 systems have version 4.72 of Shell32.dll."
>
> It _is_ true for Windfows 95, though.

SHGetFolderPath requires shell32.dll version 5.0 or later.
SHGetFolderPath can only be accessed on Windows 98 through the
ShFolder.dll redistributable.

http://msdn.microsoft.com/library/en-us/shellcc/platform/shell/reference
/functions/shgetfolderpath.asp?frame=true

- Dale

Re: [GD-Windows] Security/access when writing to registry

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

Are you sure this is true for Windows 98? From MSDN, "Shell and Common
Controls Versions" (MSDN\Shellcc.chm::/shellcc/Shell/versions.htm):

"All Windows 98 systems have version 4.72 of Shell32.dll."

It _is_ true for Windfows 95, though.

Dale Freya <df...@op...> wrote:
> The SHGetFolderPath functionality is available on Win98 in the
> ShFolder.dll Platform SDK redistributable.
>
> http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdkredist.htm
>
> If you want to use SHGetFolderPath on Win98 make sure you always link
> to the SHGetFolderPath in ShFolder.dll and not the one in shell32.dll.
>
> See...
> How to play well with WindowsR XP
> http://www.microsoft.com/mscorp/corpevents/meltdown2001/presentations.as
> p
> Mike Burrows - Microsoft Corporation [Meltdown 2001]
>
> - Dale
>
>
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Jon Watte
> Sent: Friday, 24 January 2003 4:28 AM
> To: gam...@li...
> Subject: RE: [GD-Windows] Security/access when writing to registry
>
>
>> Is it impossible to put that stuff along with save data in the
>> folder where
>> the game was installed ???
>
> Yes; if the game is installed by a user who is administrator, and
> then run by a user who is not, the second user won't be able to
> write to the folder where the game is installed. Lots of older
> games are failing on Windows XP for this reason (or forcing users
> to run as Administrator all the time, which is bad for different
> reasons).
>
>> Personaly I'm swearing each time some "smart" pc developper put
>> settings, highscores and save games in some weird location in my
>> computer, because it
>> means I cannot backup my game saves.
>
> I'd be happy if they just DOCUMENTED where these were. I use three
> different computers at different times during the week, and I want
> to drag my savegames with me. Some games make finding out what I
> need to drag with me easier than others.
>
> The right thing to do, really, is using the
> SHGetSpecialFolderLocation() call (NT4, Win95) or the
> SHGetFolderLocation() call (Win2k, WinME). Pass
> CSIDL_COMMON_DOCUMENTS on < WinME/Win2k; possibly pass
> CSIDL_COMMON_APPDATA on Win2k and WinME and later (too bad that's
> not available for Win98)
>
> On the MacOS, the FindFolder() function has been around since the
> late '80s, so users are quite used to finding the "settings" folder
> and expecting all application settings to go there.
>
> Cheers,
>
> / h+
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555


  Javier Arevalo
  Pyro Studios

RE: [GD-Windows] Security/access when writing to registry

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

> I agree though, it is a *real* pain in Windows to transfer application
> data
> (i.e Outlook Express with mail, folders, addresses * newsgroups) to
> another
> computer.

Hmmm, I've not really considered a 'travelling' install. Although if I were
aiming to support such a feature then maybe an extra option on the
applications start bar entry would be an option? (ie. "Programs->My
App->Build Travel Bag" or some-such).

Wayney
"I'm sure at least 2% of my mails are not inane babble!" - Wayne Coles, 2003

-Virus scanned and cleared ok

RE: [GD-Windows] Security/access when writing to registry

[Dale F. <df...@op...>]

The SHGetFolderPath functionality is available on Win98 in the
ShFolder.dll Platform SDK redistributable.

http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdkredist.htm

If you want to use SHGetFolderPath on Win98 make sure you always link to
the SHGetFolderPath in ShFolder.dll and not the one in shell32.dll.

See...
How to play well with WindowsR XP
http://www.microsoft.com/mscorp/corpevents/meltdown2001/presentations.as
p
Mike Burrows - Microsoft Corporation [Meltdown 2001]

- Dale


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Jon Watte
Sent: Friday, 24 January 2003 4:28 AM
To: gam...@li...
Subject: RE: [GD-Windows] Security/access when writing to registry


> Is it impossible to put that stuff along with save data in the 
> folder where
> the game was installed ???

Yes; if the game is installed by a user who is administrator, and 
then run by a user who is not, the second user won't be able to 
write to the folder where the game is installed. Lots of older 
games are failing on Windows XP for this reason (or forcing users 
to run as Administrator all the time, which is bad for different 
reasons).

> Personaly I'm swearing each time some "smart" pc developper put
settings,
> highscores and save games in some weird location in my computer, 
> because it
> means I cannot backup my game saves.

I'd be happy if they just DOCUMENTED where these were. I use three 
different computers at different times during the week, and I want 
to drag my savegames with me. Some games make finding out what I 
need to drag with me easier than others.

The right thing to do, really, is using the 
SHGetSpecialFolderLocation() call (NT4, Win95) or the 
SHGetFolderLocation() call (Win2k, WinME). Pass 
CSIDL_COMMON_DOCUMENTS on < WinME/Win2k; possibly pass 
CSIDL_COMMON_APPDATA on Win2k and WinME and later (too bad that's 
not available for Win98)

On the MacOS, the FindFolder() function has been around since the 
late '80s, so users are quite used to finding the "settings" folder 
and expecting all application settings to go there.

Cheers,

				/ h+



-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=555

RE: [GD-Windows] Security/access when writing to registry

[Andrew G. <ag...@cl...>]

If it's Win98 you can just bung the scores file in the same directory where
the game was installed to.

I agree though, it is a *real* pain in Windows to transfer application data
(i.e Outlook Express with mail, folders, addresses * newsgroups) to another
computer. 


Andy @ 
Climax Brighton 



> -----Original Message-----
> From: Jon Watte [mailto:hp...@mi...]
> Sent: 23 January 2003 18:28
> To: gam...@li...
> Subject: RE: [GD-Windows] Security/access when writing to registry
> 
> 
> 
> > For me it's summarised in one single choice: If it's worthwhile 
> > for the user
> > to backup it, use the "app local data" you are talking about.
> 
> But that doesn't solve the initial problem, which was data shared 
> by ALL users, such as highscores. You need the "global" versions 
> of these folders.
> 
> Unfortunately, appdata is only defined on WinME/Win2k, so if you 
> want to support Win98 (you do!) then you'll have to go with a 
> "documents" kind of folder :-( Or maybe not support high score 
> sharing on that version of Windows.
> 
> Cheers,
> 
> 			/ h+
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 

RE: [GD-Windows] Security/access when writing to registry

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

> For me it's summarised in one single choice: If it's worthwhile 
> for the user
> to backup it, use the "app local data" you are talking about.

But that doesn't solve the initial problem, which was data shared 
by ALL users, such as highscores. You need the "global" versions 
of these folders.

Unfortunately, appdata is only defined on WinME/Win2k, so if you 
want to support Win98 (you do!) then you'll have to go with a 
"documents" kind of folder :-( Or maybe not support high score 
sharing on that version of Windows.

Cheers,

			/ h+

RE: [GD-Windows] Security/access when writing to registry

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

> Is it impossible to put that stuff along with save data in the 
> folder where
> the game was installed ???

Yes; if the game is installed by a user who is administrator, and 
then run by a user who is not, the second user won't be able to 
write to the folder where the game is installed. Lots of older 
games are failing on Windows XP for this reason (or forcing users 
to run as Administrator all the time, which is bad for different 
reasons).

> Personaly I'm swearing each time some "smart" pc developper put settings,
> highscores and save games in some weird location in my computer, 
> because it
> means I cannot backup my game saves.

I'd be happy if they just DOCUMENTED where these were. I use three 
different computers at different times during the week, and I want 
to drag my savegames with me. Some games make finding out what I 
need to drag with me easier than others.

The right thing to do, really, is using the 
SHGetSpecialFolderLocation() call (NT4, Win95) or the 
SHGetFolderLocation() call (Win2k, WinME). Pass 
CSIDL_COMMON_DOCUMENTS on < WinME/Win2k; possibly pass 
CSIDL_COMMON_APPDATA on Win2k and WinME and later (too bad that's 
not available for Win98)

On the MacOS, the FindFolder() function has been around since the 
late '80s, so users are quite used to finding the "settings" folder 
and expecting all application settings to go there.

Cheers,

				/ h+

RE: [GD-Windows] Security/access when writing to registry

[Mickael P. <mpo...@ed...>]

Wayne Coles wrote:
>> Personaly I'm swearing each time some "smart" pc developper put
>> settings, highscores and save games in some weird location in my
>> computer, because it means I cannot backup my game saves.
>
> Although I don't think the registry is the correct place to store
> 'shared' information. I also don't think the applications local
> directory tree is the correct place either. The ability to 'lock
> down' what an application can do is part of where the OS is going
> (Windows anyway).

Okay.
When I was talking about the "folder where the program is installed", I was
refering in general to any well documented place where the user can expect
to find his data.


> If it's for a single user and it's small, I suggest the registry.
> If it's for a single user and it's large, I suggest the app local data
> directory (as mentioned before, obtained by calling
> SHGetSpecialFolderPath with CSIDL_APPDATA).
> If it's shared across users, I suggest the app common data directory
> (SHGetSpecialFolderPath with CSIDL_COMMON_APPDATA).

For me it's summarised in one single choice: If it's worthwhile for the user
to backup it, use the "app local data" you are talking about.

    Mickael Pointier

RE: [GD-Windows] Security/access when writing to registry

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

> Personaly I'm swearing each time some "smart" pc developper put settings,
> highscores and save games in some weird location in my computer, because
> it means I cannot backup my game saves.

Although I don't think the registry is the correct place to store 'shared'
information. I also don't think the applications local directory tree is the
correct place either. The ability to 'lock down' what an application can do
is part of where the OS is going (Windows anyway).

Even now, the .net framework allows the user to prevent applications writing
anywhere they like. Providing 'isolated storage' (which is basically the
app-data directory someone mentioned before). So in the future you're
application may not be able to write to its home directory.

If it's for a single user and it's small, I suggest the registry.
If it's for a single user and it's large, I suggest the app local data
directory (as mentioned before, obtained by calling SHGetSpecialFolderPath
with CSIDL_APPDATA).
If it's shared across users, I suggest the app common data directory
(SHGetSpecialFolderPath with CSIDL_COMMON_APPDATA).

Personally I quite like the idea, although I'm known to be a little strange
(by some) :)

Wayney
"I'm sure at least 2% of my mails are not inane babble!" - Wayne Coles, 2003

-Virus scanned and cleared ok

RE: [GD-Windows] Security/access when writing to registry

[Gareth L. <GL...@cl...>]

Mickael.

> Perhaps that due to my less than average english skills I 
> missed something
> of the whole thread, but why actually do you want to put this 
> kind of things
> in the registry ???

Well, it makes sense.

> Is it impossible to put that stuff along with save data in 
> the folder where
> the game was installed ???

That is the first thing a lot of us ask. You can't put the data in the
directory the game was installed, because the directory the game was
installed in, isn't always writable to the player. For example, most games
install under "Program Files". As said before, someone might decide that for
their children, Program Files will not be writable, so now when little
Johnny makes a high-score, the game crashes.

> Personaly I'm swearing each time some "smart" pc developper 
> put settings,
> highscores and save games in some weird location in my 
> computer, because it
> means I cannot backup my game saves.

True, but there are only 2 real options, Registry and a directory guarenteed
to be writable, for example "Documents and Settings\All Users". And for save
games, that makes a lot of sense. But if all you want to store are
high-scores, then to me, personally, the registry makes more sense.

Anyway, even if you do use the All Users directory, you still want to store
what directory you used in the registry :)

> Sometimes better is worse.

Yes, but sometimes simpler is wrong.

Re: [GD-Windows] Security/access when writing to registry

[Mickael P. <mpo...@ed...>]

>    It seems that I simply ignored this stuff about sharing
>    highscores;-(

Perhaps that due to my less than average english skills I missed something
of the whole thread, but why actually do you want to put this kind of things
in the registry ???

Is it impossible to put that stuff along with save data in the folder where
the game was installed ???

Personaly I'm swearing each time some "smart" pc developper put settings,
highscores and save games in some weird location in my computer, because it
means I cannot backup my game saves.

Recently I had to change my computer and was more than happy to be able to
copy save games of most of what I had installed directly in the program
folder on the new pc.

Sometimes better is worse.

    Mickael Pointier (perplexifié)