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

RE: [GD-Windows] Icon for game window

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

> and in the reference for WNDCLASS:
> 
>     hIcon 
>     Handle to the class icon. This member must be a handle to an icon
>     resource. If this member is NULL, the system provides a default
>     icon. 


There's also a hIconSm in the WNDCLASSEX structure.

hIconSm 
    Handle to a small icon that is associated with the window class. 
    If this member is NULL, the system searches the icon resource 
    specified by the hIcon member for an icon of the appropriate size 
    to use as the small icon. 


http://msdn.microsoft.com/

It even has a useful "search" field (though I wish the default search 
scope would exclude all that Windows CE nonsense :-)


Cheers,

			/ h+

RE: [GD-Windows] Icon for game window

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

A-ha!  I was doing that, however I botched up the call to LoadIcon by
passing NULL as the first parameter instead of hInstance.  Doh.

Thanks!

Brian


> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Andrew Grant
> Sent: Monday, January 07, 2002 9:45 AM
> To: gam...@li...
> Subject: RE: [GD-Windows] Icon for game window
> 
> 
> set WNDCLASS.hIcon before you register the class for your main window.
> 
> Andrew Grant
> Hothouse Creations 
> 
> 
> 
> > -----Original Message-----
> > From: Brian Hook [mailto:bri...@py...]
> > Sent: 07 January 2002 17:34
> > To: 'Gamedevlists-Windows@Lists. Sourceforge. Net'
> > Subject: [GD-Windows] Icon for game window
> > 
> > 
> > What magical bit of tomfoolery do I need to do to have my
> > application's
> > icon show up in the caption bar?  I'm already using 
> LoadIcon() to load
> > the correct icon, and it shows up correctly in Explorer 
> when browsing
> > directories, just not in the caption.
> > 
> > Thanks,
> > 
> > Brian
> > 
> > 
> > _______________________________________________
> > Gamedevlists-windows mailing list 
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> > 
> 
> 
> This email is covered by the following disclaimer, please 
> read before accepting this email. http://www.hothouse.org/disclaimer/
> 
> _______________________________________________
> Gamedevlists-windows mailing list 
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> 

RE: [GD-Windows] Icon for game window

[Andrew G. <And...@ho...>]

Just incase you meant dynamically, you can use WM_SETICON to do the same
thing at any time while your program is running.

Andrew Grant
Hothouse Creations 



> -----Original Message-----
> From: Andrew Grant [mailto:And...@ho...]
> Sent: 07 January 2002 17:45
> To: gam...@li...
> Subject: RE: [GD-Windows] Icon for game window
> 
> 
> set WNDCLASS.hIcon before you register the class for your main window.
> 
> Andrew Grant
> Hothouse Creations 
> 
> 
> 
> > -----Original Message-----
> > From: Brian Hook [mailto:bri...@py...]
> > Sent: 07 January 2002 17:34
> > To: 'Gamedevlists-Windows@Lists. Sourceforge. Net'
> > Subject: [GD-Windows] Icon for game window
> > 
> > 
> > What magical bit of tomfoolery do I need to do to have my 
> > application's
> > icon show up in the caption bar?  I'm already using 
> LoadIcon() to load
> > the correct icon, and it shows up correctly in Explorer 
> when browsing
> > directories, just not in the caption.
> > 
> > Thanks,
> > 
> > Brian
> > 
> > 
> > _______________________________________________
> > Gamedevlists-windows mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> > 
> 
> 
> This email is covered by the following disclaimer, please read before
> accepting this email. http://www.hothouse.org/disclaimer/
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> 


This email is covered by the following disclaimer, please read before
accepting this email. http://www.hothouse.org/disclaimer/

Re: [GD-Windows] Icon for game window

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

In article <001a01c197a1$84d1df00$0101a8c0@HOOKDELL220>,
    Brian Hook <bri...@py...>  writes:

> What magical bit of tomfoolery do I need to do to have my application's
> icon show up in the caption bar?

MSDN Library January 2001 / Platform SDK / User Interface Services /
Windows user Interface / Windowing / Windows / About Windows /
Application Windows, in the section heading "Nonclient Area":

    ``The title bar displays an application-defined icon and line of
    text; typically, the text specifies the name of the application or
    indicates the purpose of the window. An application specifies the
    icon and text when creating the window. The title bar also makes
    it possible for the user to move the window by using a mouse or
    other pointing device.''

and in the reference for WNDCLASS:

    hIcon 
    Handle to the class icon. This member must be a handle to an icon
    resource. If this member is NULL, the system provides a default
    icon. 

I beleive this is where you set it.
--
Ask me about my upcoming book on Direct3D from Addison-Wesley!
  Direct3D Book <http://www.xmission.com/~legalize/book/>
    Don't Support Spammers!  Boycott Fractal Painter 7!
     <http://www.xmission.com/~legalize/spammers.html>

RE: [GD-Windows] Icon for game window

[Andrew G. <And...@ho...>]

set WNDCLASS.hIcon before you register the class for your main window.

Andrew Grant
Hothouse Creations 



> -----Original Message-----
> From: Brian Hook [mailto:bri...@py...]
> Sent: 07 January 2002 17:34
> To: 'Gamedevlists-Windows@Lists. Sourceforge. Net'
> Subject: [GD-Windows] Icon for game window
> 
> 
> What magical bit of tomfoolery do I need to do to have my 
> application's
> icon show up in the caption bar?  I'm already using LoadIcon() to load
> the correct icon, and it shows up correctly in Explorer when browsing
> directories, just not in the caption.
> 
> Thanks,
> 
> Brian
> 
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> 


This email is covered by the following disclaimer, please read before
accepting this email. http://www.hothouse.org/disclaimer/

[GD-Windows] Icon for game window

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

What magical bit of tomfoolery do I need to do to have my application's
icon show up in the caption bar?  I'm already using LoadIcon() to load
the correct icon, and it shows up correctly in Explorer when browsing
directories, just not in the caption.

Thanks,

Brian

RE: [GD-Windows] TryEnterCriticalSection

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

> It seems to me that the best approach is use OS locks and minimize the
> time locks are held.  Am I missing something here?

The non-blocking FIFO is supposed to be sized big enough that 
"normal" operating conditions always leaves free space in it. 

Thus, the normal case is to pay no additional cost except 
the memory bus atomic instruction cost, which is small for 
most architectures (compared to entering the kernel -- ouch!)

You can get some of the same benefits by wrapping your 
blocking kernel primitive in an atomic memory primitive, and 
only call into the kernel when you actually need to block; 
assuming low contention this is a win. When we did BeOS, we 
called this pattern a "benaphore"; you might turn up something 
with a web search on that term.

Cheers,

				/ h+

RE: [GD-Windows] TryEnterCriticalSection

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

I'm not sure that "snooze and re-try" is much better than calling a wait
function (EnterCriticalSection, WaitForxxxx, etc.) that triggers a
context switch, for a few reasons.  If you're just going to spin and
wait, then you've got a thread doing nothing while other threads could
be working.  If you call Sleep, you give up the rest of your timeslice
and trigger a context switch anyway.  The scheduler can trigger context
switches at any time - it doesn't need to wait for you to call Sleep -
so it's not like you can prevent that, unless you stop using threads and
switch to a polling model.  Finally, if the network thread is using a
wait function on a socket to block until data arrives, it won't even be
considered for scheduling, so that improves your chances of not entering
a race with the main thread. =20

It seems to me that the best approach is use OS locks and minimize the
time locks are held.  Am I missing something here?

--brian

-----Original Message-----
From: Jon Watte [mailto:hp...@mi...]=20
Sent: Thursday, January 03, 2002 4:15 PM
To: Gamedevlists-Windows@Lists. Sourceforge. Net
Subject: RE: [GD-Windows] TryEnterCriticalSection


In my experience, when you find you want to "try to grab a lock if=20
possible," you are most often better off re-designing your algorithm=20
to not use that. More often than not, there's a race waiting to happen=20
that you don't realize if you find you need this.

And, for low-latency applications (like games), I've found that you're=20
much better off using non-blocking primitives than trying to go through=20
context switches -- they add up pretty quickly! A non-blocking* FIFO is=20
quite simple to implement using an atomic add-and-return-old-value=20
function, if you only ever have one reader and one writer, for example.

For your event queue, you could just have a sufficiently large list of=20
events waiting to be inserted implemented as a non-blocking FIFO, and=20
have the "poll for next event" function empty out whatever's there when=20
the function gets entered and put it into the queue.

Cheers,

			/ h+


* Non-blocking primitives force you to decide what to do if the "put"=20
operation fails because there's not enough space, though -- snooze and=20
re-try is often good enough; the idea is that you allocate a sufficient=20
buffer area up-front that you seldom get into that case, and when you=20
do, snoozing is the right thing to do because the other guy's falling=20
behind too much. If you're using a non-reliable mechanism like UDP, you=20
may decide to start dropping packets instead.

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Hook
> Sent: Thursday, January 03, 2002 11:18 AM
> To: gam...@li...
> Subject: [GD-Windows] TryEnterCriticalSection
>=20
>=20
> It looks like TryEnterCriticalSection is only available on >=3D NT4 =
(and
> according to the docs, it's not available on Win9x at all).  To get
> around this I'm thinking that I could switch to using a mutex and
> WaitForSingleObject with a timeout of 0 milliseconds, but mutexes are
> heavier weight than critical sections (I'm not sure how bad this is in
> practice though).
>=20
> Any opinions, comments or shared experiences with this?
>=20
> Brian
>=20
>=20
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
>=20

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

RE: [GD-Windows] TryEnterCriticalSection

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

In my experience, when you find you want to "try to grab a lock if 
possible," you are most often better off re-designing your algorithm 
to not use that. More often than not, there's a race waiting to happen 
that you don't realize if you find you need this.

And, for low-latency applications (like games), I've found that you're 
much better off using non-blocking primitives than trying to go through 
context switches -- they add up pretty quickly! A non-blocking* FIFO is 
quite simple to implement using an atomic add-and-return-old-value 
function, if you only ever have one reader and one writer, for example.

For your event queue, you could just have a sufficiently large list of 
events waiting to be inserted implemented as a non-blocking FIFO, and 
have the "poll for next event" function empty out whatever's there when 
the function gets entered and put it into the queue.

Cheers,

			/ h+


* Non-blocking primitives force you to decide what to do if the "put" 
operation fails because there's not enough space, though -- snooze and 
re-try is often good enough; the idea is that you allocate a sufficient 
buffer area up-front that you seldom get into that case, and when you 
do, snoozing is the right thing to do because the other guy's falling 
behind too much. If you're using a non-reliable mechanism like UDP, you 
may decide to start dropping packets instead.

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Hook
> Sent: Thursday, January 03, 2002 11:18 AM
> To: gam...@li...
> Subject: [GD-Windows] TryEnterCriticalSection
> 
> 
> It looks like TryEnterCriticalSection is only available on >= NT4 (and
> according to the docs, it's not available on Win9x at all).  To get
> around this I'm thinking that I could switch to using a mutex and
> WaitForSingleObject with a timeout of 0 milliseconds, but mutexes are
> heavier weight than critical sections (I'm not sure how bad this is in
> practice though).
> 
> Any opinions, comments or shared experiences with this?
> 
> Brian
> 
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> 

RE: [GD-Windows] TryEnterCriticalSection

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

> I've used mutexes (mutices?) a lot, for instance when walking 
> common data structures like network message queues (receive 
> messages on worker thread, process messages on main thread). 

That's pretty much exactly what I'm going to be using them for.  I need
to have synchronized access to my event queue, which may be written to
by an external network thread.

I don't NEED TryEnterCriticalSection at this point, but I'm trying to
make sure that I leave that option open later.  Right now I have my
HMutex and HCriticalSection class, but the latter can really just be
removed if I switch to mutices exclusively (not pun intended).  Then
again, the HCriticalSection class is all of 30 lines of code, so keeping
it around wouldn't hurt.

> Maybe more details about how many threads you have going, 
> what they're doing, how many different places the critical 
> section is currently being used, etc. would help get answers 
> that are more useful to you.

At this point I'm just trying to get a semblance of a general
synchronization architecture in place that can be used for a bunch of
different things.  The only two concrete areas I have, however, are an
audio thread and a network pump.

The audio thread presumably needs synchronized access to my direct sound
object and buffers, but a hard wait is fine.  Same goes with the network
pump feeding an event queue -- it's not going to hold a lock for a very
long time by any means.

-Brian

RE: [GD-Windows] TryEnterCriticalSection

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

There's also all the Interlocked* functions, like
InterlockedCompareExchange, for those who have a hard time remembering
x86 asm instructions.  And for those, like myself, who never knew the
instructions :). =20

I've used mutexes (mutices?) a lot, for instance when walking common
data structures like network message queues (receive messages on worker
thread, process messages on main thread). My usage has typically been
with 2 threads going.  I've never sensed a problem.  I don't know what
the internal implementation is like, but I would guess that lots of time
has been spent making sync primitives as efficient as possible. =20

If you're worried about the cost of wait objects vs. critical sections,
then I guess one question you could ask yourself is, does the time
required for WaitForSingleObject(0) compare at all to the time that your
thread would just sit there if you just used EnterCritSection instead of
TryEnterCritSection?  How long do the threads typically hold the
critical section?  Is your goal to actually avoid having multiple
threads execute through the guarded section in close temporal sequence,
or are you just worried about having other threads waiting idle while
one thread goes through it?

Maybe more details about how many threads you have going, what they're
doing, how many different places the critical section is currently being
used, etc. would help get answers that are more useful to you.

--brian

-----Original Message-----
From: Andy Glaister [mailto:an...@mi...]=20
Sent: Thursday, January 03, 2002 11:42 AM
To: gam...@li...
Subject: RE: [GD-Windows] TryEnterCriticalSection

There is a good performance comparison of different sync objects found
at=20

http://www.usenix.org/publications/library/proceedings/usenix-nt98/full_
papers/zabatta/zabatta_html/zabatta.html

It depends upon what you are trying to do and how often you will
check/set/block in your code. Personally I would write my own sync
object using _asm lock cmpxchg - then it would run on all CPUs 486 and
above...

There are very neat sync objects in the later OS's - SLIST for example
is very clever, but only in XP and above (of course, you could implement
it yourself without too much trouble) - also spin locks may be useful if
you only lock the resource very briefly.

Andy Glaister.

-----Original Message-----
From: Brian Hook [mailto:bri...@py...]=20
Sent: Thursday, January 03, 2002 11:18 AM
To: gam...@li...
Subject: [GD-Windows] TryEnterCriticalSection


It looks like TryEnterCriticalSection is only available on >=3D NT4 (and
according to the docs, it's not available on Win9x at all).  To get
around this I'm thinking that I could switch to using a mutex and
WaitForSingleObject with a timeout of 0 milliseconds, but mutexes are
heavier weight than critical sections (I'm not sure how bad this is in
practice though).

Any opinions, comments or shared experiences with this?

Brian


_______________________________________________
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] TryEnterCriticalSection

[Andy G. <an...@mi...>]

There is a good performance comparison of different sync objects found
at=20

http://www.usenix.org/publications/library/proceedings/usenix-nt98/full_
papers/zabatta/zabatta_html/zabatta.html

It depends upon what you are trying to do and how often you will
check/set/block in your code. Personally I would write my own sync
object using _asm lock cmpxchg - then it would run on all CPUs 486 and
above...

There are very neat sync objects in the later OS's - SLIST for example
is very clever, but only in XP and above (of course, you could implement
it yourself without too much trouble) - also spin locks may be useful if
you only lock the resource very briefly.

Andy Glaister.

-----Original Message-----
From: Brian Hook [mailto:bri...@py...]=20
Sent: Thursday, January 03, 2002 11:18 AM
To: gam...@li...
Subject: [GD-Windows] TryEnterCriticalSection


It looks like TryEnterCriticalSection is only available on >=3D NT4 (and
according to the docs, it's not available on Win9x at all).  To get
around this I'm thinking that I could switch to using a mutex and
WaitForSingleObject with a timeout of 0 milliseconds, but mutexes are
heavier weight than critical sections (I'm not sure how bad this is in
practice though).

Any opinions, comments or shared experiences with this?

Brian


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

[GD-Windows] TryEnterCriticalSection

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

It looks like TryEnterCriticalSection is only available on >= NT4 (and
according to the docs, it's not available on Win9x at all).  To get
around this I'm thinking that I could switch to using a mutex and
WaitForSingleObject with a timeout of 0 milliseconds, but mutexes are
heavier weight than critical sections (I'm not sure how bad this is in
practice though).

Any opinions, comments or shared experiences with this?

Brian

RE: [GD-Windows] Restoring a minimized window

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

And, as always, the bug is discovered 30 seconds after sending out the
e-mail.  =)  Apparently it had something to do with Set/ReleaseCapture()
not allowing it to restore...or something.  So basically I don't call
Set/ReleaseCapture() when the window is minimized and the problem seems
to have gone away.

Brian


> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Brian Hook
> Sent: Thursday, December 27, 2001 6:25 PM
> To: gam...@li...
> Subject: [GD-Windows] Restoring a minimized window
> 
> 
> I'm a wee bit befuddled by this terribly simple problem: how 
> do I get a window to restore when it's been clicked on in the 
> minimize tray?  I'm not doing any particularly peculiar, yet 
> my window firmly stays minimized once minimized...is there 
> another message I should be handling (or not handling)?
> 
> If I alt-tab or right-click Restore, it comes back just fine. 
>  But clicking doesn't seem to do it.  All the WM_xxxx 
> messages that I intercept are being passed on to the DefWindowProc().
> 
> Brian
> 
> 
> _______________________________________________
> Gamedevlists-windows mailing list 
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> 

[GD-Windows] Restoring a minimized window

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

I'm a wee bit befuddled by this terribly simple problem: how do I get a
window to restore when it's been clicked on in the minimize tray?  I'm
not doing any particularly peculiar, yet my window firmly stays
minimized once minimized...is there another message I should be handling
(or not handling)?

If I alt-tab or right-click Restore, it comes back just fine.  But
clicking doesn't seem to do it.  All the WM_xxxx messages that I
intercept are being passed on to the DefWindowProc().

Brian

[GD-Windows] SM_SLOWMACHINE

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

Just out of pure curiosity, what the hell is that function exactly doing to
tell between a slow and a not-slow machine ?

BOOL Res = GetSystemMetrics(SM_SLOWMACHINE);

I find that one rather amusing :)

P.

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

[Andrew G. <And...@ho...>]

There's another important thing in this area to remember as well. Depending
on their permissions users might not have write permissions to the directory
the game is stored in. It's now recommended that you ensure persistantdata
is stored in folders that users have guaranteed access to, and use
SHGetFolderPath to retrieve this path with the correct identifier. In the
case of application data it would be CSIDL_COMMON_APPDATA, or for user
specific settings you would use CSIDL_APPDATA.

This is going to become a real issue now that XP is around and allows people
to restrict access like this. We've already had one bug report from a
previous project because our game relied on write access to it's install
folder, and little Johhny's dad had locked him off from modifying the
Program Files subtree.

There was an excellent presentation from Mike Burrows at Meltdown this year
about how to write well behaved Windows apps taking these and other aspects
into account. It's now online and well worth a read.

<http://www.microsoft.com/mscorp/corpevents/meltdown2001/ppt/GamingWinXP.ppt
>


Andrew Grant
Hothouse Creations 



> -----Original Message-----
> From: Brian Hook [mailto:bri...@py...]
> Sent: 20 December 2001 20:40
> To: gam...@li...
> Subject: RE: [GD-Windows] Security/access when writing to registry

> .
> 
> Future versions will, of course, use HKEY_CURRENT_USER.
> 
> Brian
> 
> 
> 


This email is covered by the following disclaimer, please read before
accepting this email. http://www.hothouse.org/disclaimer/

RE: [GD-Windows] RE: [GD-General] Eiffel

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

Ignore last post, sorry about that (wrong list).

[GD-Windows] RE: [GD-General] Eiffel

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

> Hey Brian you're selling this pretty well. I'm about ready to 
> go out and buy a Mac. :) Seriously though if you're this 
> excited about something, and it's got Apple's full weight 
> behind it, I'd like to check it out, if for no other reason 
> than to have something to copy in my own designs.

Go check out developer.apple.com for all the blurbs and background
information on Cocoa and Obj-C.  Pick up a book like "Learning Cocoa" or
something similar.  The book "Object Oriented Programming and the
Objective-C Language" is a good place too, and I think it's in PDF form
on their Web site.

I'll warn you now though, you won't be able to copy much of the designs
because much of Cocoa's power comes from the way IB, Cocoa and Obj-C
interact, and Obj-C is just a radically different way of thinking than
C++ (dynamic typing with optional static type checking).

> How did you get into Cocoa/Obj-C and what tools do you need
> for it?

I've been a NextStep fan boy for ages, but Cocoa was the first time I
got to really use it.  By the time I had the means and time to use NS,
OpenStep was out and not very stable or fast on NT.

Since our games are going to be running no a Mac, I had to buy a
PowerMac anyway.  Just for grins I loaded up PB and tried to write a
little OpenGL visualization tool.  With NO prior Cocoa/Obj-C programming
experience, I got a fractal terrain generator visualization tool, with
UI, working in about 6 hours.  If I had to do it again, more like 45
minutes.

I haven't had much time to mess with it anymore, but I plan on getting
back into it on our later projects that will require tools.

> to give any specifics? Or should I simply go to the Apple dev 
> site and read some glossies? :)

Here's the best part -- the dev tools are FREE.  ProjectBuilder, the
compiler (gcc), Interface Builder, libs, everything are freely
downloadable (and come with the OS X retail CDs, although not with OS X
on pre-installed machines).

It's a Better Way of Doing Things.  Unfortunately, it's limited to OS X.

Brian

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

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

Thanks for the help everyone.  Yes, I was writing into
HKEY_LOCAL_MACHINE instead of HKEY_CURRENT_USER.  Unfortunately, since
the game is already out and it stores config/high scores information
there, I need to either write an import facility or just continue to use
HKLM when possible.  The latter is easier, since 99.999% of our
particular users aren't going to have this problem.

So now I'm doing:

if ( RegCreateKeyEx( HKEY_LOCAL_MACHINE, ... ) != ERROR_SUCCESS )
   if ( RegCreateKeyEx( HKEY_CURRENT_USER, ... ) 
.
.
.

Future versions will, of course, use 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 S. <bs...@mi...>]

I'm certainly not a NT security expert, but in this particular instance
you only have access to HKLM if you have admin privileges (since you can
essentially screw up the whole machine from there).  Similarly, I don't
think non-admins can install DLLs to the system directory.  It's
probably more correct to say that admin privileges imply the ability to
write to HKLM, and non-admins might have that particular privilege
enabled, but that's way too much detail.  The important point is that
HKCU should always be accessible. =20

I don't have any links to point you to, but I'm sure you could search
MSDN or Google for something like "porting from 95 to Win2k" to get a
list of other gotchas.

--brian

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

> 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


_______________________________________________
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

[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

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

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

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