Re: Wine memory limitation for malloc?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



mikolajz wrote:
> There are apps that won't work if there is more than 2GB memory (e.g. they may treat this value as signed and fail to start informing the user that it requires at least 16MB of RAM on a computer with 3GB RAM). That's why Microsoft introduced a header flag that allows the developer to mark the executable as able to handle such an amount of memory. Wine also implements this behaviour. When compiling the program with Visual C, you should try the linker option /LARGEADDRESSAWARE:YES . AFAIK this puts that flag in the header.
> 
> As it was said, on 32-bit Windows, in the default configuration, this flag won't change anything as the high 2GB of address space is reserved for the system (and it's not possible to allocate more memory with malloc than the available address space). It's possible to make 3GB of address space available to the application with the /3gb switch in boot.ini. AFAIR, the 3GB address space is the default on Linux and may be even increased by distributions. On 64-bit Windows and Linux, the whole 4GB of address space will be visible to applicaitons with such a flag.
> 
> I may also add that this problem is different than the problem addressed by the PAE. The PAE allows to give more than 4GB of physical memory to all the processes in the system. The problem here is how much of the address space is available to a single process.


It's great idea!
Test program:
#include <stdlib.h>
#include <stdio.h>
#include <time.h>
main(int argc, char **argv)
{unsigned long n,m,N,i; int *p,*p1,*p2,*p3; clock_t time1,time2;
i=4095; if (argc == 2) i = (size_t) strtoul(argv[1], NULL, 0); n=0; N=0;
m=i*1024*1024; while(  (p=(int*)malloc(m)) ==0 ) m-=1024l*1024l;
printf("Allocated %u MB  ( %u bytes )\n",m/1024l/1024l,m); n=m; N=m;
m=i*1024*1024; while(  (p1=(int*)malloc(m)) ==0 ) m-=1024l*1024l;
printf("Allocated %u MB  ( %u bytes )\n",m/1024l/1024l,m); N+=m;
m=i*1024*1024; while(  (p2=(int*)malloc(m)) ==0 ) m-=1024l*1024l;
printf("Allocated %u MB  ( %u bytes )\n",m/1024l/1024l,m); N+=m;
m=i*1024*1024; while(  (p3=(int*)malloc(m)) ==0 ) m-=1024l*1024l;
printf("Allocated %u MB  ( %u bytes )\n",m/1024l/1024l,m); N+=m;
printf("Total allocated %u MB  ( %u bytes )\n",N/1024l/1024l,m);
}

Results:
Computer: Core 2Duo, 4GB physical memory.
OS - openSUSE 11 x64.

Win32 console application compiled _without_  linker option /LARGEADDRESSAWARE. Visual C 6.0
Allocated 1529 MB
Allocated 439 MB
Allocated 45 MB
Allocated 15 MB
Total allocated 2028 MB

Win32 console application compiled with  linker option /LARGEADDRESSAWARE. Visual C 6.0
Allocated 1529 MB
Allocated 1024 MB
Allocated 439 MB
Allocated 45 MB
Total allocated 3037 MB

Linux 32-bit application compiled gcc with  option -m32
Allocated 3836 MB
Allocated 128 MB
Allocated 123 MB
Allocated 4 MB
Total allocated 4091 MB

Good option /LARGEADDRESSAWARE, but 1GB unused :(

Quote from wine sources. File vxd.c:
>>        /*
>>         * Note: Win32s reserves 0GB - 2GB for Win 3.1 and uses 2GB -  4GB as
>>         *       sparse memory arena. We do it the other way around, since
>>         *       we have to reserve 3GB - 4GB for Linux, and thus use
>>         *       0GB - 3GB as sparse memory arena.
>>         *
>>         *       FIXME: What about other OSes ?
>>         */
>>        context->Ecx = W32S_WINE2APP(0x00000000);
>>        context->Edx = W32S_WINE2APP(0xbfffffff);

1GB reserve for Lunix?! IMHO, not more 256MB!






[Index of Archives]     [Gimp for Windows]     [Red Hat]     [Samba]     [Yosemite Camping]     [Graphics Cards]     [Wine Home]

  Powered by Linux