gamedevlists-windows

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

[Brian S. <bs...@mi...>]

Write to HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE.

-----Original Message-----
From: Brian Hook [mailto:bri...@py...]=20
Sent: Thursday, December 20, 2001 10:16 AM
To: gam...@li...
Subject: [GD-Windows] Security/access when writing to registry

I've had some reports that our game generates an error when it tries to
write to the registry when a user is logged in without admin privileges.
Is this because I'm doing something stupid, or because you simply have
to have admin privileges to install software?

Brian



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

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

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

> Write to HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE.

Can you elaborate on this a bit more (or point me somewhere that does)?
Do you mean simply replace my HKEY_LOCAL_MACHINE places directly with
HKEY_CURRENT_USER?

Brian

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

[Kent Q. <ken...@co...>]

We had a similar problem.

HKEY_LOCAL_MACHINE was originally intended to be the place you put all
the data that was common to all users (such as where to find your app,
etc). Our original install did that, and then put user-specific data in
HKCU. 

But under NT-related OS's, HKLM is inaccessible to anyone other than the
admin user. So we ended up just eating it and putting everything under
HKCU, and if more than one user wants to run the game on the same
machine, they both have to install it (though I guess they could install
it in the same place).

Brian Hook wrote:
> 
> > Write to HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE.
> 
> Can you elaborate on this a bit more (or point me somewhere that does)?
> Do you mean simply replace my HKEY_LOCAL_MACHINE places directly with
> HKEY_CURRENT_USER?

-- 
-----------------------------------------------------------------------
Kent Quirk                   | MindRover: "Astonishingly creative."
Game Architect               | Check it out!
ken...@co...      | http://www.mindrover.com/
_____________________________|_________________________________________

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

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

Yes, I'm revisiting a thread that's over a year old =3D)

I've been using HKCU instead of HKLM like a good Windows app, but=
 it 
seems like you can't win 'em all.

The problem with HKCU is that, well, it's per user.  I've gotten=
 very 
sporadic complaints about having to install our games multiple=
 times 
(including unlock codes), which isn't that big a deal.  But what=
 IS a 
big deal is when you have multiple users on the same machine=
 trying 
to compete against each other, but now their high scores aren't 
shared.  This is a pretty galling thing, since a lot of our games=
 are 
competitive that way and we do find that more than a few of our 
players are on multi-user systems.

Ideas on a clean solution to this problem?

Brian

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

[Matthijs H. <mat...@al...>]

> The problem with HKCU is that, well, it's per user.

I don't know if you can do this with the registry. There is,
however, a "common data" folder on most Windows systems. For
example, on my WinXP box it is "C:\Documents and Settings\All
Users\Application Data".

You can get it with SHGetSpecialFolderLocation(...,
CSIDL_COMMON_APPDATA, ...). In case you have old headers, the
corresponding numeric value is 0x23. There is also a
CSIDL_COMMON_DOCUMENTS folder (0x2e).

This appears to work on all versions of Windows, except NT4
(depending on the version of Internet Explorer that is installed).
In that case, you can get the location of this folder from the
registry key
"HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell
Folders". Not a very clean solution, I know.

Hope it helps,
--
Matthijs Hollemans
www.allyoursoftware.com

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

[Kerim B. <wa...@ho...>]

Hello Brian,

     Support both HKCU and HKLM. If your software is being installed
     by an advanced user let her choose what to use. Like this:
     
     "Do you want this software to be available to all users(requires
     admin rights) or only to the current user?(Yes/No)"

     And on start of your app first, say, look into CU(if the user
     installed this soft for her personally ) and if nothing
     found loook into LM.

Best regards,
 Kerim                            mailto:wa...@ho...

Wednesday, January 22, 2003, 11:01:55 AM, you wrote:

BH> Yes, I'm revisiting a thread that's over a year old =)

BH> I've been using HKCU instead of HKLM like a good Windows app, but it
BH> seems like you can't win 'em all.

BH> The problem with HKCU is that, well, it's per user.  I've gotten very
BH> sporadic complaints about having to install our games multiple times
BH> (including unlock codes), which isn't that big a deal.  But what IS a
BH> big deal is when you have multiple users on the same machine trying
BH> to compete against each other, but now their high scores aren't
BH> shared.  This is a pretty galling thing, since a lot of our games are
BH> competitive that way and we do find that more than a few of our
BH> players are on multi-user systems.

BH> Ideas on a clean solution to this problem?

BH> Brian




BH> -------------------------------------------------------
BH> This SF.net email is sponsored by: Scholarships for Techies!
BH> Can't afford IT training? All 2003 ictp students receive scholarships.
BH> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
BH> www.ictp.com/training/sourceforge.asp
BH> _______________________________________________
BH> Gamedevlists-windows mailing list
BH> Gam...@li...
BH> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
BH> Archives:
BH> http://sourceforge.net/mailarchive/forum.php?forum_idU5

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

[Dan T. <da...@cs...>]

>      And on start of your app first, say, look into CU(if the user
>      installed this soft for her personally ) and if nothing
>      found loook into LM.

This won't nessearily work, because it implies that all users have admin
rights. You suggest that only the installer needs admin rights, but if the
installer puts it in HKLM, and adds it to the start menu for everyone, the
program won't load for Users, because the program won't be able to find it
in HKCU, and it will try HKLM, which will get it an access denied...

You could just have the installer put a copy of it in everyone's HKCU
somehow, but that doesn't solve the high scores problem...

I think your best bet is the common docs folder, or an internet high scores.

-Dan


----- Original Message -----
From: "Kerim Borchaev" <wa...@ho...>
To: "Brian Hook" <gam...@li...>
Sent: Wednesday, January 22, 2003 1:06 AM
Subject: Re[2]: [GD-Windows] Security/access when writing to registry


> Hello Brian,
>
>      Support both HKCU and HKLM. If your software is being installed
>      by an advanced user let her choose what to use. Like this:
>
>      "Do you want this software to be available to all users(requires
>      admin rights) or only to the current user?(Yes/No)"
>
>      And on start of your app first, say, look into CU(if the user
>      installed this soft for her personally ) and if nothing
>      found loook into LM.
>
> Best regards,
>  Kerim                            mailto:wa...@ho...
>
> Wednesday, January 22, 2003, 11:01:55 AM, you wrote:
>
> BH> Yes, I'm revisiting a thread that's over a year old =)
>
> BH> I've been using HKCU instead of HKLM like a good Windows app, but it
> BH> seems like you can't win 'em all.
>
> BH> The problem with HKCU is that, well, it's per user.  I've gotten very
> BH> sporadic complaints about having to install our games multiple times
> BH> (including unlock codes), which isn't that big a deal.  But what IS a
> BH> big deal is when you have multiple users on the same machine trying
> BH> to compete against each other, but now their high scores aren't
> BH> shared.  This is a pretty galling thing, since a lot of our games are
> BH> competitive that way and we do find that more than a few of our
> BH> players are on multi-user systems.
>
> BH> Ideas on a clean solution to this problem?
>
> BH> Brian
>
>
>
>
> BH> -------------------------------------------------------
> BH> This SF.net email is sponsored by: Scholarships for Techies!
> BH> Can't afford IT training? All 2003 ictp students receive scholarships.
> BH> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> BH> www.ictp.com/training/sourceforge.asp
> BH> _______________________________________________
> BH> Gamedevlists-windows mailing list
> BH> Gam...@li...
> BH> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> BH> Archives:
> BH> http://sourceforge.net/mailarchive/forum.php?forum_idU5
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> 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[4]: [GD-Windows] Security/access when writing to registry

[Kerim B. <wa...@ho...>]

Hello Dan,

      Users can read from HKLM. So in case of "for all users"
      installer puts in HKLM "global" settings(like install location)
      to be only read in typical use of the app. And "local"(like
      video options) user settings are created in HKCU when user
      starts the application for the first time.

Best regards,
 Kerim                            mailto:wa...@ho...
 
Wednesday, January 22, 2003, 9:51:40 PM, you wrote:

>>      And on start of your app first, say, look into CU(if the user
>>      installed this soft for her personally ) and if nothing
>>      found loook into LM.

DT> This won't nessearily work, because it implies that all users have admin
DT> rights. You suggest that only the installer needs admin rights, but if the
DT> installer puts it in HKLM, and adds it to the start menu for everyone, the
DT> program won't load for Users, because the program won't be able to find it
DT> in HKCU, and it will try HKLM, which will get it an access denied...

DT> You could just have the installer put a copy of it in everyone's HKCU
DT> somehow, but that doesn't solve the high scores problem...

DT> I think your best bet is the common docs folder, or an internet high scores.

DT> -Dan


DT> ----- Original Message -----
DT> From: "Kerim Borchaev" <wa...@ho...>
DT> To: "Brian Hook" <gam...@li...>
DT> Sent: Wednesday, January 22, 2003 1:06 AM
DT> Subject: Re[2]: [GD-Windows] Security/access when writing to registry


>> Hello Brian,
>>
>>      Support both HKCU and HKLM. If your software is being installed
>>      by an advanced user let her choose what to use. Like this:
>>
>>      "Do you want this software to be available to all users(requires
>>      admin rights) or only to the current user?(Yes/No)"
>>
>>      And on start of your app first, say, look into CU(if the user
>>      installed this soft for her personally ) and if nothing
>>      found loook into LM.
>>
>> Best regards,
>>  Kerim                            mailto:wa...@ho...
>>
>> Wednesday, January 22, 2003, 11:01:55 AM, you wrote:
>>
>> BH> Yes, I'm revisiting a thread that's over a year old =)
>>
>> BH> I've been using HKCU instead of HKLM like a good Windows app, but it
>> BH> seems like you can't win 'em all.
>>
>> BH> The problem with HKCU is that, well, it's per user.  I've gotten very
>> BH> sporadic complaints about having to install our games multiple times
>> BH> (including unlock codes), which isn't that big a deal.  But what IS a
>> BH> big deal is when you have multiple users on the same machine trying
>> BH> to compete against each other, but now their high scores aren't
>> BH> shared.  This is a pretty galling thing, since a lot of our games are
>> BH> competitive that way and we do find that more than a few of our
>> BH> players are on multi-user systems.
>>
>> BH> Ideas on a clean solution to this problem?
>>
>> BH> Brian
>>
>>
>>
>>
>> BH> -------------------------------------------------------
>> BH> This SF.net email is sponsored by: Scholarships for Techies!
>> BH> Can't afford IT training? All 2003 ictp students receive scholarships.
>> BH> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
>> BH> www.ictp.com/training/sourceforge.asp
>> BH> _______________________________________________
>> BH> Gamedevlists-windows mailing list
>> BH> Gam...@li...
>> BH> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>> BH> Archives:
>> BH> http://sourceforge.net/mailarchive/forum.php?forum_idU5
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Scholarships for Techies!
>> Can't afford IT training? All 2003 ictp students receive scholarships.
>> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
>> www.ictp.com/training/sourceforge.asp
>> _______________________________________________
>> Gamedevlists-windows mailing list
>> Gam...@li...
>> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>> Archives:
>> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>>



DT> -------------------------------------------------------
DT> This SF.net email is sponsored by: Scholarships for Techies!
DT> Can't afford IT training? All 2003 ictp students receive scholarships.
DT> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
DT> www.ictp.com/training/sourceforge.asp
DT> _______________________________________________
DT> Gamedevlists-windows mailing list
DT> Gam...@li...
DT> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
DT> Archives:
DT> http://sourceforge.net/mailarchive/forum.php?forum_id=555

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

[Dan T. <da...@cs...>]

Yeah I know, but it still doesn't solve the problem when the user wishes to
update some high score. That requires write access to HLKM, if you choose to
store there, which would fail. Other than something outside the registry,
the only other option would be to read in the high scores from every user
and select the highest, which is also an access denied I believe :)

Dan


----- Original Message -----
From: "Kerim Borchaev" <wa...@ho...>
To: "Dan Thompson" <gam...@li...>
Sent: Wednesday, January 22, 2003 12:15 PM
Subject: Re[4]: [GD-Windows] Security/access when writing to registry


> Hello Dan,
>
>       Users can read from HKLM. So in case of "for all users"
>       installer puts in HKLM "global" settings(like install location)
>       to be only read in typical use of the app. And "local"(like
>       video options) user settings are created in HKCU when user
>       starts the application for the first time.
>
> Best regards,
>  Kerim                            mailto:wa...@ho...
>
> Wednesday, January 22, 2003, 9:51:40 PM, you wrote:
>
> >>      And on start of your app first, say, look into CU(if the user
> >>      installed this soft for her personally ) and if nothing
> >>      found loook into LM.
>
> DT> This won't nessearily work, because it implies that all users have
admin
> DT> rights. You suggest that only the installer needs admin rights, but if
the
> DT> installer puts it in HKLM, and adds it to the start menu for everyone,
the
> DT> program won't load for Users, because the program won't be able to
find it
> DT> in HKCU, and it will try HKLM, which will get it an access denied...
>
> DT> You could just have the installer put a copy of it in everyone's HKCU
> DT> somehow, but that doesn't solve the high scores problem...
>
> DT> I think your best bet is the common docs folder, or an internet high
scores.
>
> DT> -Dan
>
>
> DT> ----- Original Message -----
> DT> From: "Kerim Borchaev" <wa...@ho...>
> DT> To: "Brian Hook" <gam...@li...>
> DT> Sent: Wednesday, January 22, 2003 1:06 AM
> DT> Subject: Re[2]: [GD-Windows] Security/access when writing to registry
>
>
> >> Hello Brian,
> >>
> >>      Support both HKCU and HKLM. If your software is being installed
> >>      by an advanced user let her choose what to use. Like this:
> >>
> >>      "Do you want this software to be available to all users(requires
> >>      admin rights) or only to the current user?(Yes/No)"
> >>
> >>      And on start of your app first, say, look into CU(if the user
> >>      installed this soft for her personally ) and if nothing
> >>      found loook into LM.
> >>
> >> Best regards,
> >>  Kerim                            mailto:wa...@ho...
> >>
> >> Wednesday, January 22, 2003, 11:01:55 AM, you wrote:
> >>
> >> BH> Yes, I'm revisiting a thread that's over a year old =)
> >>
> >> BH> I've been using HKCU instead of HKLM like a good Windows app, but
it
> >> BH> seems like you can't win 'em all.
> >>
> >> BH> The problem with HKCU is that, well, it's per user.  I've gotten
very
> >> BH> sporadic complaints about having to install our games multiple
times
> >> BH> (including unlock codes), which isn't that big a deal.  But what IS
a
> >> BH> big deal is when you have multiple users on the same machine trying
> >> BH> to compete against each other, but now their high scores aren't
> >> BH> shared.  This is a pretty galling thing, since a lot of our games
are
> >> BH> competitive that way and we do find that more than a few of our
> >> BH> players are on multi-user systems.
> >>
> >> BH> Ideas on a clean solution to this problem?
> >>
> >> BH> Brian
> >>
> >>
> >>
> >>
> >> BH> -------------------------------------------------------
> >> BH> This SF.net email is sponsored by: Scholarships for Techies!
> >> BH> Can't afford IT training? All 2003 ictp students receive
scholarships.
> >> BH> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and
more.
> >> BH> www.ictp.com/training/sourceforge.asp
> >> BH> _______________________________________________
> >> BH> Gamedevlists-windows mailing list
> >> BH> Gam...@li...
> >> BH> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> >> BH> Archives:
> >> BH> http://sourceforge.net/mailarchive/forum.php?forum_idU5
> >>
> >>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.net email is sponsored by: Scholarships for Techies!
> >> Can't afford IT training? All 2003 ictp students receive scholarships.
> >> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> >> www.ictp.com/training/sourceforge.asp
> >> _______________________________________________
> >> Gamedevlists-windows mailing list
> >> Gam...@li...
> >> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> >> Archives:
> >> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> >>
>
>
>
> DT> -------------------------------------------------------
> DT> This SF.net email is sponsored by: Scholarships for Techies!
> DT> Can't afford IT training? All 2003 ictp students receive scholarships.
> DT> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> DT> www.ictp.com/training/sourceforge.asp
> DT> _______________________________________________
> DT> Gamedevlists-windows mailing list
> DT> Gam...@li...
> DT> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> DT> Archives:
> DT> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> 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[6]: [GD-Windows] Security/access when writing to registry

[Kerim B. <wa...@ho...>]

Hello Dan,

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

Best regards,
 Kerim                            mailto:wa...@ho...

Thursday, January 23, 2003, 12:02:53 AM, you wrote:

DT> Yeah I know, but it still doesn't solve the problem when the user wishes to
DT> update some high score. That requires write access to HLKM, if you choose to
DT> store there, which would fail. Other than something outside the registry,
DT> the only other option would be to read in the high scores from every user
DT> and select the highest, which is also an access denied I believe :)

DT> Dan


DT> ----- Original Message -----
DT> From: "Kerim Borchaev" <wa...@ho...>
DT> To: "Dan Thompson" <gam...@li...>
DT> Sent: Wednesday, January 22, 2003 12:15 PM
DT> Subject: Re[4]: [GD-Windows] Security/access when writing to registry


>> Hello Dan,
>>
>>       Users can read from HKLM. So in case of "for all users"
>>       installer puts in HKLM "global" settings(like install location)
>>       to be only read in typical use of the app. And "local"(like
>>       video options) user settings are created in HKCU when user
>>       starts the application for the first time.
>>
>> Best regards,
>>  Kerim                            mailto:wa...@ho...
>>
>> Wednesday, January 22, 2003, 9:51:40 PM, you wrote:
>>
>> >>      And on start of your app first, say, look into CU(if the user
>> >>      installed this soft for her personally ) and if nothing
>> >>      found loook into LM.
>>
>> DT> This won't nessearily work, because it implies that all users have
DT> admin
>> DT> rights. You suggest that only the installer needs admin rights, but if
DT> the
>> DT> installer puts it in HKLM, and adds it to the start menu for everyone,
DT> the
>> DT> program won't load for Users, because the program won't be able to
DT> find it
>> DT> in HKCU, and it will try HKLM, which will get it an access denied...
>>
>> DT> You could just have the installer put a copy of it in everyone's HKCU
>> DT> somehow, but that doesn't solve the high scores problem...
>>
>> DT> I think your best bet is the common docs folder, or an internet high
DT> scores.
>>
>> DT> -Dan
>>
>>
>> DT> ----- Original Message -----
>> DT> From: "Kerim Borchaev" <wa...@ho...>
>> DT> To: "Brian Hook" <gam...@li...>
>> DT> Sent: Wednesday, January 22, 2003 1:06 AM
>> DT> Subject: Re[2]: [GD-Windows] Security/access when writing to registry
>>
>>
>> >> Hello Brian,
>> >>
>> >>      Support both HKCU and HKLM. If your software is being installed
>> >>      by an advanced user let her choose what to use. Like this:
>> >>
>> >>      "Do you want this software to be available to all users(requires
>> >>      admin rights) or only to the current user?(Yes/No)"
>> >>
>> >>      And on start of your app first, say, look into CU(if the user
>> >>      installed this soft for her personally ) and if nothing
>> >>      found loook into LM.
>> >>
>> >> Best regards,
>> >>  Kerim                            mailto:wa...@ho...
>> >>
>> >> Wednesday, January 22, 2003, 11:01:55 AM, you wrote:
>> >>
>> >> BH> Yes, I'm revisiting a thread that's over a year old =)
>> >>
>> >> BH> I've been using HKCU instead of HKLM like a good Windows app, but
DT> it
>> >> BH> seems like you can't win 'em all.
>> >>
>> >> BH> The problem with HKCU is that, well, it's per user.  I've gotten
DT> very
>> >> BH> sporadic complaints about having to install our games multiple
DT> times
>> >> BH> (including unlock codes), which isn't that big a deal.  But what IS
DT> a
>> >> BH> big deal is when you have multiple users on the same machine trying
>> >> BH> to compete against each other, but now their high scores aren't
>> >> BH> shared.  This is a pretty galling thing, since a lot of our games
DT> are
>> >> BH> competitive that way and we do find that more than a few of our
>> >> BH> players are on multi-user systems.
>> >>
>> >> BH> Ideas on a clean solution to this problem?
>> >>
>> >> BH> Brian

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

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

[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

[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

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

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

[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

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

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

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

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

> Multi-monitor support is a bit of a mess.

My heuristic is that if the display is wider than 16:9 form factor,=20
it's probably two displays side-by-side, and I treat it according=20
to that. No other special casing. This takes care of 95% of the=20
special cases (which are only 5% of all users to begin with -- tops!)

I suppose you could document an ultra-l33t config file where the=20
user can determine what monitor for you to use, and what mode to set=20
it in, and where to put the viewport on that monitor. Document it for=20
the ten people who care to find it, and all your mass market=20
consumers won't be confused by an array of senseless check boxes and=20
popup menus ;-)

Cheers,

			/ h+

RE: [GD-Windows] More multimon

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

>My heuristic is that if the display is wider than 16:9 form=
 factor,
>it's probably two displays side-by-side, and I treat it=
 according to
>that.

That's part of the heuristic I will end up using.  I think the=
 Apple 
Cinema Displays are the stretchiest out there.

>No other special casing. This takes care of 95% of the special
>cases (which are only 5% of all users to begin with -- tops!)

That's a good point, but as a multimon user, I have a personal 
interest in the matter, especially after having played several=
 games 
now that try to center themselves right between my monitors.

>consumers won't be confused by an array of senseless check boxes=
 and
> popup menus ;-)

This is also a good point.  I don't mind the multimon hacking=
 about, 
but the nVidia "I'm just a big wide monitor as far you're=
 concerned" 
thing is kind of annoying because it's probably the single most 
prevalent multimon config out there.

As a short term hack I'll probably just have a check box in=
 graphics 
options to allow windowed mode along with a "use current screen 
resolution" check box which I'll use as a cue to do the centered=
 
window thing.

Brian

Re: [GD-Windows] More multimon

[Eero P. <epa...@ko...>]

Brian Hook wrote:
> 
> 
> This is also a good point.  I don't mind the multimon hacking about, 
> but the nVidia "I'm just a big wide monitor as far you're concerned" 
> thing is kind of annoying because it's probably the single most 
> prevalent multimon config out there.
> 
>

I was extremely happy when I tried and found this working on a
Windows XP machine. Considering Microsoft support for OpenGL
I don't know how I would be able to get fullscreen HW-accelerated
(OpenGL) graphics for both projectors without it.


		Eero

Re: [GD-Windows] More multimon

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

I wonder gow the Matrox drivers solve this - I know that Serious Sam had an
option to render on two displays simmultaneously using when some Matrox c
----- Original Message -----
From: "Eero Pajarre" <epa...@ko...>
To: <gam...@li...>
Sent: Monday, March 31, 2003 12:45 PM
Subject: Re: [GD-Windows] More multimon


> Brian Hook wrote:
> >
> >
> > This is also a good point.  I don't mind the multimon hacking about,
> > but the nVidia "I'm just a big wide monitor as far you're concerned"
> > thing is kind of annoying because it's probably the single most
> > prevalent multimon config out there.
> >
> >
>
> I was extremely happy when I tried and found this working on a
> Windows XP machine. Considering Microsoft support for OpenGL
> I don't know how I would be able to get fullscreen HW-accelerated
> (OpenGL) graphics for both projectors without it.
>
>
> Eero
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>
>