Quote:
Originally Posted by WernherVonTrapp
...On the other hand, they claim that they haven't noticed any improvements or enhancements to their Windows system either. You have just reinforced this with your own claim.
|
Not so fast. I have had an improvement: After the NTCore patch, SH4 doesn't crash nearly as much as it once did. Hardly ever, in fact.
Quote:
Originally Posted by WernherVonTrapp
From what I've read, and I'm not an expert mind you, you cannot allow a 32 bit program to use 4GB of memory (on a 32 or 64 bit system), without altering the Windows Kernel. It's not possible, from what I dug up.
|
That's not what the article you linked says.
Quote:
Originally Posted by WernherVonTrapp
Any time you mess with the Windows Kernel, you potentially open up your system to an exploit or hack. Hacks occur every day without the PC users ever knowing that it took place. That's one of the reasons why it's called hacking.
|
Any time you step outside, you potentially open yourself up to having a grand piano land on your head.
That doesn't mean it's reasonable to worry about it, especially when the thing (changes to the Windows kernel) isn't even happening.
This line of thought is a dead end.
Quote:
Originally Posted by WernherVonTrapp
... Now, from what I can decipher, he mentions "call tos" or other references that sound like he's using or fooling the Windows Kernel. That, in essence, is an alteration of the original Kernel. Maybe I'm misunderstanding this but check it out for yourself:
http://www.ntcore.com/files/vista_x64.htm
|
There is not a single use of the term "call to" in that article.
Using features of the system as intended is not "altering" the kernel. You apparently skipped the section on Patch Guard. Go back and read it, and perhaps you'll understand.
Another part you must have skipped, under the "Windows on Windows" heading:
Quote:
...32bit applications have a maximal 2GB space (4GB if explicitly required) and the rest of the space is handled by the system. This doesn't change much of course, since on x86 user mode applications had 2GB of virtual memory space out of 4GB (the other 2GB were reserved for kernel mode). On x64 these two other GB can now be accessed by 32bit applications. In order to achieve this, the IMAGE_FILE_LARGE_ADDRESS_AWARE flag has to be set in the File Header's Characteristics field. You can do this programmatically or manually with a normal PE editor like the CFF Explorer, just like this: (example truncated)
|
So we see it is entirely possible to let a 32-bit app access more than 2 GB RAM without "hacking" or in any way altering the Windows kernel. Even if it did try, Patch Guard would probably stop it.
I have seen no evidence that the NTCore 4GB patch does anything that could reasonably be regarded as harmful. The plural of anecdote is not "data."
Rather, the NTCore patch simply keeps SH4 from crashing where it once crashed constantly, regardless of whether SH4 uses more than 2 GB RAM. That is good enough for me.
No insult perceived or intended - I just think you are worrying needlessly, and perpetuating conclusions not supported by the facts.