Sign in with
Sign up | Sign in
Your question

Prime95 is stuck

Last response: in Overclocking
Share
Anonymous
a b K Overclocking
January 10, 2005 12:22:03 AM

Archived from groups: alt.comp.hardware.overclocking (More info?)

Hello.
I don't know whether this is the correct group to post to.
But I decided to use the 'torture test' of the program Prime95 to test the
stability of a computer but it doesn't get past the first test. It doesn't
fail. It just doesn't do anything. It says it's working through Test 1 but
it never moves on to Test 2 even after several hours.
I tried the 3 different types of torture test and it never moves on.

When I tried to run the test on another computer it only takes a few mins to
complete the first test, then a few seconds to complete each of the others.
By searching the internet and usegroups I found that this is what is meant
to happen and seems to be everyone elses experience.

Does anyone know how I can get this program to work on this computer.
The specs are:-
Pentium 4 2.6Ghz
1500MB Ram
ATI Radeon 9800Pro
WinXP Home SP2
Thanks

More about : prime95 stuck

Anonymous
a b K Overclocking
January 10, 2005 11:31:41 PM

Archived from groups: alt.comp.hardware.overclocking (More info?)

On Sun, 9 Jan 2005 21:22:03 -0000, "MikeJohnes"
<1412ffre1@hotmail.com> wrote:

>Hello.
>I don't know whether this is the correct group to post to.
>But I decided to use the 'torture test' of the program Prime95 to test the
>stability of a computer but it doesn't get past the first test. It doesn't
>fail. It just doesn't do anything. It says it's working through Test 1 but
>it never moves on to Test 2 even after several hours.
>I tried the 3 different types of torture test and it never moves on.
>
>When I tried to run the test on another computer it only takes a few mins to
>complete the first test, then a few seconds to complete each of the others.
>By searching the internet and usegroups I found that this is what is meant
>to happen and seems to be everyone elses experience.

Prime95 is a very stable, well established and professionally written
piece of software. It cannot be the software unless your download had
a glitch in it or something went weird during the install. If I were
you I would remove it, redownload and reinstall Pirme95.

If you have the same fault after reloading Prime95 then your computer
is unstable - no questions about it. At that point you need to check
all your BIOS settings (perhaps going back to failsafe BIOS settings),
check the temperatures of your MB and CPU and check the voltages from
your power supply.

Larry Gagnon, A+ certifed tech.
Anonymous
a b K Overclocking
January 11, 2005 10:36:04 AM

Archived from groups: alt.comp.hardware.overclocking (More info?)

Larry Gagnon skrev:
> On Sun, 9 Jan 2005 21:22:03 -0000, "MikeJohnes"
> <1412ffre1@hotmail.com> wrote:
>
>
>>Hello.
>>I don't know whether this is the correct group to post to.
>>But I decided to use the 'torture test' of the program Prime95 to test the
>>stability of a computer but it doesn't get past the first test. It doesn't
>>fail. It just doesn't do anything. It says it's working through Test 1 but
>>it never moves on to Test 2 even after several hours.
>>I tried the 3 different types of torture test and it never moves on.
>>
>>When I tried to run the test on another computer it only takes a few mins to
>>complete the first test, then a few seconds to complete each of the others.
>>By searching the internet and usegroups I found that this is what is meant
>>to happen and seems to be everyone elses experience.
>
>
> Prime95 is a very stable, well established and professionally written
> piece of software. It cannot be the software unless your download had
> a glitch in it or something went weird during the install. If I were
> you I would remove it, redownload and reinstall Pirme95.
>
> If you have the same fault after reloading Prime95 then your computer
> is unstable - no questions about it. At that point you need to check
> all your BIOS settings (perhaps going back to failsafe BIOS settings),
> check the temperatures of your MB and CPU and check the voltages from
> your power supply.
>
> Larry Gagnon, A+ certifed tech.

hi

that stable and perfect is not prime! it wont run on a machine with dep activated, thats
version 23.8.1.0 and some older versions. (xp pro2 on a amd64)

coco
Related resources
Anonymous
a b K Overclocking
January 11, 2005 11:49:04 PM

Archived from groups: alt.comp.hardware.overclocking (More info?)

CoCo <cocotm@tele2.se> writes:
>Larry Gagnon skrev:
>> On Sun, 9 Jan 2005 21:22:03 -0000, "MikeJohnes"
>> <1412ffre1@hotmail.com> wrote:
>>>Hello.
>>>I don't know whether this is the correct group to post to.
>>>But I decided to use the 'torture test' of the program Prime95 to test the
>>>stability of a computer but it doesn't get past the first test. It doesn't
>>>fail. It just doesn't do anything. It says it's working through Test 1 but
>>>it never moves on to Test 2 even after several hours.
>>>I tried the 3 different types of torture test and it never moves on.
>>>
>>>When I tried to run the test on another computer it only takes a few mins to
>>>complete the first test, then a few seconds to complete each of the others.
>>>By searching the internet and usegroups I found that this is what is meant
>>>to happen and seems to be everyone elses experience.
>>
>>
>> Prime95 is a very stable, well established and professionally written
>> piece of software. It cannot be the software unless your download had
>> a glitch in it or something went weird during the install. If I were
>> you I would remove it, redownload and reinstall Pirme95.
>>
>> If you have the same fault after reloading Prime95 then your computer
>> is unstable - no questions about it. At that point you need to check
>> all your BIOS settings (perhaps going back to failsafe BIOS settings),
>> check the temperatures of your MB and CPU and check the voltages from
>> your power supply.
>>
>> Larry Gagnon, A+ certifed tech.

>that stable and perfect is not prime! it wont run on a machine with dep
>activated, thats version 23.8.1.0 and some older versions. (xp pro2 on
>a amd64)

>coco

If you search for prime95 in microsoft.public.windowsxp.general
from a month or three ago, I believe that I and someone else did
figure out why he was having prime95 fail under DEP. He was
having the same problem because he had turned on DEP for everything
on the system. When he backed that off of prime95 then it worked
for him, or maybe I'm forgetting some of the details, but we did
get it working for him and in his case it was DEP related.

And if the original poster is still having problems with prime95
and would like some help then throw me email and I'll try to help
you try to figure out what is going on. I don't use it for the
memory testing or group work but as a stand-alone factoring engine.
Anonymous
a b K Overclocking
January 12, 2005 10:58:15 AM

Archived from groups: alt.comp.hardware.overclocking (More info?)

Don Taylor skrev:
> CoCo <cocotm@tele2.se> writes:
>
>>Larry Gagnon skrev:
>>
>>>On Sun, 9 Jan 2005 21:22:03 -0000, "MikeJohnes"
>>><1412ffre1@hotmail.com> wrote:
>>>
>>>>Hello.
>>>>I don't know whether this is the correct group to post to.
>>>>But I decided to use the 'torture test' of the program Prime95 to test the
>>>>stability of a computer but it doesn't get past the first test. It doesn't
>>>>fail. It just doesn't do anything. It says it's working through Test 1 but
>>>>it never moves on to Test 2 even after several hours.
>>>>I tried the 3 different types of torture test and it never moves on.
>>>>
>>>>When I tried to run the test on another computer it only takes a few mins to
>>>>complete the first test, then a few seconds to complete each of the others.
>>>>By searching the internet and usegroups I found that this is what is meant
>>>>to happen and seems to be everyone elses experience.
>>>
>>>
>>>Prime95 is a very stable, well established and professionally written
>>>piece of software. It cannot be the software unless your download had
>>>a glitch in it or something went weird during the install. If I were
>>>you I would remove it, redownload and reinstall Pirme95.
>>>
>>>If you have the same fault after reloading Prime95 then your computer
>>>is unstable - no questions about it. At that point you need to check
>>>all your BIOS settings (perhaps going back to failsafe BIOS settings),
>>>check the temperatures of your MB and CPU and check the voltages from
>>>your power supply.
>>>
>>>Larry Gagnon, A+ certifed tech.
>
>
>>that stable and perfect is not prime! it wont run on a machine with dep
>>activated, thats version 23.8.1.0 and some older versions. (xp pro2 on
>>a amd64)
>
>
>>coco
>
>
> If you search for prime95 in microsoft.public.windowsxp.general
> from a month or three ago, I believe that I and someone else did
> figure out why he was having prime95 fail under DEP. He was
> having the same problem because he had turned on DEP for everything
> on the system. When he backed that off of prime95 then it worked
> for him, or maybe I'm forgetting some of the details, but we did
> get it working for him and in his case it was DEP related.
>
> And if the original poster is still having problems with prime95
> and would like some help then throw me email and I'll try to help
> you try to figure out what is going on. I don't use it for the
> memory testing or group work but as a stand-alone factoring engine.

hi

i am running prime without dep, just pointed out that the programming done in prime isnt
perfect or wasnt done with normal programming rules. (no program should trip dep ever)

(no solution or reason given in microsoft.public.windowsxp.general)

coco
Anonymous
a b K Overclocking
January 12, 2005 7:32:20 PM

Archived from groups: alt.comp.hardware.overclocking (More info?)

On Tue, 11 Jan 2005 07:36:04 GMT, CoCo <cocotm@tele2.se> wrote:

>Larry Gagnon skrev:
>> On Sun, 9 Jan 2005 21:22:03 -0000, "MikeJohnes"
>> <1412ffre1@hotmail.com> wrote:

>> Prime95 is a very stable, well established and professionally written
>> piece of software. It cannot be the software unless your download had
>> a glitch in it or something went weird during the install. If I were
>> you I would remove it, redownload and reinstall Pirme95.
>>
>> If you have the same fault after reloading Prime95 then your computer
>> is unstable - no questions about it. At that point you need to check
>> all your BIOS settings (perhaps going back to failsafe BIOS settings),
>> check the temperatures of your MB and CPU and check the voltages from
>> your power supply.
>>
>> Larry Gagnon, A+ certifed tech.
>
>hi
>
>that stable and perfect is not prime! it wont run on a machine with dep activated, thats
>version 23.8.1.0 and some older versions. (xp pro2 on a amd64)
>
>coco


Coco: sorry but you make the gross assumption that Prime95 is unstable
under WinXP. A lot of software is unstable under Windows because
Windows is a lousy operating system. Prime95 is perfectly stable under
Linux and on my Win98SE box. I suspect therefore, that if there is any
glitch running Prime95 under dep under WinXP then the fault lies with
dep or WinXP and NOT with Prime95.

Larry Gagnon
Anonymous
a b K Overclocking
January 12, 2005 11:16:33 PM

Archived from groups: alt.comp.hardware.overclocking (More info?)

CoCo wrote:
[...]
> i am running prime without dep, just pointed out that the programming
> done in prime isnt perfect or wasnt done with normal programming
> rules. (no program should trip dep ever)

You're assuming there that both DEP and Windows are perfect :)  I'd say it's
just as likely, if not more likely, that the problems are in DEP or one of
the system DLLs conflicting with DEP.

--
Michael Brown
www.emboss.co.nz : OOS/RSI software and more :) 
Add michael@ to emboss.co.nz ---+--- My inbox is always open
Anonymous
a b K Overclocking
January 12, 2005 11:16:34 PM

Archived from groups: alt.comp.hardware.overclocking (More info?)

Michael Brown skrev:
> CoCo wrote:
> [...]
>
>>i am running prime without dep, just pointed out that the programming
>>done in prime isnt perfect or wasnt done with normal programming
>>rules. (no program should trip dep ever)
>
>
> You're assuming there that both DEP and Windows are perfect :)  I'd say it's
> just as likely, if not more likely, that the problems are in DEP or one of
> the system DLLs conflicting with DEP.
>

hi

not really, but i have dep active for all tasks and it's only prime that have tripped it.

all dll/resources under prime task is common shared stuff that other apps do use without
any problems (ex prime95.exe)

coco
Anonymous
a b K Overclocking
January 13, 2005 12:31:14 AM

Archived from groups: alt.comp.hardware.overclocking (More info?)

CoCo <cocotm@tele2.se> wrote:

> (no program should trip dep ever)

I don't think I would agree with that. There maybe applications where for
reasons of speed or efficiency some method is used which trips DEP. That
doesn't make such an application necessarily dangerous or bad.
Anonymous
a b K Overclocking
January 13, 2005 2:14:47 AM

Archived from groups: alt.comp.hardware.overclocking (More info?)

Mitch Crane wrote:
> CoCo <cocotm@tele2.se> wrote:
>
>
>>(no program should trip dep ever)
>
>
> I don't think I would agree with that. There maybe applications where for
> reasons of speed or efficiency some method is used which trips DEP.

"Speed and efficiency" are not always compatible with security. For
example, a firewall consumes resources but it's more secure than a 'speedy
and efficient' open system.

> That
> doesn't make such an application necessarily dangerous or bad.

The application itself may not be malicious but if it depends on a
methodology that necessitates bypassing a system's security features then
it *is* 'dangerous and bad'.
Anonymous
a b K Overclocking
January 13, 2005 11:03:01 AM

Archived from groups: alt.comp.hardware.overclocking (More info?)

Larry Gagnon skrev:
> On Tue, 11 Jan 2005 07:36:04 GMT, CoCo <cocotm@tele2.se> wrote:
>
>
>>Larry Gagnon skrev:
>>
>>>On Sun, 9 Jan 2005 21:22:03 -0000, "MikeJohnes"
>>><1412ffre1@hotmail.com> wrote:
>
>
>>>Prime95 is a very stable, well established and professionally written
>>>piece of software. It cannot be the software unless your download had
>>>a glitch in it or something went weird during the install. If I were
>>>you I would remove it, redownload and reinstall Pirme95.
>>>
>>>If you have the same fault after reloading Prime95 then your computer
>>>is unstable - no questions about it. At that point you need to check
>>>all your BIOS settings (perhaps going back to failsafe BIOS settings),
>>>check the temperatures of your MB and CPU and check the voltages from
>>>your power supply.
>>>
>>>Larry Gagnon, A+ certifed tech.
>>
>>hi
>>
>>that stable and perfect is not prime! it wont run on a machine with dep activated, thats
>>version 23.8.1.0 and some older versions. (xp pro2 on a amd64)
>>
>>coco
>
>
>
> Coco: sorry but you make the gross assumption that Prime95 is unstable
> under WinXP. A lot of software is unstable under Windows because
> Windows is a lousy operating system. Prime95 is perfectly stable under
> Linux and on my Win98SE box. I suspect therefore, that if there is any
> glitch running Prime95 under dep under WinXP then the fault lies with
> dep or WinXP and NOT with Prime95.
>
> Larry Gagnon

hi

ok, ok, i think prime is a good thing and do run it anyway. it wasnt even me that had
problems in the first place, it was mike johnes!

coco
Anonymous
a b K Overclocking
January 13, 2005 7:32:22 PM

Archived from groups: alt.comp.hardware.overclocking (More info?)

David Maynard <dNOTmayn@ev1.net> wrote:

> Mitch Crane wrote:
>> CoCo <cocotm@tele2.se> wrote:
>>
>>
>>>(no program should trip dep ever)
>>
>>
>> I don't think I would agree with that. There maybe applications where
>> for reasons of speed or efficiency some method is used which trips
>> DEP.
>
> "Speed and efficiency" are not always compatible with security. For
> example, a firewall consumes resources but it's more secure than a
> 'speedy and efficient' open system.

And they aren't always incompatible either. For example, Prime95 may use
some programming methodolgy which executes what Windows thinks is data
in a perfectly safe and known way--it knows what it's doing even if
Windows doesn't--, because speed is of prime (no pun intended)
importance. Your firewall may block certain network operations, because
they can be dangerous, but it doesn't block them all. The fact that an
app access the net doesn't make that a bad app.

>> That doesn't make such an application necessarily dangerous or bad.
>
> The application itself may not be malicious but if it depends on a
> methodology that necessitates bypassing a system's security features
> then it *is* 'dangerous and bad'.

Not neccesarily. Is there and danger of Prime95 being exploited by some
third-party to execute data and comprimise the system? I've seen no
evidence of this. Windows' DEP is a blanket general protection scheme
for to cover unknown bad apps. There are a lot of exploitable apps out
there--probably in no small part due to MS compilers. This scheme was
cooked up to cover those, but it gets some perfectly safe apps in the
process.

One might argue that networking in general is dangeraous, as that's the
major path viruses and worms use to infect large numbers of computers,
but we don't disable all networking in XP, because that would break a
lot of useful and not dangerous apps and would be unacceptable to most
users. DEP, on the other hand, doesn't break that much. If a few babies
get thrown out with the bath water MS doesn't really care.

Back to your firewall example. If your contention is that the danger
comes in having to turn off DEP for all apps then my contention is that
DEP is broken. Just as your firewall would be broken if you had to turn
it completely off in order to surf the web.

I haven't touched the DEP settings in my PC and Prime95 works perfectly
well for me, however, so I'm not sure what the fuss is all about.
Anonymous
a b K Overclocking
January 14, 2005 4:22:24 AM

Archived from groups: alt.comp.hardware.overclocking (More info?)

David Maynard wrote:
> Mitch Crane wrote:
>> CoCo <cocotm@tele2.se> wrote:
>>
>>
>>> (no program should trip dep ever)
>>
>>
>> I don't think I would agree with that. There maybe applications
>> where for reasons of speed or efficiency some method is used which
>> trips DEP.
>
> "Speed and efficiency" are not always compatible with security. For
> example, a firewall consumes resources but it's more secure than a
> 'speedy and efficient' open system.
>
>> That
>> doesn't make such an application necessarily dangerous or bad.
>
> The application itself may not be malicious but if it depends on a
> methodology that necessitates bypassing a system's security features
> then it *is* 'dangerous and bad'.

There's essentially three types of DEP:

1) Software DEP for non Safe Structured Exception Handling (SSEH)
applications. In these cases, when an exception is fired, the exception
handler address is checked to make sure it points to an area marked as
"executable". Since the SEH handler addresses are stored on the stack, and
SEH provides a nice way to jump back into the stack, they are a prime
canditate for buffer overflow attacks. Of course, none of the exploits
(AFAIK) have rewritten this address with a non-executable address, there
always being sufficient code in known executable areas for this attack to
proceed. So this class of DEP (which isn't really "data execution
prevention') is pretty much useless for preventing attacks. Note that
exceptions are commonly used for graceful failure handling (for example a
TCP connection attemtp failing, or a divide by zero), so an exception
occuring is not a bug.

2) Software DEP for SSEH applications. Similar to 1, except that the
exception handlers must be one that is in a list that is generated by the
linker. So the only code that can be executed after an exception is a
registered exception handler, which means that attacks by overwriting the
SEH pointers on the stack are pretty much always stopped. This type of DEP
(which isn't really "data execution prevention" either) does help things as
opposed to 1. However, it still does not fix the problem of return address
overwriting (which, depending on the compiler and the situation, may or may
not be possible). Of course, this requires a recompile with a supporting
compiler (ie: MSVC, since SSEH is completely undocumented. To get an idea of
the extent of SSEH documentation type "SEHandlerTable" into google ...).

3) Hardware DEP. Only with CPUs with the NX bit, this prevents the CPU from
executing at addresses not marked as executable. This includes the stack and
the heap (pretty much the only places where you can put stuff in with buffer
overflow attacks) so this is very effective in stopping buffer overflow
attacks.

The main culprits for setting off any of the forms of DEP are JIT compilers
and programs that do runtime optimisation of themselves to suit the CPU
they're running on. The second form is also often triggered by
dynamically-allocated stubs that are commonly used to sit between the
non-object-orientated Win32 API and an object-orientated component library
(MFC, VCL, etc). Back in the good ol' days, you just grabbed a few bytes of
memory off the heap and were away. Everything worked fine, even though the
memory was technically not marked as executable. Older versions of MSVC used
to do this (circa version 2 or so IIRC) though I believe they've cleaned up
the latest MFC DLLs to do things properly. Dynamically allocated stubs are
also used in quite a few of the system DLLs to do various tasks, which may
be the cause of some of the DEP-related issues. To solve the problem, you
need to allocate a second heap and use VirtualProtect to mark the second
heap as executable. The second main problem area is copy protection
(obviously not relevant to Prime95) as a VirtualProtect call to get
executable-OK memory is like a big flashing sign saying "I'm just about to
play silly buggers with some code, you may want to have a look at where I'm
calling from".

Of course, you also have the normal problem of just plain buggy code, and we
all know how good MS is at length-checking buffers ...

That said, no perfect application, running on a perfect OS with a perfect
RTL, should cause any DEP errors. Of course, Windows, the MS RTL, and
Prime95 are not perfect though in many cases the distribution of blame for a
particular imperfection can't be put entirely on one component. If the Win32
documentation is missing some details, and the programmer relies on the
function acting as it says it should when passed shonky data, who is at
fault? MS for the documentation or the programmer by relying on the function
to do the job of validating the data?

OK, I think I've rambled on long enough. In this case there's no proof that
DEP is even the cause of the problem. DEP should fire an EAccessViolation
when it detects something bad going on, and this should be picked up by
Prime95 (or Prime95 should crash). In this case it appears that the Prime95
engine just doesn't start, which may or may not be related to DEP.

--
Michael Brown
www.emboss.co.nz : OOS/RSI software and more :) 
Add michael@ to emboss.co.nz ---+--- My inbox is always open
Anonymous
a b K Overclocking
January 14, 2005 7:07:37 AM

Archived from groups: alt.comp.hardware.overclocking (More info?)

Michael Brown wrote:
> David Maynard wrote:
>
>>Mitch Crane wrote:
>>
>>>CoCo <cocotm@tele2.se> wrote:
>>>
>>>
>>>
>>>>(no program should trip dep ever)
>>>
>>>
>>>I don't think I would agree with that. There maybe applications
>>>where for reasons of speed or efficiency some method is used which
>>>trips DEP.
>>
>>"Speed and efficiency" are not always compatible with security. For
>>example, a firewall consumes resources but it's more secure than a
>>'speedy and efficient' open system.
>>
>>
>>>That
>>>doesn't make such an application necessarily dangerous or bad.
>>
>>The application itself may not be malicious but if it depends on a
>>methodology that necessitates bypassing a system's security features
>>then it *is* 'dangerous and bad'.
>
>
> There's essentially three types of DEP:
>
> 1) Software DEP for non Safe Structured Exception Handling (SSEH)
> applications. In these cases, when an exception is fired, the exception
> handler address is checked to make sure it points to an area marked as
> "executable". Since the SEH handler addresses are stored on the stack, and
> SEH provides a nice way to jump back into the stack, they are a prime
> canditate for buffer overflow attacks. Of course, none of the exploits
> (AFAIK) have rewritten this address with a non-executable address, there
> always being sufficient code in known executable areas for this attack to
> proceed. So this class of DEP (which isn't really "data execution
> prevention') is pretty much useless for preventing attacks. Note that
> exceptions are commonly used for graceful failure handling (for example a
> TCP connection attemtp failing, or a divide by zero), so an exception
> occuring is not a bug.
>
> 2) Software DEP for SSEH applications. Similar to 1, except that the
> exception handlers must be one that is in a list that is generated by the
> linker. So the only code that can be executed after an exception is a
> registered exception handler, which means that attacks by overwriting the
> SEH pointers on the stack are pretty much always stopped. This type of DEP
> (which isn't really "data execution prevention" either) does help things as
> opposed to 1. However, it still does not fix the problem of return address
> overwriting (which, depending on the compiler and the situation, may or may
> not be possible). Of course, this requires a recompile with a supporting
> compiler (ie: MSVC, since SSEH is completely undocumented. To get an idea of
> the extent of SSEH documentation type "SEHandlerTable" into google ...).
>
> 3) Hardware DEP. Only with CPUs with the NX bit, this prevents the CPU from
> executing at addresses not marked as executable. This includes the stack and
> the heap (pretty much the only places where you can put stuff in with buffer
> overflow attacks) so this is very effective in stopping buffer overflow
> attacks.
>
> The main culprits for setting off any of the forms of DEP are JIT compilers
> and programs that do runtime optimisation of themselves to suit the CPU
> they're running on. The second form is also often triggered by
> dynamically-allocated stubs that are commonly used to sit between the
> non-object-orientated Win32 API and an object-orientated component library
> (MFC, VCL, etc). Back in the good ol' days, you just grabbed a few bytes of
> memory off the heap and were away. Everything worked fine, even though the
> memory was technically not marked as executable. Older versions of MSVC used
> to do this (circa version 2 or so IIRC) though I believe they've cleaned up
> the latest MFC DLLs to do things properly. Dynamically allocated stubs are
> also used in quite a few of the system DLLs to do various tasks, which may
> be the cause of some of the DEP-related issues. To solve the problem, you
> need to allocate a second heap and use VirtualProtect to mark the second
> heap as executable. The second main problem area is copy protection
> (obviously not relevant to Prime95) as a VirtualProtect call to get
> executable-OK memory is like a big flashing sign saying "I'm just about to
> play silly buggers with some code, you may want to have a look at where I'm
> calling from".
>
> Of course, you also have the normal problem of just plain buggy code, and we
> all know how good MS is at length-checking buffers ...
>
> That said, no perfect application, running on a perfect OS with a perfect
> RTL, should cause any DEP errors. Of course, Windows, the MS RTL, and
> Prime95 are not perfect though in many cases the distribution of blame for a
> particular imperfection can't be put entirely on one component. If the Win32
> documentation is missing some details, and the programmer relies on the
> function acting as it says it should when passed shonky data, who is at
> fault? MS for the documentation or the programmer by relying on the function
> to do the job of validating the data?
>
> OK, I think I've rambled on long enough. In this case there's no proof that
> DEP is even the cause of the problem. DEP should fire an EAccessViolation
> when it detects something bad going on, and this should be picked up by
> Prime95 (or Prime95 should crash). In this case it appears that the Prime95
> engine just doesn't start, which may or may not be related to DEP.
>

Excellent dissertation and there's nothing in there to disagree with.

I wasn't arguing whether DEP was the cause, or that it's 'perfect', or, as
you pointed out, that it's even the cause of the observed symptom. I was
disagreeing with the assertion that a program should have the 'rights' to
do anything it dern well pleases, for the sake of 'speed or efficiency',
and that if DEP gets in the way then DEP is 'faulty', for that reason
alone, even if it is performing flawlessly.
Anonymous
a b K Overclocking
January 14, 2005 7:43:58 AM

Archived from groups: alt.comp.hardware.overclocking (More info?)

Mitch Crane wrote:

> David Maynard <dNOTmayn@ev1.net> wrote:
>
>
>>Mitch Crane wrote:
>>
>>>CoCo <cocotm@tele2.se> wrote:
>>>
>>>
>>>
>>>>(no program should trip dep ever)
>>>
>>>
>>>I don't think I would agree with that. There maybe applications where
>>>for reasons of speed or efficiency some method is used which trips
>>>DEP.
>>
>>"Speed and efficiency" are not always compatible with security. For
>>example, a firewall consumes resources but it's more secure than a
>>'speedy and efficient' open system.
>
>
> And they aren't always incompatible either. For example, Prime95 may use
> some programming methodolgy which executes what Windows thinks is data
> in a perfectly safe and known way--it knows what it's doing even if
> Windows doesn't--,

You miss the point. Prime may know it's 'safe' but if DEP is forced to
allow Prime to do peculiar things then it must allow all programs to do
those peculiar things and the next program may NOT be 'safe'.

Unless you have the unreasonable expectation that Microsoft will write a
specific exclusion for the one program called 'Prime' (did anyone ASK then
to? How would they even know?) and deny the others.

> because speed is of prime (no pun intended)
> importance. Your firewall may block certain network operations, because
> they can be dangerous, but it doesn't block them all. The fact that an
> app access the net doesn't make that a bad app.

Poor example because you're talking about a normal mode of operation. Put
it in the DEP context where your 'Prime' program wants to fiddle directly
with the TCP/IP stack and hack buffers... in a perfectly 'safe' manner of
course. And then Mr. Hacker comes along and does the same thing except his
'purpose' isn't for 'speed or efficiency'.


>>>That doesn't make such an application necessarily dangerous or bad.
>>
>>The application itself may not be malicious but if it depends on a
>>methodology that necessitates bypassing a system's security features
>>then it *is* 'dangerous and bad'.
>
>
> Not neccesarily. Is there and danger of Prime95 being exploited by some
> third-party to execute data and comprimise the system? I've seen no
> evidence of this.

Has nothing to do with 'Prime' being 'vulnerable'. It has to do with you
expecting the system to open it's doors to a program doing what (you
theorize) Prime is doing. And, as I mentioned above, if 'Prime' can do it
then so can any other program, for whatever purpose. An open door is an
open door.

> Windows' DEP is a blanket general protection scheme
> for to cover unknown bad apps. There are a lot of exploitable apps out
> there--probably in no small part due to MS compilers. This scheme was
> cooked up to cover those, but it gets some perfectly safe apps in the
> process.

You can attribute 'bad code' to anything you like but it's irrelevant. One
can intentionally write 'bad code' as well and there's no way for DEP to
know 'why' someone wrote code that's doing funky dunky things it shouldn't
be doing; be it a compiler 'woops', a hacker, or the 'speed & efficiency'
wizard.


> One might argue that networking in general is dangeraous, as that's the
> major path viruses and worms use to infect large numbers of computers,
> but we don't disable all networking in XP, because that would break a
> lot of useful and not dangerous apps and would be unacceptable to most
> users. DEP, on the other hand, doesn't break that much. If a few babies
> get thrown out with the bath water MS doesn't really care.

Inappropriate analogy. You compare removing entirely a vital capability,
I.E. 'disable all networking', to simply having a program obey proper O.S.
coding rules. There's nothing in DEP that prevents Prime from working, if
it does so properly, and the proper analogy is that Prime obeying DEP
'rules' is equivalent to a firewall on that internet connection. It may not
be quite as 'speedy or efficient', and it sure as heck isn't as convenient,
but it's vital to system security.


> Back to your firewall example. If your contention is that the danger
> comes in having to turn off DEP for all apps then my contention is that
> DEP is broken. Just as your firewall would be broken if you had to turn
> it completely off in order to surf the web.

How is Windows to know, without so much as a hint, that 'Prime' is so
privileged it's to be allowed O.S. level access? And how is it to know that
this, lord knows where it came from, program is allowed but no others are?

The answer is: it can't. And if you allow Prime to wander unimpeded through
system memory then you have to allow all the others too.

Again, your firewall analogy doesn't hold. A more appropriate analogy would
be a firewall that allows just any old program to open any port it feels
like any time it feels like it because the 'safe' program you write wants
to do so for 'speed or efficiency'.

I'm not concerned with the 'safe' program' It's the doors you want left
open simply for that program's convenience. Of course, the next guy with a
'safe' program wants a different door left open. And the third guy...


> I haven't touched the DEP settings in my PC and Prime95 works perfectly
> well for me, however, so I'm not sure what the fuss is all about.

Probably something else entirely and I'm not saying DEP is the problem or
that Prime is flawed. I'm just disagreeing with your assertion that DEP
should allow just any old program that feels like it to romp through the
system unimpeded. That defeats the whole concept.
Anonymous
a b K Overclocking
January 14, 2005 4:18:55 PM

Archived from groups: alt.comp.hardware.overclocking (More info?)

David Maynard <dNOTmayn@ev1.net> writes:
>Mitch Crane wrote:
>> David Maynard <dNOTmayn@ev1.net> wrote:
>>>Mitch Crane wrote:
>>>>CoCo <cocotm@tele2.se> wrote:
>>>>>(no program should trip dep ever)
>>>>I don't think I would agree with that. There maybe applications where
>>>>for reasons of speed or efficiency some method is used which trips
>>>>DEP.
>>>
>>>"Speed and efficiency" are not always compatible with security. For
>>>example, a firewall consumes resources but it's more secure than a
>>>'speedy and efficient' open system.
>>
>> And they aren't always incompatible either. For example, Prime95 may use
>> some programming methodolgy which executes what Windows thinks is data
>> in a perfectly safe and known way--it knows what it's doing even if
>> Windows doesn't--,

>You miss the point. Prime may know it's 'safe' but if DEP is forced to
>allow Prime to do peculiar things then it must allow all programs to do
>those peculiar things and the next program may NOT be 'safe'.

Perhaps I'm confused, but Windows already has built in the feature to
let you turn DEP on and off on a program by program basis. I do not
find any documentation that says you must allow this to be done for
all programs.

From the help system, the first hit:

"To turn Data Execution Prevention on or off for a program"

Now to be brutally fair, it goes on to say:

"If you turn off Data Execution Prevention (DEP) for a specific program,
it might become vulnerable to attack."

>Unless you have the unreasonable expectation that Microsoft will write a
>specific exclusion for the one program called 'Prime' (did anyone ASK then
>to? How would they even know?) and deny the others.

Already been done, hasn't it?

>How is Windows to know, without so much as a hint, that 'Prime' is so
>privileged it's to be allowed O.S. level access? And how is it to know that
>this, lord knows where it came from, program is allowed but no others are?

Because you:

You must be logged on as an administrator or a member of the
Administrators group in order to complete this procedure. If your
computer is connected to a network, network policy settings might
also prevent you from completing this procedure.

To open System Properties, click Start, click Control Panel, and
then double-click System.
Click the Advanced tab and, under Performance, click Settings.
Click the Data Execution Prevention tab.
In the Turn on DEP for all programs and services except those I
select list, do one of the following:

To turn off DEP for a program, select the check box next to the
program name and click OK. (If the name of the program doesn't
appear in the list, click Add, navigate to your Program Files
folder, select the program's executable file which will have an
.exe file extension, and click OK).

To turn on DEP for a program, clear the check box next to the
program name, and then click OK.

>The answer is: it can't. And if you allow Prime to wander unimpeded through
>system memory then you have to allow all the others too.

No

>Again, your firewall analogy doesn't hold. A more appropriate analogy would
>be a firewall that allows just any old program to open any port it feels
>like any time it feels like it because the 'safe' program you write wants
>to do so for 'speed or efficiency'.

No

>I'm not concerned with the 'safe' program' It's the doors you want left
>open simply for that program's convenience. Of course, the next guy with a
>'safe' program wants a different door left open. And the third guy...

>> I haven't touched the DEP settings in my PC and Prime95 works perfectly
>> well for me, however, so I'm not sure what the fuss is all about.

>Probably something else entirely and I'm not saying DEP is the problem or
>that Prime is flawed. I'm just disagreeing with your assertion that DEP
>should allow just any old program that feels like it to romp through the
>system unimpeded. That defeats the whole concept.

I don't think anybody said "any old program should go romping" but
I also don't think I understand the DEP to be all or nothing as you
seem to have found it to be.
Anonymous
a b K Overclocking
January 14, 2005 4:46:11 PM

Archived from groups: alt.comp.hardware.overclocking (More info?)

David Maynard <dNOTmayn@ev1.net> wrote:

> Mitch Crane wrote:
>> And they aren't always incompatible either. For example, Prime95 may
>> use some programming methodolgy which executes what Windows thinks is
>> data in a perfectly safe and known way--it knows what it's doing even
>> if Windows doesn't--,
>
> You miss the point. Prime may know it's 'safe' but if DEP is forced to
> allow Prime to do peculiar things then it must allow all programs to
> do those peculiar things and the next program may NOT be 'safe'.

Actually, I covered that point later in my post.

> Unless you have the unreasonable expectation that Microsoft will write
> a specific exclusion for the one program called 'Prime' (did anyone
> ASK then to? How would they even know?) and deny the others.

Firewalls have exclusions, for example.

>> because speed is of prime (no pun intended)
>> importance. Your firewall may block certain network operations,
>> because they can be dangerous, but it doesn't block them all. The
>> fact that an app access the net doesn't make that a bad app.
>
> Poor example because you're talking about a normal mode of operation.
> Put it in the DEP context where your 'Prime' program wants to fiddle
> directly with the TCP/IP stack and hack buffers... in a perfectly
> 'safe' manner of course. And then Mr. Hacker comes along and does the
> same thing except his 'purpose' isn't for 'speed or efficiency'.

So app B is bad, which still in no way makes app A bad.

>>>>That doesn't make such an application necessarily dangerous or bad.
>>>
>>>The application itself may not be malicious but if it depends on a
>>>methodology that necessitates bypassing a system's security features
>>>then it *is* 'dangerous and bad'.

No more so than when one occasionally has to tell NAV to allow a script
to run for an installation or poke a hole in a filrewall.

>> Not neccesarily. Is there and danger of Prime95 being exploited by
>> some third-party to execute data and comprimise the system? I've
>> seen no evidence of this.

>> Windows' DEP is a blanket general protection scheme
>> for to cover unknown bad apps. There are a lot of exploitable apps
>> out there--probably in no small part due to MS compilers. This scheme
>> was cooked up to cover those, but it gets some perfectly safe apps in
>> the process.
>
> You can attribute 'bad code' to anything you like but it's irrelevant.
> One can intentionally write 'bad code' as well and there's no way for
> DEP to know 'why' someone wrote code that's doing funky dunky things
> it shouldn't be doing; be it a compiler 'woops', a hacker, or the
> 'speed & efficiency' wizard.

But the user can know and in this case he would know that there is
nothing wrong with Prime95 and should be able to allow it to run.

>> One might argue that networking in general is dangeraous, as that's
>> the major path viruses and worms use to infect large numbers of
>> computers, but we don't disable all networking in XP, because that
>> would break a lot of useful and not dangerous apps and would be
>> unacceptable to most users. DEP, on the other hand, doesn't break
>> that much. If a few babies get thrown out with the bath water MS
>> doesn't really care.
>
> Inappropriate analogy. You compare removing entirely a vital
> capability, I.E. 'disable all networking', to simply having a program
> obey proper O.S. coding rules. There's nothing in DEP that prevents
> Prime from working, if it does so properly, and the proper analogy is
> that Prime obeying DEP 'rules' is equivalent to a firewall on that
> internet connection. It may not be quite as 'speedy or efficient', and
> it sure as heck isn't as convenient, but it's vital to system
> security.

As far as I can tell it obeys the rules and works properly. I made the
point that disabling all networking would be stupid and unacceptable. The
point of the analogy is that security features need to allow for
exceptions.

>> Back to your firewall example. If your contention is that the danger
>> comes in having to turn off DEP for all apps then my contention is
>> that DEP is broken. Just as your firewall would be broken if you had
>> to turn it completely off in order to surf the web.
>
> How is Windows to know, without so much as a hint, that 'Prime' is so
> privileged it's to be allowed O.S. level access? And how is it to know
> that this, lord knows where it came from, program is allowed but no
> others are?

We aren't talking about OS level access. The same way something like Zone
Alarm knows to allow your email client to run.

> The answer is: it can't. And if you allow Prime to wander unimpeded
> through system memory then you have to allow all the others too.

The DEP is bad, not Prime95.

> Again, your firewall analogy doesn't hold. A more appropriate analogy
> would be a firewall that allows just any old program to open any port
> it feels like any time it feels like it because the 'safe' program you
> write wants to do so for 'speed or efficiency'.
>
> I'm not concerned with the 'safe' program' It's the doors you want
> left open simply for that program's convenience. Of course, the next
> guy with a 'safe' program wants a different door left open. And the
> third guy...

Does a firewall allow all traffic to pass? No. It wouldn't be very useful
if it anly allow two options. Allow all traffic or none. That's why my
analogy is appropriate. Tat's the whole point.

>> I haven't touched the DEP settings in my PC and Prime95 works
>> perfectly well for me, however, so I'm not sure what the fuss is all
>> about.
>
> Probably something else entirely and I'm not saying DEP is the problem
> or that Prime is flawed. I'm just disagreeing with your assertion that
> DEP should allow just any old program that feels like it to romp
> through the system unimpeded. That defeats the whole concept.

Romping through the system unimpeded isn't what anyone is suggesting.
You're making a strawman argument. I don't want to allow just any old
program to become an open mail relay on my system, either, but I don't
argue that all TCP/IP functions are bad.
Anonymous
a b K Overclocking
January 16, 2005 4:42:50 AM

Archived from groups: alt.comp.hardware.overclocking (More info?)

Don Taylor wrote:

> David Maynard <dNOTmayn@ev1.net> writes:
>
>>Mitch Crane wrote:
>>
>>>David Maynard <dNOTmayn@ev1.net> wrote:
>>>
>>>>Mitch Crane wrote:
>>>>
>>>>>CoCo <cocotm@tele2.se> wrote:
>>>>>
>>>>>>(no program should trip dep ever)
>>>>>
>>>>>I don't think I would agree with that. There maybe applications where
>>>>>for reasons of speed or efficiency some method is used which trips
>>>>>DEP.
>>>>
>>>>"Speed and efficiency" are not always compatible with security. For
>>>>example, a firewall consumes resources but it's more secure than a
>>>>'speedy and efficient' open system.
>>>
>>>And they aren't always incompatible either. For example, Prime95 may use
>>>some programming methodolgy which executes what Windows thinks is data
>>>in a perfectly safe and known way--it knows what it's doing even if
>>>Windows doesn't--,
>
>
>>You miss the point. Prime may know it's 'safe' but if DEP is forced to
>>allow Prime to do peculiar things then it must allow all programs to do
>>those peculiar things and the next program may NOT be 'safe'.
>
>
> Perhaps I'm confused, but Windows already has built in the feature to
> let you turn DEP on and off on a program by program basis. I do not
> find any documentation that says you must allow this to be done for
> all programs.
>
> From the help system, the first hit:
>
> "To turn Data Execution Prevention on or off for a program"
>
> Now to be brutally fair, it goes on to say:
>
> "If you turn off Data Execution Prevention (DEP) for a specific program,
> it might become vulnerable to attack."
>
>
>>Unless you have the unreasonable expectation that Microsoft will write a
>>specific exclusion for the one program called 'Prime' (did anyone ASK then
>>to? How would they even know?) and deny the others.
>
>
> Already been done, hasn't it?
>
>
>>How is Windows to know, without so much as a hint, that 'Prime' is so
>>privileged it's to be allowed O.S. level access? And how is it to know that
>>this, lord knows where it came from, program is allowed but no others are?
>
>
> Because you:
>
> You must be logged on as an administrator or a member of the
> Administrators group in order to complete this procedure. If your
> computer is connected to a network, network policy settings might
> also prevent you from completing this procedure.
>
> To open System Properties, click Start, click Control Panel, and
> then double-click System.
> Click the Advanced tab and, under Performance, click Settings.
> Click the Data Execution Prevention tab.
> In the Turn on DEP for all programs and services except those I
> select list, do one of the following:
>
> To turn off DEP for a program, select the check box next to the
> program name and click OK. (If the name of the program doesn't
> appear in the list, click Add, navigate to your Program Files
> folder, select the program's executable file which will have an
> .exe file extension, and click OK).
>
> To turn on DEP for a program, clear the check box next to the
> program name, and then click OK.
>
>
>>The answer is: it can't. And if you allow Prime to wander unimpeded through
>>system memory then you have to allow all the others too.
>
>
> No
>
>
>>Again, your firewall analogy doesn't hold. A more appropriate analogy would
>>be a firewall that allows just any old program to open any port it feels
>>like any time it feels like it because the 'safe' program you write wants
>>to do so for 'speed or efficiency'.
>
>
> No
>
>
>>I'm not concerned with the 'safe' program' It's the doors you want left
>>open simply for that program's convenience. Of course, the next guy with a
>>'safe' program wants a different door left open. And the third guy...
>
>
>>>I haven't touched the DEP settings in my PC and Prime95 works perfectly
>>>well for me, however, so I'm not sure what the fuss is all about.
>
>
>>Probably something else entirely and I'm not saying DEP is the problem or
>>that Prime is flawed. I'm just disagreeing with your assertion that DEP
>>should allow just any old program that feels like it to romp through the
>>system unimpeded. That defeats the whole concept.
>
>
> I don't think anybody said "any old program should go romping" but
> I also don't think I understand the DEP to be all or nothing as you
> seem to have found it to be.

Well, I was discussing it based on the theoretical premise presented.

The current implementation has a number of practical considerations because
it's 'new' and that means some programs trigger DEP because they were
written not knowing there would *be* a 'DEP'; so Microsoft provides the
ability to turn DEP off for them. That doesn't change the basic theory,
however. You're increasing risk by doing so and, eventually, the 'turn it
off for' option should become unnecessary as the new versions come into
compliance.

However, the 'per program' ability only allows *that* program's memory to
be 'misused'. O.S. program/data areas are still protected, unless you turn
DEP off entirely.

But the basic point remains. If a program is triggering DEP then it's not
performing properly under the new rules and it is the offending program
that needs to be changed, not DEP; a temporary 'fix' to turn DEP off for it
notwithstanding.

The ability to turn DEP off for a program is an unfortunate, hopefully
temporary, development and not the way, as Mitch is suggesting, it *should*
work.

And that is what I was arguing: the should vs shouldn't (not the 'temporary').
Anonymous
a b K Overclocking
January 16, 2005 11:20:23 AM

Archived from groups: alt.comp.hardware.overclocking (More info?)

David Maynard <dNOTmayn@ev1.net> wrote in
news:10uk6nrh7f94b94@corp.supernews.com:

>> I don't think anybody said "any old program should go romping" but
>> I also don't think I understand the DEP to be all or nothing as you
>> seem to have found it to be.
>
> Well, I was discussing it based on the theoretical premise presented.

The only person who presented an all or nothing premise was you. You
assumed from the start that allowing one app to run unimpeded would have
to allow all apps to do so.

> However, the 'per program' ability only allows *that* program's memory
> to be 'misused'. O.S. program/data areas are still protected, unless
> you turn DEP off entirely.

Which is why I explained to you that DEP wasn't preventing "OS level"
access.

> But the basic point remains. If a program is triggering DEP then it's
> not performing properly under the new rules and it is the offending
> program that needs to be changed, not DEP; a temporary 'fix' to turn
> DEP off for it notwithstanding.

If the OS prevents an app from running then it's a given that the app
will have to change. That doesn't mean the app is doing anything unsafe.
It just means it won't run anymore.

> The ability to turn DEP off for a program is an unfortunate, hopefully
> temporary, development and not the way, as Mitch is suggesting, it
> *should* work.

The inability to turn if off would have been unfortunate. That why you
can turn it off... fortunately.

> And that is what I was arguing: the should vs shouldn't (not the
> 'temporary').

Actually, you were making up arguments about allowing programs to romp
through memory at will and turn off DEP of their own volition, in
addition to your mistaken belief that allowing one app to run would force
DEP to be completely turned off.
Anonymous
a b K Overclocking
January 16, 2005 11:20:24 AM

Archived from groups: alt.comp.hardware.overclocking (More info?)

Mitch Crane wrote:

> David Maynard <dNOTmayn@ev1.net> wrote in
> news:10uk6nrh7f94b94@corp.supernews.com:
>
>
>>>I don't think anybody said "any old program should go romping" but
>>>I also don't think I understand the DEP to be all or nothing as you
>>>seem to have found it to be.
>>
>>Well, I was discussing it based on the theoretical premise presented.
>
>
> The only person who presented an all or nothing premise was you. You
> assumed from the start that allowing one app to run unimpeded would have
> to allow all apps to do so.

And it does allow any app to do so.

You seem to be arguing that the user doesn't have to do that but the point
I was making isn't that the O.S. automatically 'enables' it for all apps
but that it has to *allow* it. I.E. the user can do it for any and all apps
because it is *allowed* for any and all apps.


>>However, the 'per program' ability only allows *that* program's memory
>>to be 'misused'. O.S. program/data areas are still protected, unless
>>you turn DEP off entirely.
>
>
> Which is why I explained to you that DEP wasn't preventing "OS level"
> access.

It *is* OS level access because you've replaced the OS memory allocation
and protection function with a user program, and OS files still being
protected doesn't alter that.

Just as a driver not being able to diddle around in the task scheduler
doesn't remove it from being OS level.


>>But the basic point remains. If a program is triggering DEP then it's
>>not performing properly under the new rules and it is the offending
>>program that needs to be changed, not DEP; a temporary 'fix' to turn
>>DEP off for it notwithstanding.
>
>
> If the OS prevents an app from running then it's a given that the app
> will have to change.

Not necessarily. It could be an O.S. 'bug' (as if MS never had one of
those) and you seem to be claiming that DEP itself is a 'bug'.

You must also be irate that the O.S. doesn't allow user programs to access
the hardware directly.

> That doesn't mean the app is doing anything unsafe.

You keep saying that and I keep telling you it isn't 'that' app being
'safe' that's the issue. Although your blind faith that Prime could never
ever have a bug is amusing.

> It just means it won't run anymore.
>
>
>>The ability to turn DEP off for a program is an unfortunate, hopefully
>>temporary, development and not the way, as Mitch is suggesting, it
>>*should* work.
>
>
> The inability to turn if off would have been unfortunate. That why you
> can turn it off... fortunately.

Only in the Windows world would someone argue that defeating memory
protection is a 'fortunate' thing.


>>And that is what I was arguing: the should vs shouldn't (not the
>>'temporary').
>
>
> Actually, you were making up arguments about allowing programs to romp
> through memory at will and turn off DEP of their own volition, in
> addition to your mistaken belief that allowing one app to run would force
> DEP to be completely turned off.

No, but it doesn't seem to matter what I say because the only thing you
care about is having your pet program run and to hell with anything else.

The ability to turn DEP off for a program *does* open the door to all
programs because you can turn it off for any program, or all programs, or
off entirely (although that takes some work). And just as you don't give a
tinker's dam about DEP if your cute program doesn't like it the next person
will turn DEP off for their cute little program and so on. Or, as it seems
most folks are doing, just turn it off for all programs because that's a
lot easier than entering exclusions.
Anonymous
a b K Overclocking
January 16, 2005 4:27:05 PM

Archived from groups: alt.comp.hardware.overclocking (More info?)

As politely as I can possibly suggest this... it really looks
like there is no way to find an agreement on this subject.

Now, fully accepting your position on this, I'll ask a question
about prime95, to try to make sure I don't waste lots of cycles.

If I set up multiple machines to run the linux version of prime95,
mprime239, and I don't take any part in group factoring work, I'm
just using it as a factoring engine for a project of my own,
and I manually fill worktodo.ini on every machine with the same
ECM=11213,1000000,0,1800,0,0,1,0
(which is elliptic curve factoring of 2^11213+1 for 1800 curves,
that last 1, rather than 0, says to factor +1 instead of -1)

am I correct in my understanding that every machine is randomly
generating curves to try to find a factor, so that running multiple
machines will reduce the factoring time?

A slightly different item, under XP I've seen prime95 seem to not
correctly restart if I turn the power off and later boot the
machine. I have seen it run one curve and then go idle. This
doesn't seem to be because the progress files are corrupted.
It might be because I have manually appended to the worktodo.ini
file while prime95 was running, but not actively reading the work
file, but that is just a guess on my part. I had assumed it would
re-read worktodo.ini each time it needed more work. It isn't
clear why it doesn't correctly restart work for me every time.

Thank you for your consideration
Anonymous
a b K Overclocking
January 16, 2005 8:52:12 PM

Archived from groups: alt.comp.hardware.overclocking (More info?)

David Maynard <dNOTmayn@ev1.net> wrote in
news:10ukculf1ugmi36@corp.supernews.com:

> Mitch Crane wrote:
>
>> The only person who presented an all or nothing premise was you. You
>> assumed from the start that allowing one app to run unimpeded would
>> have to allow all apps to do so.
>
> And it does allow any app to do so.

No, it allows administrators to allow any app to do so without allow all
apps to do so.

> You seem to be arguing that the user doesn't have to do that but the
> point I was making isn't that the O.S. automatically 'enables' it for
> all apps but that it has to *allow* it. I.E. the user can do it for
> any and all apps because it is *allowed* for any and all apps.

Of course it allows users to allow it. This is no more dangerous (and, in
fact, probably a lot les dangerous) than allowing users to install
software or open email attachments.

>>>However, the 'per program' ability only allows *that* program's
>>>memory to be 'misused'. O.S. program/data areas are still protected,
>>>unless you turn DEP off entirely.
>>
>>
>> Which is why I explained to you that DEP wasn't preventing "OS level"
>> access.
>
> It *is* OS level access because you've replaced the OS memory
> allocation and protection function with a user program, and OS files
> still being protected doesn't alter that.

No, I haven't replaced the OS level memory allocation and protection with
a user program. Now you're just being silly. The user program isn't going
to do anything different other than not crash. The only thing doing
anything on an OS level is the OS because it's the OS which is changing
it's behavior at the user's request. The data being manipulated is owned
by the app and apps have always been free to access their own space.

> Just as a driver not being able to diddle around in the task scheduler
> doesn't remove it from being OS level.

Another strawman bites the dust. If something works at "OS level" DEP has
nothing to do with it.

>> If the OS prevents an app from running then it's a given that the app
>> will have to change.
>
> Not necessarily. It could be an O.S. 'bug' (as if MS never had one of
> those) and you seem to be claiming that DEP itself is a 'bug'.

We weren't talking about a bug. We were talking about the OS preventing
an app from running through DEP (or other security 'features'). You knew
that, of course, you're just grasping at straws now.

> You must also be irate that the O.S. doesn't allow user programs to
> access the hardware directly.

No. Why should I be? That's inherently dangerous since that hardware is
shared by everything in the system. An apps memory space isn't.

>> That doesn't mean the app is doing anything unsafe.
>
> You keep saying that and I keep telling you it isn't 'that' app being
> 'safe' that's the issue. Although your blind faith that Prime could
> never ever have a bug is amusing.

Any app could have a bug. Anything I install could damage the system. You
unnatural fear of DE is what's amusing.

>> The inability to turn if off would have been unfortunate. That why
>> you can turn it off... fortunately.
>
> Only in the Windows world would someone argue that defeating memory
> protection is a 'fortunate' thing.

It isn't memory protection. Only on Usenet would some argue so vehemently
something of which he completely fails to understand.

>>>And that is what I was arguing: the should vs shouldn't (not the
>>>'temporary').
>>
>> Actually, you were making up arguments about allowing programs to
>> romp through memory at will and turn off DEP of their own volition,
>> in addition to your mistaken belief that allowing one app to run
>> would force DEP to be completely turned off.
>
> No, but it doesn't seem to matter what I say because the only thing
> you care about is having your pet program run and to hell with
> anything else.

It doesn't matter what you say when you are making up positions to agrue
against, actually.

> The ability to turn DEP off for a program *does* open the door to all
> programs because you can turn it off for any program, or all programs,
> or off entirely (although that takes some work). And just as you don't
> give a tinker's dam about DEP if your cute program doesn't like it the
> next person will turn DEP off for their cute little program and so on.
> Or, as it seems most folks are doing, just turn it off for all
> programs because that's a lot easier than entering exclusions.

Just as they can turn off or poke holes in their firewall, install
applications and open attachments. That's just the way it is. Maybe you'd
rather that all of those dangerous things be disallowed. They are all
certainly more dangerous than allowing a user to turn off DEP for a given
app. Especially since most users will probably never touch the DEP
settings. If it ever comes to the point where many users are turning DEP
off then obviously it's broken.
!