gamedevlists-general — List for discussing general game development issues

Re: [GD-General] Is it possible to detect debugging?

[Colin F. <cp...@ea...>]

I am convinced that a binary executable will never know how 
it is being executed.

>>> That won't stop me from running windbg in non-invasive mode and
>>> capturing a memory dump, then inspecting that.

I heard of "WinDbg" before (and, no, I don't mean that I heard about it
from the previous post!  Hee, hee!), but I've never used it.  What 
do you mean by capturing and inspecting a memory dump?  Are you simply
referring to looking at a snapshot of all allocated memory buffers?

The only application hacking I ever did was on the Commodore 64,
when I loaded an application, and then simply dumped a memory image
of RAM to a file on disk.  Thus, restoring the file to memory 
would bring the application back to life, in the exact state of
its execution.  I guess it is like bringing a laptop out of 
hibernation, or using VMWare (or whatever the product is called),
to restore various computer states.

So, one crude application cracking method would be to store 
both the executable and stored memory buffers and somehow restore
both in to a process.  I'm sure it's easy to protect against
this kind of crack!

Is the benefit of checking memory that you can look at run-time
data structures, like finding where the player's "gold pieces"
or "health" value is stored?  Or scanning for strings, 3D models,
textures, network buffers, etc?

As I mentioned earlier, I am just making conversation.  If I
was talking about hacking prevention, I would say that various 
components to a complete solution involve: (1) Making every 
binary very unique (custom-built per user per download from the
Internet); (2) Subscription model, or at least the requirement
of calling home on start-up; (3) Making the application algorithm
complicated, so even a total understanding of actions at the 
assembly level don't give any hint about the high-level actions
in the program.  I think all three pieces are necessary to make
the hacker's effort a nightmare that ends in depressing failure.
I read in a recently published book the claim that even the elite
hackers, despite their expertise in the low level operations of
computers, often cannot comprehend intermediate algorithms in
computer science.  But I think the only way that fact could be put
to good use in anti-cracking efforts would be to make the entire
application an intermediate level computer science algorithm!
Otherwise, the cracker just bypasses the crazy code and 
replaces it with a functional "equivalent" -- like just saying,
"yes" to the question of whether or not the product key is 
valid!

By the way: I hate the idea of turning all products in to 
rentals!  That just sucks.  Unless it's a true *service*,
with ongoing value added, then a "leasing" model is just 
greedy exploitation of the market.  I swear I don't mean to
rant or bash any company in particular, but I am generally 
afraid of the exploitation that occurs when companies succeed
in taking full control of distribution (cell phone carriers)
or the target platform (consoles or the upcoming CPU/OS 
combination that renders a PC in to a console).  I make
these comments just to make sure it's clear that there's a
difference between protecting a product and exploiting one's
control over a channel.

--- Colin

RE: [GD-General] Is it possible to detect debugging?

[Mat N. \(BUNGIE\) <mat...@mi...>]

That won't stop me from running windbg in non-invasive mode and
capturing a memory dump, then inspecting that.

I've done it before. It's not that hard at all.

MSN

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Aaron Drew
Sent: Thursday, October 09, 2003 5:09 PM
To: gam...@li...
Subject: Re: [GD-General] Is it possible to detect debugging?

I don't remember too much about it but I do recall reading a while back
an=20
ezine (phrack or similar) describing how to avoid debuggers (well, I
think it=20
was actuall on how to stop crackers). They listed a few techniques such
as:

- Modifying your code during execution to confuse any debugger and/or
third=20
party.
	- Kind of like the way executable packers work.
	- Small assembly language segments like "mov ax, 0x9090; jmp
0xfe" that
	  do nothing important but then jump back into their data and
execute it.
- Checking for an int 3 handler (the one that gets called at
breakpoints) or=20
replacing the int 3 handler with your own (with extreme care).

I'm sure there were more but I forget them.

- Aaroin

On Fri, 10 Oct 2003 08:34 am, Colin Fahey wrote:
> [1] IsDebuggerPresent()
>
> [2] [...] WinDBG and kd can attach in noninvasive mode and generate a
full
>     minidump [...]
>
> As I suspected: Developers can check for obvious debugging (e.g., to
handle
> errors differently), but circumventing the check requires a very
modest
> effort (e.g., intercept IsDebuggerPresent() call, or use noninvasive
> debuggers). Also, I suppose one could run the whole application within
the
> context of an 80x86 emulator, so that it isn't running on the CPU as
native
> instructions, in which case the state of the code is totally exposed
and
> there is no way in the world the app could possibly detect that it was
> running in virtual reality!  (Much as we can't tell that we're living
in
> the Matrix -- without pills, I mean.)
>
> --- Colin
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557

--=20
- Aaron

"Today's mighty oak is just yesterday's nut that held its ground."



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D557

Re: [GD-General] Is it possible to detect debugging?

[Aaron D. <ri...@in...>]

I don't remember too much about it but I do recall reading a while back an 
ezine (phrack or similar) describing how to avoid debuggers (well, I think it 
was actuall on how to stop crackers). They listed a few techniques such as:

- Modifying your code during execution to confuse any debugger and/or third 
party.
	- Kind of like the way executable packers work.
	- Small assembly language segments like "mov ax, 0x9090; jmp 0xfe" that
	  do nothing important but then jump back into their data and execute it.
- Checking for an int 3 handler (the one that gets called at breakpoints) or 
replacing the int 3 handler with your own (with extreme care).

I'm sure there were more but I forget them.

- Aaroin

On Fri, 10 Oct 2003 08:34 am, Colin Fahey wrote:
> [1] IsDebuggerPresent()
>
> [2] [...] WinDBG and kd can attach in noninvasive mode and generate a full
>     minidump [...]
>
> As I suspected: Developers can check for obvious debugging (e.g., to handle
> errors differently), but circumventing the check requires a very modest
> effort (e.g., intercept IsDebuggerPresent() call, or use noninvasive
> debuggers). Also, I suppose one could run the whole application within the
> context of an 80x86 emulator, so that it isn't running on the CPU as native
> instructions, in which case the state of the code is totally exposed and
> there is no way in the world the app could possibly detect that it was
> running in virtual reality!  (Much as we can't tell that we're living in
> the Matrix -- without pills, I mean.)
>
> --- Colin
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557

-- 
- Aaron

"Today's mighty oak is just yesterday's nut that held its ground."

Re: [GD-General] Is it possible to detect debugging?

[Colin F. <cp...@ea...>]

[1] IsDebuggerPresent()

[2] [...] WinDBG and kd can attach in noninvasive mode and generate a full
    minidump [...]

As I suspected: Developers can check for obvious debugging (e.g., to handle
errors differently), but circumventing the check requires a very modest effort
(e.g., intercept IsDebuggerPresent() call, or use noninvasive debuggers).  
Also, I suppose one could run the whole application within the context of an
80x86 emulator, so that it isn't running on the CPU as native instructions, 
in which case the state of the code is totally exposed and there is no way
in the world the app could possibly detect that it was running in virtual
reality!  (Much as we can't tell that we're living in the Matrix -- 
without pills, I mean.)

--- Colin

RE: [GD-General] Is it possible to detect debugging?

[Mat N. \(BUNGIE\) <mat...@mi...>]

No. WinDBG and kd can attach in noninvasive mode and generate a full
minidump, even if the process has attached to itself as a debugger.

MSN

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Colin Fahey
Sent: Thursday, October 09, 2003 9:59 AM
To: gam...@li...
Subject: [GD-General] Is it possible to detect debugging?


Can a Windows application determine if it is being debugged?
Naturally it can't do anything if it has been suspended at a breakpoint,

but I'm wondering if there is a way, during execution, to check for
debugging.

Sorry, it has been a while since I was in to Windows process information
stuff, so I forget all the cool things a process can do.

Anyhow, let's say the application is started.  Meanwhile, something like
Visual C++ has already been started, or is now started.  Some time=20
during the execution of the application, the user of Visual C++ uses=20
the "Attach to Process..." option, and selects the application.
Is there any way for the application to detect that it is being
debugged,
assuming it has not been immediately paused?

The method cannot depend on any particular debugger (like checking for=20
certain states of, say, Visual Studio).  But I assume that many
debuggers
work the same way -- although the 1337 haX0r might run the whole app in=20
an 80x86 emulator...

I don't really have any particular objective, like popping up a dialog
to embarrass the first haX0r who attempts to crack my application.
I'm just making conversation.  Relax!  Talk amongst yourselves!

--- Colin

cp...@ea...




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D557

RE: [GD-General] Is it possible to detect debugging?

[Daniel V. <vo...@ep...>]

> I'm guessing that you're going through these hoops because 
> IsDebuggerPresent isn't available in Win95?  

Yes.

> Surely this can't really prevent Someone Evil from having 
> their way with your app.

It isn't mean to :) We only detect the presence of a debugger to determine
whether to use use ::DebugBreak on error instead of bringing up an error
crash dialog box.
 
-- Daniel, Epic Games Inc.

Re: [GD-General] Is it possible to detect debugging?

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

I'm guessing that you're going through these hoops because 
IsDebuggerPresent isn't available in Win95?  Surely this can't really 
prevent Someone Evil from having their way with your app.

*Seems to me I could easily use 
http://research.microsoft.com/sn/detours/ to hook your call to 
GetProcAddress.

--brian
*
Daniel Vogel wrote:

>UBOOL appIsDebuggerPresent()
>{
>	UBOOL Result = 0;
>	OSVERSIONINFO WinVersion;
>
>	HINSTANCE KernLib =  LoadLibraryEx( TEXT("kernel32.dll"), NULL, 0);
>	if( KernLib )
>	{
>		FARPROC lIsDebuggerPresent = GetProcAddress( KernLib,
>"IsDebuggerPresent" );
>		if( lIsDebuggerPresent && lIsDebuggerPresent() )
>			Result = 1;
>
>		FreeLibrary( KernLib );
>	}
>	return Result;
>}
>
>-- Daniel, Epic Games Inc. 
>  
>

RE: [GD-General] Is it possible to detect debugging?

[Daniel V. <vo...@ep...>]

UBOOL appIsDebuggerPresent()
{
	UBOOL Result = 0;
	OSVERSIONINFO WinVersion;

	HINSTANCE KernLib =  LoadLibraryEx( TEXT("kernel32.dll"), NULL, 0);
	if( KernLib )
	{
		FARPROC lIsDebuggerPresent = GetProcAddress( KernLib,
"IsDebuggerPresent" );
		if( lIsDebuggerPresent && lIsDebuggerPresent() )
			Result = 1;

		FreeLibrary( KernLib );
	}
	return Result;
}

-- Daniel, Epic Games Inc. 

> -----Original Message-----
> From: gam...@li... 
> [mailto:gam...@li...] On 
> Behalf Of Colin Fahey
> Sent: Thursday, October 09, 2003 12:59 PM
> To: gam...@li...
> Subject: [GD-General] Is it possible to detect debugging?
> 
> 
> 
> Can a Windows application determine if it is being debugged?
> Naturally it can't do anything if it has been suspended at a 
> breakpoint, 
> but I'm wondering if there is a way, during execution, to 
> check for debugging.
> 
> Sorry, it has been a while since I was in to Windows process 
> information
> stuff, so I forget all the cool things a process can do.
> 
> Anyhow, let's say the application is started.  Meanwhile, 
> something like
> Visual C++ has already been started, or is now started.  Some time 
> during the execution of the application, the user of Visual C++ uses 
> the "Attach to Process..." option, and selects the application.
> Is there any way for the application to detect that it is 
> being debugged,
> assuming it has not been immediately paused?
> 
> The method cannot depend on any particular debugger (like 
> checking for 
> certain states of, say, Visual Studio).  But I assume that 
> many debuggers
> work the same way -- although the 1337 haX0r might run the 
> whole app in 
> an 80x86 emulator...
> 
> I don't really have any particular objective, like popping up a dialog
> to embarrass the first haX0r who attempts to crack my application.
> I'm just making conversation.  Relax!  Talk amongst yourselves!
> 
> --- Colin
> 
> cp...@ea...
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> SourceForge.net hosts over 70,000 Open Source Projects.
> See the people who have HELPED US provide better services:
> Click here: http://sourceforge.net/supporters.php
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

Re: [GD-General] Is it possible to detect debugging?

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

You could call IsDebuggerPresent().  Of course they can easily detour 
your calls to that function so it's really only useful for you - for 
instance, if you're trying to figure out whether to display your fancy 
assert box or drop straight into the debugger.

Ultimately, if the person running the debugger didn't want you to know 
you were being debugged, I don't think you could tell.  You could try to 
play games, like tracking frame times to guess if you'd been sitting at 
a breakpoint, but that wouldn't stop anyone serious.

--brian

Colin Fahey wrote:

>Can a Windows application determine if it is being debugged?
>Naturally it can't do anything if it has been suspended at a breakpoint, 
>but I'm wondering if there is a way, during execution, to check for debugging.
>
>Sorry, it has been a while since I was in to Windows process information
>stuff, so I forget all the cool things a process can do.
>
>Anyhow, let's say the application is started.  Meanwhile, something like
>Visual C++ has already been started, or is now started.  Some time 
>during the execution of the application, the user of Visual C++ uses 
>the "Attach to Process..." option, and selects the application.
>Is there any way for the application to detect that it is being debugged,
>assuming it has not been immediately paused?
>
>The method cannot depend on any particular debugger (like checking for 
>certain states of, say, Visual Studio).  But I assume that many debuggers
>work the same way -- although the 1337 haX0r might run the whole app in 
>an 80x86 emulator...
>
>I don't really have any particular objective, like popping up a dialog
>to embarrass the first haX0r who attempts to crack my application.
>I'm just making conversation.  Relax!  Talk amongst yourselves!
>
>--- Colin
>
>cp...@ea...
>  
>

[GD-General] Is it possible to detect debugging?

[Colin F. <cp...@ea...>]

Can a Windows application determine if it is being debugged?
Naturally it can't do anything if it has been suspended at a breakpoint, 
but I'm wondering if there is a way, during execution, to check for debugging.

Sorry, it has been a while since I was in to Windows process information
stuff, so I forget all the cool things a process can do.

Anyhow, let's say the application is started.  Meanwhile, something like
Visual C++ has already been started, or is now started.  Some time 
during the execution of the application, the user of Visual C++ uses 
the "Attach to Process..." option, and selects the application.
Is there any way for the application to detect that it is being debugged,
assuming it has not been immediately paused?

The method cannot depend on any particular debugger (like checking for 
certain states of, say, Visual Studio).  But I assume that many debuggers
work the same way -- although the 1337 haX0r might run the whole app in 
an 80x86 emulator...

I don't really have any particular objective, like popping up a dialog
to embarrass the first haX0r who attempts to crack my application.
I'm just making conversation.  Relax!  Talk amongst yourselves!

--- Colin

cp...@ea...

RE: [GD-General] Bink

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

WMV version 8

> -----Original Message-----
> From: Matt Newport [mailto:mat...@ni...]
> Sent: 03 September 2003 17:16
> To: gam...@li...
> Subject: RE: [GD-General] Bink
> 
> 
> Out of curiosity, what were you using before?
> 
> Matt Newport.
> 
> > -----Original Message-----
> > From: Gareth Lewin [mailto:GL...@cl...] 
> > Sent: 03 September 2003 16:46
> > To: gam...@li...
> > Subject: [GD-General] Bink
> > 
> > 
> > I know there are some RADTools people here.
> > 
> > I just put Bink into Sudeki. Man your codec is excellent. 
> > Hat's off to you guys, our FMVs look (to quote an artist) 
> > "29million times better".
> > 
> > ________________________
> > Regards, Gareth Lewin
> > Programmer, Sudeki
> > http://www.xbox.com/Sudeki
> 
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.512 / Virus Database: 309 - Release Date: 19/08/2003
>  
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7
> 

RE: [GD-General] Bink

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

Out of curiosity, what were you using before?

Matt Newport.

> -----Original Message-----
> From: Gareth Lewin [mailto:GL...@cl...]=20
> Sent: 03 September 2003 16:46
> To: gam...@li...
> Subject: [GD-General] Bink
>=20
>=20
> I know there are some RADTools people here.
>=20
> I just put Bink into Sudeki. Man your codec is excellent.=20
> Hat's off to you guys, our FMVs look (to quote an artist)=20
> "29million times better".
>=20
> ________________________
> Regards, Gareth Lewin
> Programmer, Sudeki
> http://www.xbox.com/Sudeki

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.512 / Virus Database: 309 - Release Date: 19/08/2003
=20

[GD-General] Bink

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

I know there are some RADTools people here.

I just put Bink into Sudeki. Man your codec is excellent. Hat's off to you
guys, our FMVs look (to quote an artist) "29million times better".

________________________
Regards, Gareth Lewin
Programmer, Sudeki
http://www.xbox.com/Sudeki

Re: [GD-General] Multifile atomic updates

[Colin F. <cp...@ea...>]

I suggest the following:

MAKE YOUR "MAIN" APP A "LAUNCHER", not the 
actual application.

For example, have a root directory for your
application:

  c:\app

Such that you have your friendly app icon
and name in there:

  c:\app\happy.exe

This is the only binary in the directory, and this
executable is the one specified by any shortcuts
on the desktop and the "Start menu".

But this app is just a simple Win32 app that is
just WinMain() with a call to CreateProcess()
or system() and some extra logic.

Okay, your real application, with associated DLLs,
etc, is in a sub-directory:

  c:\app\ver2003aug

Like the following:

  c:\app\ver2003aug\happyv2003aug.exe
  c:\app\ver2003aug\happyv2003aug.dll
  c:\app\ver2003aug\ijl_v2003aug.dll
  c:\app\ver2003aug\manifest_v2003aug.bin

If you patch your application, you basically do 
whatever reckless procedure suits you, resulting
in a totally new version directory:

  c:\app\ver2004jan

Like the following:

  c:\app\ver2004jan\happyv2004jan.exe
  c:\app\ver2004jan\happyv2004jan.dll
  c:\app\ver2004jan\ijl_v2004jan.dll
  c:\app\ver2003aug\manifest_v2004jan.bin

Okay, anything bad can happen during initial
installation or patching!  If the initial installation
TOTALLY fails, the launcher app won't even be available.
If the tiny launcher app was installed, but nothing
else, this won't lead to any craziness.  And any 
additional success / corruption during the copying
or patching of files, on a continuum, will never be
 a problem.

The launcher searches all sub-directories for
manifest_*.bin files.  Any such file that is not
internally consistent (i.e., matches its own stated
hash code within the file) is rejected.  Thus,
we have a list of candidate application versions.
We can sort from newest to oldest.  We consider 
the newest manifest first.

We look at the list of all files mentioned in 
the manifest, and we verify the existence of
each file and the recorded hash code.  If all
files exist AND match all recorded hash codes,
then we execute the main application as a new
process.  The end!

The updater always creates new subdirectories,
and the main application NEVER changes.  There
are no "state" files recording the progress of
updates or installations or "latest version",
etc.  The launcher actively decides which version
among the completely correct versions is the
latest.

The beauty of this scheme, depending on how 
difficult it is to hack your manifest_*.bin 
file format, is that you get some protection
against cracks or random corruption.  Also, 
you will be 100% sure of all file versions!
All files will be consistent, otherwise you
will not run.

Furthermore, the launcher app can report 
corruption, or even do updates itself, and
make the user aware of available versions.
Perhaps it would be useful for the user to
have the ability to select versions, for
testing, etc.

You can give the user the option of removing
old versions.  But the great thing is that 
you can always insure that at least one 
working version exists (assuming the initial
install was successful).  You will never 
execute a corrupt version (of the EXE, 
associated DLLS, or even data if you choose
to verify the data, too).  Disk space may
be an issue, especially when patching huge 
files, but I think giving the user the
option of removing old versions (after both
old and new versions have been fully verified)
will conserve disk space to any desired level.

Well, this scheme seems so simple and appealing
that I'm sure it is very common!  (I can't 
possibly have an original idea...)

--- Colin

cp...@ea...

Re: [GD-General] Multifile atomic updates

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

> what you mean by the brute force mechanism

The old "setting a flag before patch, clearing it after verification" 
thing that was mentioned.  You get a bit of a recursive problem if you 
try to back out to the older versions and then find that you failed 
doing THAT, etc.

But setting checkpoint flags probably works well enough I guess.  
Bleh.

-Hook

Re: [GD-General] Multifile atomic updates

[Mike W. <mi...@ge...>]

nm, just realized i'm subscribed twice...can't figure out what my 
'other' email address i'm subscribed with is...hmm...

Mike Wuetherick wrote:

> doh, sorry bout the double post
> my bad
> mike
>
> Mike Wuetherick wrote:
>
>> i'd think that you'd have your updater application set an ini or 
>> registry entry indicating 'startedupdate=1' or something and then 
>> have some kind of launcher application that does checks of the 
>> application, reads this setting on every launch, if the 
>> 'startedupdate' is set, but not 'finishedupdate', then prompt the 
>> user to finish the update they started, which could check at what 
>> state the update is in, if the files have been downloaded locally 
>> already, the user doesn't have to do that step, you can md5 the files 
>> to make sure they are valid before applying the changes (taking into 
>> account terminated downloads) and download any 'broken' files as 
>> necessary...
>>
>> or use VISE AutoUpdate that does all this fun stuff for you ;]
>>
>> mike w
>> www.gekidodesigns.com
>>
>>
>> Brian Hook wrote:
>>
>>> Say you have a patch installer that needs to update the following 
>>> files:
>>>
>>> GAME.EXE
>>> GAME.DLL
>>> NETAPI.DLL
>>>
>>> The typical way would be to download the patch, apply it to 
>>> temporary files, then copy over the files upon completion.
>>>
>>> PATCH GAME.EXE NEWGAME.EXE
>>> PATCH GAME.DLL NEWGAME.DLL
>>> PATCH NETAPI.DLL NEWNETAPI.DLL
>>>
>>> //Assume UPDATE renames existing to .EXT.OLD
>>> //and copies NEW*.EXT to *.EXT
>>> UPDATE GAME.EXE
>>> UPDATE GAME.DLL
>>> UPDATE NETAPI.DLL
>>>
>>> Obviously nothing destructive happens until after the patches are 
>>> applied and you can verify that everything is okay.  But what do you 
>>> do if something bad happens during the destructive update portion, 
>>> e.g. lost connection to remote disk or power outage or system crash, 
>>> etc. during the update?
>>>
>>> The brute force mechanism seems a little, well, brute force, I was 
>>> wondering if there's something more elegant I could do.
>>>
>>> Brian
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>>> Data Reports, E-commerce, Portals, and Forums are available now.
>>> Download today and enter to win an XBOX or Visual Studio .NET.
>>> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 
>>>
>>> _______________________________________________
>>> Gamedevlists-general mailing list
>>> Gam...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>>> Archives:
>>> http://sourceforge.net/mailarchive/forum.php?forum_idU7
>>>
>>>
>>>  
>>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>> Data Reports, E-commerce, Portals, and Forums are available now.
>> Download today and enter to win an XBOX or Visual Studio .NET.
>> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 
>>
>> _______________________________________________
>> Gamedevlists-general mailing list
>> Gam...@li...
>> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>> Archives:
>> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>>
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>
>

Re: [GD-General] Multifile atomic updates

[Mike W. <mi...@ge...>]

doh, sorry bout the double post
my bad
mike

Mike Wuetherick wrote:

> i'd think that you'd have your updater application set an ini or 
> registry entry indicating 'startedupdate=1' or something and then have 
> some kind of launcher application that does checks of the application, 
> reads this setting on every launch, if the 'startedupdate' is set, but 
> not 'finishedupdate', then prompt the user to finish the update they 
> started, which could check at what state the update is in, if the 
> files have been downloaded locally already, the user doesn't have to 
> do that step, you can md5 the files to make sure they are valid before 
> applying the changes (taking into account terminated downloads) and 
> download any 'broken' files as necessary...
>
> or use VISE AutoUpdate that does all this fun stuff for you ;]
>
> mike w
> www.gekidodesigns.com
>
>
> Brian Hook wrote:
>
>> Say you have a patch installer that needs to update the following files:
>>
>> GAME.EXE
>> GAME.DLL
>> NETAPI.DLL
>>
>> The typical way would be to download the patch, apply it to temporary 
>> files, then copy over the files upon completion.
>>
>> PATCH GAME.EXE NEWGAME.EXE
>> PATCH GAME.DLL NEWGAME.DLL
>> PATCH NETAPI.DLL NEWNETAPI.DLL
>>
>> //Assume UPDATE renames existing to .EXT.OLD
>> //and copies NEW*.EXT to *.EXT
>> UPDATE GAME.EXE
>> UPDATE GAME.DLL
>> UPDATE NETAPI.DLL
>>
>> Obviously nothing destructive happens until after the patches are 
>> applied and you can verify that everything is okay.  But what do you 
>> do if something bad happens during the destructive update portion, 
>> e.g. lost connection to remote disk or power outage or system crash, 
>> etc. during the update?
>>
>> The brute force mechanism seems a little, well, brute force, I was 
>> wondering if there's something more elegant I could do.
>>
>> Brian
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>> Data Reports, E-commerce, Portals, and Forums are available now.
>> Download today and enter to win an XBOX or Visual Studio .NET.
>> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 
>>
>> _______________________________________________
>> Gamedevlists-general mailing list
>> Gam...@li...
>> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>> Archives:
>> http://sourceforge.net/mailarchive/forum.php?forum_idU7
>>
>>
>>  
>>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>
>

Re: [GD-General] Multifile atomic updates

[Mike W. <mi...@ge...>]

i'd think that you'd have your updater application set an ini or 
registry entry indicating 'startedupdate=1' or something and then have 
some kind of launcher application that does checks of the application, 
reads this setting on every launch, if the 'startedupdate' is set, but 
not 'finishedupdate', then prompt the user to finish the update they 
started, which could check at what state the update is in, if the files 
have been downloaded locally already, the user doesn't have to do that 
step, you can md5 the files to make sure they are valid before applying 
the changes (taking into account terminated downloads) and download any 
'broken' files as necessary...

or use VISE AutoUpdate that does all this fun stuff for you ;]

mike w
www.gekidodesigns.com


Brian Hook wrote:

>Say you have a patch installer that needs to update the following 
>files:
>
>GAME.EXE
>GAME.DLL
>NETAPI.DLL
>
>The typical way would be to download the patch, apply it to temporary 
>files, then copy over the files upon completion.
>
>PATCH GAME.EXE NEWGAME.EXE
>PATCH GAME.DLL NEWGAME.DLL
>PATCH NETAPI.DLL NEWNETAPI.DLL
>
>//Assume UPDATE renames existing to .EXT.OLD
>//and copies NEW*.EXT to *.EXT
>UPDATE GAME.EXE
>UPDATE GAME.DLL
>UPDATE NETAPI.DLL
>
>Obviously nothing destructive happens until after the patches are 
>applied and you can verify that everything is okay.  But what do you 
>do if something bad happens during the destructive update portion, 
>e.g. lost connection to remote disk or power outage or system crash, 
>etc. during the update?
>
>The brute force mechanism seems a little, well, brute force, I was 
>wondering if there's something more elegant I could do.
>
>Brian
>
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>Data Reports, E-commerce, Portals, and Forums are available now.
>Download today and enter to win an XBOX or Visual Studio .NET.
>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>_______________________________________________
>Gamedevlists-general mailing list
>Gam...@li...
>https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>Archives:
>http://sourceforge.net/mailarchive/forum.php?forum_idU7
>
>
>  
>

Re: [GD-General] Multifile atomic updates

[Jason M. <jma...@li...>]

You would probably want to have a way to recognize that something bad
happened that stopped the update from completing.  I'm not sure what you
mean by the brute force mechanism, but the first thing that comes to my mind
is to create a temporary file, say "patching.txt", that would be created
before the patch begins and deleted when it is finished.  The game and/or
patch installer could check for the existence of this file when it starts
up, and if it's there you would know something funky happened while updating
and the update needs to be redone (or better yet continued from where it got
interrupted).

-Jason

----- Original Message -----
From: "Brian Hook" <bri...@py...>
To: <gam...@li...>
Sent: Friday, August 15, 2003 9:32 PM
Subject: [GD-General] Multifile atomic updates


Say you have a patch installer that needs to update the following
files:

GAME.EXE
GAME.DLL
NETAPI.DLL

The typical way would be to download the patch, apply it to temporary
files, then copy over the files upon completion.

PATCH GAME.EXE NEWGAME.EXE
PATCH GAME.DLL NEWGAME.DLL
PATCH NETAPI.DLL NEWNETAPI.DLL

//Assume UPDATE renames existing to .EXT.OLD
//and copies NEW*.EXT to *.EXT
UPDATE GAME.EXE
UPDATE GAME.DLL
UPDATE NETAPI.DLL

Obviously nothing destructive happens until after the patches are
applied and you can verify that everything is okay.  But what do you
do if something bad happens during the destructive update portion,
e.g. lost connection to remote disk or power outage or system crash,
etc. during the update?

The brute force mechanism seems a little, well, brute force, I was
wondering if there's something more elegant I could do.

Brian




-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7

[GD-General] Multifile atomic updates

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

Say you have a patch installer that needs to update the following 
files:

GAME.EXE
GAME.DLL
NETAPI.DLL

The typical way would be to download the patch, apply it to temporary 
files, then copy over the files upon completion.

PATCH GAME.EXE NEWGAME.EXE
PATCH GAME.DLL NEWGAME.DLL
PATCH NETAPI.DLL NEWNETAPI.DLL

//Assume UPDATE renames existing to .EXT.OLD
//and copies NEW*.EXT to *.EXT
UPDATE GAME.EXE
UPDATE GAME.DLL
UPDATE NETAPI.DLL

Obviously nothing destructive happens until after the patches are 
applied and you can verify that everything is okay.  But what do you 
do if something bad happens during the destructive update portion, 
e.g. lost connection to remote disk or power outage or system crash, 
etc. during the update?

The brute force mechanism seems a little, well, brute force, I was 
wondering if there's something more elegant I could do.

Brian

RE: [GD-General] runtime error logging

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

The reason is lost in the mists of time, but I think it was so you could do
obscure things like:

if ( type == TYPEA )
{
	ERROR ( "Error in thingie of type 'A'" );
}
else if ( type == TYPEB )
{
	ERROR ( "Error in thingie of type 'B'" );
}

...though actually you could have changed those to:

ERROR ( "Error in thingie of type %s", "A" );
ERROR ( "Error in thingie of type %s", "B" );


Oh, there probably was a good reason for it, many years ago :-)



Tom Forsyth - Muckyfoot bloke and Microsoft MVP.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.

> -----Original Message-----
> From: Gareth Lewin [mailto:GL...@cl...]
> Sent: 16 July 2003 07:46
> To: gam...@li...
> Subject: RE: [GD-General] runtime error logging
> 
> 
> Silly questoin, but couldn't you hash the string before the 
> params were
> evaluated ? So you would just hash "Unknown effect '%s' in 
> mesh '%s'\n" 
> 
> > -----Original Message-----
> > From: Tom Forsyth [mailto:to...@mu...]
> > Sent: 14 July 2003 17:03
> > To: gam...@li...
> > Subject: RE: [GD-General] runtime error logging
> > 
> > 
> > We do three things. (1) surround high-frequency info with 
> > single quotes. (2)
> > hash the characters _not_ in single quotes. (3) check hash 
> > against a list of
> > "I've already reported that" errors. So you have:
> > 
> > LOG_ERROR ( "Unknown effect '%s' in mesh '%s'\n", 
> > sEffectName, sMeshName );
> > 
> > So this is a spritnf-style format string, and will come out 
> > to be something
> > like:
> > 
> > Unknown effect 'WATRE' in mesh 'blah.x'
> > Unknown effect 'WATRE' in mesh 'blah2.x'
> > Unknown effect 'WATRE' in mesh 'blah3.x'
> > 
> > ...so then we remove everything in single quotes:
> > 
> > Unknown effect  in mesh 
> > Unknown effect  in mesh 
> > Unknown effect  in mesh 
> > 
> > ...and hash those. And of course they all come out with the 
> > same hash value
> > and only the first one gets reported if you click on "Ignore 
> > all" in our
> > little dialog box.
> > 
> > 
> > Tom Forsyth - Muckyfoot bloke and Microsoft MVP.
> > 
> > This email is the product of your deranged imagination,
> > and does not in any way imply existence of the author.
> > 
> > > -----Original Message-----
> > > From: Andras Balogh [mailto:bn...@ma...]
> > > Sent: 14 July 2003 16:41
> > > To: gam...@li...
> > > Subject: [GD-General] runtime error logging
> > > 
> > > 
> > > There are some cases when I have to deal with runtime errors that
> > > cannot be seen before, such as when the user executes an invalid
> > > script. I can handle these events, but I would also like 
> to log them
> > > somewhere. The problem is that these invalid events may happen in
> > > every frame (or even multiple times a frame) flooding the 
> > log file in
> > > no time...
> > > 
> > > Any ideas on how I could do "singleton" logging of errors?
> > > Can't think of any simple solution :(
> > > 
> > > thanks,
> > > 
> > > Bandi
> > > 
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This SF.Net email sponsored by: Parasoft
> > > Error proof Web apps, automate testing & more.
> > > Download & eval WebKing and get a free book.
> > > www.parasoft.com/bulletproofapps1
> > > _______________________________________________
> > > Gamedevlists-general mailing list
> > > Gam...@li...
> > > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > > Archives:
> > > http://sourceforge.net/mailarchive/forum.php?forum_id=557
> > > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email sponsored by: Parasoft
> > Error proof Web apps, automate testing & more.
> > Download & eval WebKing and get a free book.
> > www.parasoft.com/bulletproofapps1
> > _______________________________________________
> > Gamedevlists-general mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=557
> > 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a 
> single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual 
> machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

RE: [GD-General] runtime error logging

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

I'm guessing that Tom wants to be able to shut off instances
of a log message (for a 'mesh1' but not 'mesh2').  I think
someone mentioned already that you hash the format string
for the "class" of logs and the formatted string for the
"instance" of logs. =20

I'm not sure why you would hash only the strings in quotes.
If you have multiple classes of messages that each used
'mesh1' as the only param then you'd potentially ignore
both by just hashing the params.

Paul


> -----Original Message-----
> From: gam...@li...=20
> [mailto:gam...@li...] On=20
> Behalf Of Gareth Lewin
> Sent: Wednesday, July 16, 2003 1:46 AM
> To: gam...@li...
> Subject: RE: [GD-General] runtime error logging
>=20
> Silly questoin, but couldn't you hash the string before the=20
> params were evaluated ? So you would just hash "Unknown=20
> effect '%s' in mesh '%s'\n"=20
>=20
> > -----Original Message-----
> > From: Tom Forsyth [mailto:to...@mu...]
> > Sent: 14 July 2003 17:03
> > To: gam...@li...
> > Subject: RE: [GD-General] runtime error logging
> >=20
> >=20
> > We do three things. (1) surround high-frequency info with single=20
> > quotes. (2) hash the characters _not_ in single quotes. (3)=20
> check hash=20
> > against a list of "I've already reported that" errors. So you have:
> >=20
> > LOG_ERROR ( "Unknown effect '%s' in mesh '%s'\n", sEffectName,=20
> > sMeshName );
> >=20
> > So this is a spritnf-style format string, and will come out to be=20
> > something
> > like:
> >=20
> > Unknown effect 'WATRE' in mesh 'blah.x'
> > Unknown effect 'WATRE' in mesh 'blah2.x'
> > Unknown effect 'WATRE' in mesh 'blah3.x'
> >=20
> > ...so then we remove everything in single quotes:
> >=20
> > Unknown effect  in mesh
> > Unknown effect  in mesh
> > Unknown effect  in mesh
> >=20
> > ...and hash those. And of course they all come out with the=20
> same hash=20
> > value and only the first one gets reported if you click on "Ignore=20
> > all" in our little dialog box.
> >=20
> >=20
> > Tom Forsyth - Muckyfoot bloke and Microsoft MVP.
> >=20
> > This email is the product of your deranged imagination, and=20
> does not=20
> > in any way imply existence of the author.
> >=20
> > > -----Original Message-----
> > > From: Andras Balogh [mailto:bn...@ma...]
> > > Sent: 14 July 2003 16:41
> > > To: gam...@li...
> > > Subject: [GD-General] runtime error logging
> > >=20
> > >=20
> > > There are some cases when I have to deal with runtime errors that=20
> > > cannot be seen before, such as when the user executes an invalid=20
> > > script. I can handle these events, but I would also like=20
> to log them=20
> > > somewhere. The problem is that these invalid events may happen in=20
> > > every frame (or even multiple times a frame) flooding the
> > log file in
> > > no time...
> > >=20
> > > Any ideas on how I could do "singleton" logging of errors?
> > > Can't think of any simple solution :(
> > >=20
> > > thanks,
> > >=20
> > > Bandi
> > >=20
> > >=20
> > >=20
> > >=20
> > > -------------------------------------------------------
> > > This SF.Net email sponsored by: Parasoft Error proof Web apps,=20
> > > automate testing & more.
> > > Download & eval WebKing and get a free book.
> > > www.parasoft.com/bulletproofapps1
> > > _______________________________________________
> > > Gamedevlists-general mailing list
> > > Gam...@li...
> > > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > > Archives:
> > > http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
> > >=20
> >=20
> >=20
> > -------------------------------------------------------
> > This SF.Net email sponsored by: Parasoft Error proof Web apps,=20
> > automate testing & more.
> > Download & eval WebKing and get a free book.
> > www.parasoft.com/bulletproofapps1
> > _______________________________________________
> > Gamedevlists-general mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
> >=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware With VMware you=20
> can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual=20
> machines at the same time. Free trial click here:=20
> http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
>=20
>=20

RE: [GD-General] runtime error logging

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

Silly questoin, but couldn't you hash the string before the params were
evaluated ? So you would just hash "Unknown effect '%s' in mesh '%s'\n" 

> -----Original Message-----
> From: Tom Forsyth [mailto:to...@mu...]
> Sent: 14 July 2003 17:03
> To: gam...@li...
> Subject: RE: [GD-General] runtime error logging
> 
> 
> We do three things. (1) surround high-frequency info with 
> single quotes. (2)
> hash the characters _not_ in single quotes. (3) check hash 
> against a list of
> "I've already reported that" errors. So you have:
> 
> LOG_ERROR ( "Unknown effect '%s' in mesh '%s'\n", 
> sEffectName, sMeshName );
> 
> So this is a spritnf-style format string, and will come out 
> to be something
> like:
> 
> Unknown effect 'WATRE' in mesh 'blah.x'
> Unknown effect 'WATRE' in mesh 'blah2.x'
> Unknown effect 'WATRE' in mesh 'blah3.x'
> 
> ...so then we remove everything in single quotes:
> 
> Unknown effect  in mesh 
> Unknown effect  in mesh 
> Unknown effect  in mesh 
> 
> ...and hash those. And of course they all come out with the 
> same hash value
> and only the first one gets reported if you click on "Ignore 
> all" in our
> little dialog box.
> 
> 
> Tom Forsyth - Muckyfoot bloke and Microsoft MVP.
> 
> This email is the product of your deranged imagination,
> and does not in any way imply existence of the author.
> 
> > -----Original Message-----
> > From: Andras Balogh [mailto:bn...@ma...]
> > Sent: 14 July 2003 16:41
> > To: gam...@li...
> > Subject: [GD-General] runtime error logging
> > 
> > 
> > There are some cases when I have to deal with runtime errors that
> > cannot be seen before, such as when the user executes an invalid
> > script. I can handle these events, but I would also like to log them
> > somewhere. The problem is that these invalid events may happen in
> > every frame (or even multiple times a frame) flooding the 
> log file in
> > no time...
> > 
> > Any ideas on how I could do "singleton" logging of errors?
> > Can't think of any simple solution :(
> > 
> > thanks,
> > 
> > Bandi
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email sponsored by: Parasoft
> > Error proof Web apps, automate testing & more.
> > Download & eval WebKing and get a free book.
> > www.parasoft.com/bulletproofapps1
> > _______________________________________________
> > Gamedevlists-general mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=557
> > 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

Re: [GD-General] runtime error logging

[Colin F. <cp...@ea...>]

I like the idea of hashing error strings, collapsing identical
error messages in to a single instance.  Thus, the time stamp
should not be part of the error text message; it should be
stored along with the error, and should be "printed" alongside
the error text upon display and/or logging to a file.

I like the idea of having flags associated with messages,
such as priority, and basic nature.

I think the error logging mechanism should have settings
to allow filtering out messages based on priority.  Also,
the user should be able to control which kinds of messages
are subject to "collapsing via hashing".

If you do collapse any messages, for sure I think you should
COUNT the number of collapsed incidents.  I think it would
be illuminating to see that an error message occurred exactly
706 times (perhaps the number of keystrokes, resource files,
seconds elapsed, visible objects, etc), or just one time, or
1,000,000 times!

Finally, I think you should store a run-length encoded 
vector of the error hash values.  It should be possible
for you to recover the temporal order of all error messages.

I was considering allowing myself to suppress specific 
error messages from appearing on a console in my game,
dynamically.  I would type: "hide error 17", or simply
right-click on the error and select "hide".  Thus, the
console would not be cluttered by future instances of
"error 17".

I suppose an upper limit on the log file / error log file
size is a good idea, or some policy about what to do when
a certain size is reached.

I guess I haven't really run in to many situations in which
the number of error / status messages has swamped me -- but I've
heard of a single, persisting error condition (network down,
out of disk space, out of memory, etc) leading to all available
disk space being used to repeatedly log the same error.
It is really ironic when the huge log file leads to errors 
that also need to be logged, thus leading to endless silly
log messages.  It's as nutty as an exception handler doing
something ambitious, like launching a window to report the
error, causing another out-of-memory exception!  At that
point your app is doubly-insane.

--- Colin

cp...@ea...

RE: [GD-General] runtime error logging

[Peter L. <pe...@to...>]

you just need a signature you can check against a database of what's been
reported. If you have printf-style log messages, you can generate the
signature from the string; use the format-string if you want to limit
reports by class, or the output string if you have a more particular
definition of 'already seen error'.

Peter

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Andras Balogh
> Sent: Tuesday, July 15, 2003 5:18 AM
> To: Stefan Boberg
> Subject: Re: [GD-General] runtime error logging
>
>
> Monday, July 14, 2003, 6:11:21 PM, Stefan Boberg wrote:
>
> >> Any ideas on how I could do "singleton" logging of errors?
> >> Can't think of any simple solution :(
>
> >   Would this work ok in your case?
>
> > #define Singleton_Log(x) { static bool bSeen = false; \
> >             if (bSeen == false) { bSeen = true; LogMessage(x) } }
>
>
> No, not really. :(
>
> The problem is that I handle errors at one place, and I would like to
> report many different errors and warnings, but only once each.
>
>
>
> b
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps1
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>
>