[WernherVonTrapp]

Originally Posted by WH4K

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.



That's not what the article you linked says.

I never said that particular article did. I was referring to other forums where other users of the 4GB patch, (as well as other similar apps), didn't notice, well, anything that would indicate they even installed a patch. Many said they never even bothered to check. I reiterate, it was not directed toward you. It was directed against installing patches w/o researching them first.

Originally Posted by WH4K

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.

Where did that comparison come from? Of course that line of thought is a dead end, falling pianos and PC patches are as far from each other as East from West.

Originally Posted by WH4K

There is not a single use of the term "call to" in that article.

No, the exact words "Call To" are not. Here is a paragraph from that page referencing those call functions:
And now, the most important things. Calling convention and stack. x64 assembly uses FASTCALLs as calling convention, meaning it uses registers to pass the first 4 parameters (and then the stack). Thus, the stack frame is made of: the stack parameters, the registers parameters, the return address (which I remind you is a qword) and the local variables. The first parameter is the rcx register, the second one rdx, the third r8 and the fourth r9. Saying that the parameters registers are part of the stack frame, makes it also clear that any function that calls another child function has to initialize the stack providing space for these four registers, even if the parameters passed to the child function are less than four. The initialization of the stack pointer is done only in the prologue of a function, it has to be large enough to hold all the arguments passed to child functions and it's always a duty of the caller to clean the stack. Now, the most important thing to understand how the space is provided in the stack frame is that the stack has to be 16-byte aligned. In fact, the return address has to be aligned to 16 bytes. So, the stack space will always be something like 16n + 8, where n depends on the number of parameters. Here's a small figure of a stack frame:

These are some of the "call to" functions that I was referring to. But what does that have to do with any of this? Your misunderstanding about what I was referring to, or how it was spelled is moot point. Look, I'm not going to get involved in a tit-for-tat over using a descriptive term that I never said was written in that exact way on that page. I said he mentions "call tos" and the "calls" in that paragraph are just that. Calling to another file, .dll, kernel or whatever.

Originally Posted by WH4K

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:
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 skipped a lot of parts because I didn't even reference his site in my original post. It wasn't humanly possible for me to remember verbatim all the information from all the sites I referenced. I'm not going to sit here and try to force it down your throat as far as whether his particular app alters (in any way) the windows Kernel. I was referring to other similar apps that do and just trying to give anyone the heads-up in making sure a patch to be installed doesn't do so in one way or another. I was under the impression, from one or more sites I visited, that getting Windows to use 4GB on a 32 bit app wasn't possible w/o altering the kernel in one way or another. Do you know for a fact that it doesn't? Then, that's fine. If you don't, I would make sure before using the patch, that's all I was saying.

Originally Posted by WH4K

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.

I never said that the 4GB patch was harmful. I said that it "may" pose a risk for hacks or exploits if the Windows kernel is altered. May means (it might, it could). I said that one should make sure first because I saw some questionable references regarding other similar apps. So, now you have thoroughly researched it and that was all I was trying to say in the first place. And yes, I've always been a worrier by nature.
(chuckle) God, I hate debates.