New
#131
Let me repeat what I said before: You cannot program your application to actually use the page file. There is no API to do so. That is my point.The opposite actually.
Many applications, and some games, expect it to be there.
There can be bugs, and then there can be programmers that might be frighten that their applications run out of memory, if there is not configured one. That is something else.
And then there are all the rumours. How often have I not seen the argument that photoshop cannot run without a page file.
Perhaps that demonstrates my ignorance of programming - since I made a career supporting hardware AND avoiding programming with utmost earnest, I make no apologies for that. My comment still illustrates my point that neither you nor I know the numbers. And regardless the reason why, or the technical process, the fact remains, there are programs (as shown with previously posted links) that expect to find a PF and fail to work properly when one is not found. It's been said many times before, and Wishmaster just reiterated it.I think the big number came from when you said that I couldn't possible know how the many, many applications out there were programmed to use or not use the page file.
See, there you go again, and your twisting of words is to the point where I think it rude. I "drew the badge-card" but in the same draw I explained how the gurus are not so arrogant as to expect readers will automatically accept their words as "The Gospel". So they provide corroborating evidence.You drew the badge-card and said that when the gurus have spoken then it must be true.
But also, I asked earlier if you have been following this thread - clearly you have not. You engaged me in this thread here. My argument has been all along that there is no benefit to disabling the Page File, not how memory is used.
I don't care how Windows was coded to use a page file. Users don't need to know how Windows was coded to use a page file. Users just need to know what to do with it.
And the answer for the vast majority of the nearly 1 billion Windows users out there is to just let Windows manage it. If you know what you are doing and take the time to properly analyze the results, then setting a fixed size, especially when low on free disk space, may be appropriate. But there is no published evidence to be found that even suggests disabling the page file provides any benefit. And there is nothing, no white paper, KB article, review site that recommends disabling the page file.
I'm only here to say, don't disable the page file. Disabling the PF provides no benefit. Disabling the PF will result in lost memory dumps - often valuable for troubleshooting. It may result in "low memory" errors and may prevent some programs expecting to find a PF from installing or running properly.
We are back to the need-part. If you have a bugged application for which there are no bugfixes - then you have a need for it.the fact remains, there are programs (as shown with previously posted links) that expect to find a PF and fail to work properly when one is not found. It's been said many times before, and Wishmaster just reiterated it.
What about the telnet-service? I can argue that it must never be disabled, because there exist programs that cannot work without it.
Is still a valid point.How can they know what his needs are?
I don't doubt that there are programs that will give you the "out of physical memory" errors. Should my machine experience that, I'd just activate the page file, but have not had the need for it as of yet.
I am curious now and maybe my knowledge in this area should be refreshed...
Windows present memory to the application as a single continuous memory space that is available for the app in question. This memory space is made up from physical and virtual memory. The application in itself has no knowledge of the type of actual memory it has received from the operating system. In which case, what difference does it make the type of memory that is available for Windows to manage?
As long as the app is asking for memory that Windows can assign, there should be no issue. If there's not enough memory, then the end user can have a choice. Enable the page file and/or increase the size of the physical memory.
Some applications may check the size of physical memory and request the same from the OS. In which when the page file is disabled, it'll give the out of memory error.
Again, I am curious now and not trying to fan the flames...
Thank you! You just proved my point again. Since we as tech support providers do not know the needs of the posters, it is bad advice to tell a user to disable his page file - because, ONCE AGAIN, there is no benefit in doing so.pallesenw said:
As we are all ware, a 32 bit application only gets 2GB of address space.
I too was under the assumption that that consisted of Physical and Virtual memory.
But through the course of this, I too am left questioning:
Why do some applications crash, or refuse to run if a PF is not present?
Even if theres plenty of physical memory?
Perhaps, when a application (such as in my example) starts hitting its 2GB limit in physical memory, it starts paging it out. Effectively giving the app more space.
This was just a thought, and Im looking for a definitive answer myself.
I did think address space was Physical + Virtual.
For the record, I too have experimented with no PF at all. And for the most part, everything seemed OK. But I did run into a few issues, and have since just left it on. IMHO, there as really nothing gained from it being off.
Unless of course compiled with the LARGEADDRESSAWARE linker flag. Then it has access to a 3GB process space (VA) if the system is configured for it, and all 4GB of WOW64 address space on an x64 system if compiled LARGEADDRESSAWARE (no flags need to be set on an x64 OS for this to happen either - it is native to WOW64 to do this as there is no kernel space for a 32bit kernel on a 64bit OS, hence all 4GB of VA are available to a 32bit process in WOW64 if compiled LARGEADDRESSAWARE).
Right, virtual address space and RAM have nothing at all to do with one another, other than the memory manager is responsible for mapping VA pages into physical pages, or into PF allocations, or both (depending on how the allocation is made from the application).
Because, as mentioned previously, there *are* allocation function flags that will physically back a page in memory with a page in the paging file (mapping views of files, for example, come to mind right away). If the application makes one of these API calls, and there's no PF, you get a failed allocation. If the app doesn't handle this / allow this properly or at all, then you get a second chance exception, and an app crash (and that may actually be the desired behavior as well).
A 32bit application would simply start throwing out of memory errors, even when on WOW64. The app only get the allotted VA, and if / when the app starts to get into alloc failures of VA, it will start hitting that out of memory condition. How it handles it, of course, is up to the app, but most don't handle it well for sure.
Not true. There are no such flags. This again are just rumours floating around.Because, as mentioned previously, there *are* allocation function flags that will physically back a page in memory with a page in the paging file (mapping views of files, for example, come to mind right away). If the application makes one of these API calls, and there's no PF, you get a failed allocation. If the app doesn't handle this / allow this properly or at all, then you get a second chance exception, and an app crash (and that may actually be the desired behavior as well).
If you read carefully what Mark Russinovich has to say about the allocation functions, he too will telll you that it is not true. Those page file-backed sections do NOT need a page file. The name just confuses many people.