Erhm, but no. And it's not about performance issues either. Or NTkernel...

Have a look in this thread, post 14 and 15: http://www.subsim.com/radioroom/showthread.php?t=177503

SH4 can max. address 1.65 GB. Trying for more = CTD (as loading OM Museum).
A patched SH4.exe loads OM Museum fine and use 2.21GB...

A noticable find is that the memory overhead in SH4 is actually very small, 80-160MB, which you don't need that much traffic to use.
And I've feedbacks from many users that confirms their SH4 doesn't crash anymore after applying the patch.


The LAA-patching simply allows a 32-bit program to be aware of memory above the 2GB barrier. The patching itself is only a bit being set to "1" in SH4.exe

"This is an application that assists in making applications large address aware. When a 32-bit application is Large Address Aware, it can access up to 4 GiB on x64 operating systems and up to 3 GiB on x86." Source: http://www.techpowerup.com/forums/sh...d.php?t=112556

Well, then, maybe I am missing something here, if trying to get Windows to utilize it's full 4GB of memory (instead of just having it display 4GB) is not a performance issue. If the patch actually does stop SHIV from crashing, isn't that an improvement in performance to some degree? I understood what the programmer meant when he spoke of "Large Address Awareness". As far as the Kernel is concerned, that word pops up quite a bit on that web page, and I didn't only rely on the info found on his page. I was checking other similar apps and Microsoft's own website.
My reference to the Placebo Effect was an inference drawn upon the many users (in my searching) who claimed that they had the patch installed but didn't see any effect, improvements or enhancements to their gaming. In fact, many never checked their systems or had them benchmarked to compare the before/after effect on their PC. To me, that's tantamount to a placebo effect.
If one wants to install the patch blindly, that's their prerogative. I refer to the closing in my original reply, "The whole point to this is that one should thoroughly research any patches to be installed in their PC and hopefully, no one installs it simply on the strength of an unknown who posted the patch."
There was no malice intended in wanting users to beware of a patch that involved, from my searching, some serious questions.

Post Script: I knew I should've posted link references but there were so many and I was too lazy, and I thought that would've been too presumptuous.:nope:

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.

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.

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:
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.

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.:up:



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.:D
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.

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.

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.:D
(chuckle) God, I hate debates.http://www.freesmileys.org/smileys/smiley-gen115.gif

No problem. Certainly, you did get me to look deeper into the matter. We simply differ on the conclusions.

The only reason I researched it in the first place is, after reading your first post regarding the patch I thought, if it could improve my own gaming experience, I might use the patch myself. So, I began researching it before installing it. What I found was that there were some serious questions that I couldn't find definitive answers for. Instead, I ended up with more questions than answers. I'm still not completely convinced that the patch doesn't alter (in some way, shape or form) the Windows Kernel. I concluded that I really don't need the patch and will not be installing it anytime soon. If answers to my questions become more easily available in the future, I might reconsider.;)