BF2, 2142 and stalker vista -=FIX=-

[deceived]

This fix has stopped all stuttering in 2142 for me and memory errors

do this at your own risk, but i must tell you that i have done this to 5 computers, 3 with vista 64 and 2 with vista 32 from 2gb to 4gb system memory
and it rocks, no more crashing, no more low performance. NO MORE MEMORY.DLL ISSUES

for those with 2gb do this first
click on start, then right click in computer, select properties, once the window is open click on advenced system settings, system properties is now open, click on the advance tab, under performance click on settings, then in visual effects press adjust for best performance, press apply,u should see a big change in your UI now, before closing tht we are going to set some visual effects that does not use many memory and make more comfortable the use of windows, in the boxes select this visual effects only
show thumbails instead of icons
show translucent selection rectangle
smooth edges of screen fonts
use dropshadows for icon labels on the desktop
use visual style on windows and buttons

hit apply.
then go to advanced in tht same window, and you are going to change ur pagefile from system managed to custom set initial value to 3500, max size 3500
OK NOW THE FIX, PLEASE READ CAREFULLY!!!

(You'll need to be an Administrator)
First, you'll need to grab and install Visual Studio C++ Express from Microsoft.

It's free so don't worry.
http://msdn.microsoft.com/vstudio/ex...c/default.aspx
Once installed, you'll need to update it. also the game make sure u have lastest

patch installed

Backup the bf2.exe file. Just in case.
Start ->Visual C++ 2005 Express Edition ->Visual Studio Tools ->Visual Studio

2005 Command Prompt
Navigate to your battlefield 2 directory.
If you don't know how to navigate in DOS, follow this:
"cd c:\Program Files\" ENTER ***c:\Program Files (x86)\ ENTER in vista 64***
then usually it's "cd EA GAMES" ENTER
"cd Battlefield 2" ENTER

NOW WRITE THIS

editbin.exe /LARGEADDRESSAWARE BF2.exe hit ENTER. Should come up with a

Microsoft copyright or trademark thingy. This means success.
write exit and hit ENTER
RDY TO ROCK!!

now this fix works for most of the games, i have use it in BF2, BF2142, STALKER,

CNC3, COH

to know what file u have to modify u need to see wich one is using the memory

since sometimes it's not the (gamename.exe) for example in cnc3 its a file

called cnc3game.dat not cnc3.exe, and in stalker its one called XR_3da.exe

any questions post it!!!

source http://www.forumplanet.com/planetbat...92&tid=2038426

[Animatrix]

Somethings wrong here, setting the IMAGE_FILE_LARGE_ADDRESS_AWARE flag in the image header (exe) is not enough. You need to use the /3GB switch as well. Without the /3GB switch the address space is divided equally (2GB for process and 2GB for the OS). The /3GB switch do NOT expand the user-mode address space of all programs. Only programs marked as /LARGEADDRESSAWARE are affected.

Windows Internals Fourth Edition

x86 User Address Space Layouts

By default, each user process on the 32-bit version of Windows can have up to a 2-GB private address space; the operating system takes the remaining 2 GB. Windows 2000 Advanced Server, Windows 2000 Datacenter Server, Windows XP Service Pack 2 and later, and Windows Server 2003 (all versions) support a boot-time option (the /3GB switch in Boot.ini) that allows 3-GB user address spaces. Windows XP and Windows Server 2003 support an additional switch (/USERVA), which allows specifying a user address space size between 2 GB and 3 GB. (The value is in number of megabytes.)

The ability for a 32-bit process to grow beyond 2 GB was added as a short-term solution to accommodate the need for applications such as database servers to keep more data in memory than could be done with a 2-GB address space. The AWE functions described earlier in this chapter provide a much better solution to the need for accessing more data than can fit in the limited 2-GB (or 3-GB) process address space.

For a process to grow beyond 2 GB of address space, the image file must have the IMAGE_FILE_LARGE_ADDRESS_AWARE flag set in the image header. Otherwise, Windows reserves the additional address space for that process so that the application won't see virtual addresses greater than 0x7FFFFFFF. (This is to avoid breaking applications that might break with such addresses.) You set this flag by specifying the linker flag /LARGEADDRESSAWARE when building the executable. This flag has no effect when running the application on a system with a 2-GB user address space. (If you boot with /3GB in versions of Windows Server that do not support the /3GB switch, system space is reduced to 1 GB, but user processes are still limited to 2 GB, even if the large-address-space aware flag is set on an image that is run.)

http://www.microsoft.com/whdc/system...AE/PAEmem.mspx
The /3GB switch allocates 3 GB of virtual address space to an application that uses IMAGE_FILE_LARGE_ADDRESS_AWARE in the process header. This switch allows applications to address 1 GB of additional virtual address space above 2 GB.

The virtual address space of processes and applications is still limited to 2 GB, unless the /3GB switch is used in the Boot.ini file.

...

Executables that can use the 3-GB address space are required to have the bit IMAGE_FILE_LARGE_ADDRESS_AWARE set in their image header. If you are the developer of the executable, you can specify a linker flag (/LARGEADDRESSAWARE).

To set this bit, you must use Microsoft Visual Studio Version 6.0 or later and the Editbin.exe utility, which has the ability to modify the image header (/LARGEADDRESSAWARE) flag. For more information on setting this flag, see the Microsoft Visual Studio documentation.

It should also be noted that it may not be as easy as just marking a program /LARGEADDRESSAWARE, not all software may work (assumptions made about virtual addresses).

http://blogs.msdn.com/oldnewthing/ar...12/213468.aspx
Myth: The /3GB switch expands the user-mode address space of all programs

Only programs marked as /LARGEADDRESSAWARE are affected.

For compatibility reasons, only programs that explicitly indicate that they are prepared to handle a virtual address space larger than 2GB will get the larger virtual address space. Unmarked programs get the normal 2GB virtual address space, and the address space between 2GB and 3GB goes unused.

Why?

Because far too many programs assume that the high bit of user-mode virtual addresses is always clear, often unwittingly. MSDN has a page listing some of the ways programs make this assumption. One such assumption you may be making is taking the midpoint between two pointers by using the formula (a+b)/2. As I noted in a previous exercise, this is subject to integer overflow and consequently can result in an erroneous pointer computation. Consequently, you can't just take an existing program that you didn't write, mark it /LARGEADDRESSAWARE, and declare your job done. You have to check with the authors of that program that they verified that their code does not make any 2GB assumptions. (And the fact that the authors didn't mark their program as 3GB-compatible strongly suggests that no such verification has occurred. If it had, they would have marked the program /LARGEADDRESSAWARE!)

Marking your program /LARGEADDRESSAWARE indicates to the operating system, "Go ahead and give this program access to that extra gigabyte of user-mode address space," and as a result, addresses in the third gigabyte become possible return values from memory allocation functions. If you set the "Top down" flag in the memory manager allocation preferences mask (search for "top down"), you can instruct the memory manager to allocate high-address memory first, thereby forcing your program to deal with those addresses sooner than it normally would. This is very handy when testing your program in a /3GB configuration since it forces the troublesome memory addresses to be used sooner than normal.

64-bit and 32-bit

http://blogs.msdn.com/oldnewthing/ar...01/423817.aspx
Using /LARGEADDRESSAWARE on 64-bit Windows for 32-bit programs

Probably the biggest advantage of 64-bit Windows is not the larger registers but rather the expansive 64-bit address space. Recall that even when the /3GB switch is set, 32-bit programs receive only 2GB of address space unless they indicate their willingness to cope with addresses above 2GB by passing the /LARGEADDRESSAWARE flag.

This flag means the same thing on 64-bit Windows. But since 64-bit Windows has a much larger address space available to it, it can afford to give the 32-bit Windows program the entire 4GB of address space to use. This is mentioned almost incidentally in Knowledge Base article Q889654 in the table "Comparison of memory and CPU limits in the 32-bit and 64-bit versions of Windows".

In other words, certain categories of 32-bit programs (namely, those tight on address space) benefit from running on 64-bit Windows machine, even though they aren't explicitly taking advantage of any 64-bit features.

[deceived]

I get most of what your saying in there i understand large addresses in a 32bit system and virtually addressed ram, but i tried it my memory errors ceased and the jerkiness in games cleared up. and its easily reversed as long as you make a backup of the exe in question.