Range of the memory [Resolved]

[Kwai chang caine]

Hello at all

How can i do, for obtain all the "beach" that PB use for the pointers of memory on my PC ???

The most little number, and the bigger number

Thanks and good day

[Fred]

beach = range

[Thorium]

I dont understand the question.

[Trond]

You can't know for sure, but it's no smaller than 65535 on Windows. If you are compiling a 32-bit executable, it will never be bigger than 2147483647.

[Kwai chang caine]

Thanks FRED....

@At all
In french the range is the same word that beach... :roll:
Perhaps because the french love vacancy

@Thorium
Thanks for try to answer me

@Trond
It's exactely what i want, decidately....you are nearly the second SROD for KCC

In fact i want to be sure, that a number is not a memory adress.
If i choose numbers out of this "range"....i'm sure

The one thing i'm surprising, this number not change for each PC ????
If the memory is more big or smaller, the range is surelly different ??

[ts-soft]

programs using virtuell memory, all programs the same from 0 :roll:

[Kwai chang caine]

Hello TsSoft

Ouyaya !!!!! i not sure to understand what you explain to me
You want to say, that all the PC have the same number, even if he have 2 Go or 10 Go of RAM memory ????

[ts-soft]

programs using virtuell memory, you can not sure this is RAM or Harddisk. the os manage this, not your program.

[Thorium]

Hello TsSoft

Ouyaya !!!!! i not sure to understand what you explain to me
You want to say, that all the PC have the same number, even if he have 2 Go or 10 Go of RAM memory ????

You can read more about it here: http://msdn.microsoft.com/en-us/library/aa366525.aspx

[Kwai chang caine]

Cool your link THORIUM

KCC have understand that like usualy....this is not also simple in the head of windows that in the head of KCC

Well, the numbers of TROND are always available

Thanks at you all for your quick answer

[Kwai chang caine]

you can not sure this is RAM or Harddisk. the os manage this, not your program.

Yeeesss you are right
I have forgotten this history of temp files, for emulating memory
Thanks a lot....

[Rescator]

32bit (x86) memory addresses can range from $00000000 to $FFFFFFFF, (4GB)
but $80000000 to $FFFFFFFF (high 2GB) is reserved by the OS usually. So the user memory usually range from $00000000 to $7FFFFFFF (low 2GB).

In the past some programs tried to "cheat" by using bit 31 as a private flag in the programs, which was a very silly thing to do.
On x64 windows there is a compile/exe flag that tells the OS that the program support large addresses.
This means that by setting a small flag you can let a 32bit program use ALL 4GB on a x64 OS if available.
Now! Fred does not support this flag (yet), but you could use a tool and and set the flag manually as PureBasic itself actually does support large/full range memory addresses (or should at least).

64bit (x64) memory addresses can range from $0000000000000000 to $FFFFFFFFFFFFFFFF,
but $8000000000000000 to $FFFFFFFFFFFFFFFF is reserved by the OS usually. So the user memory usually range from $0000000000000000 to $7FFFFFFFFFFFFFFF.


So unfortunately for you this means that any value in a *pointer can be a memory address.

[Rescator]

Ah, found the article mentioning it:
http://blogs.msdn.com/b/oldnewthing/arc ... 23817.aspx

And http://msdn.microsoft.com/en-us/library/bb613473.aspx

To enable an application to use the larger address space, set the IMAGE_FILE_LARGE_ADDRESS_AWARE flag in the image header. The linker included with Microsoft Visual C++ supports the /LARGEADDRESSAWARE switch to set this flag. Setting this flag and then running the application on a system that does not have 4GT support should not affect the application.

On 64-bit editions of Windows, 32-bit applications marked with the IMAGE_FILE_LARGE_ADDRESS_AWARE flag have 4 GB of address space available.

Use the following guidelines to support 4GT in applications:

* Addresses near the 2-GB boundary are typically used by various system DLLs. Therefore, a 32-bit process cannot allocate more than 2 GB of contiguous memory, even if the entire 4-GB address space is available.
* To retrieve the amount of total user virtual space, use the GlobalMemoryStatusEx function. To retrieve the highest possible user address, use the GetSystemInfo function. Always detect the real value at runtime, and avoid using hard-wired constant definitions such as: #define HIGHEST_USER_ADDRESS 0xC0000000.
* Avoid signed comparisons with pointers, because they might cause applications to crash on a 4GT-enabled system. A condition such as the following is false for a pointer that is above 2 GB: if (pointer > 40000000).
* Code that uses the highest bit of a pointer for an application-defined purpose will fail when 4GT is enabled. For example, a 32-bit word might be considered a user-mode address if it is below 0x80000000, and an error code if above. This is not true with 4GT.

VirtualAlloc usually returns low addresses before high addresses. Therefore, your process may not use very high addresses unless it allocates a lot of memory or has a fragmented virtual address space. To force allocations to allocate from higher addresses before lower addresses for testing purposes, specify MEM_TOP_DOWN when calling VirtualAlloc or set the following registry value to 0x100000:

[Rescator]

Hey Kwaï chang caïne, I realize that you never got an actual solution to your problem.
You got the answer, but not the solution (if available).

As luck would have it, there actually is a solution for your problem:

http://www.purebasic.fr/english/viewtop ... 72&start=0

[Kwai chang caine]

MASTER RESCATOR I LOVE YOU !!!!



You have one hundred time reason....all members sometime talk at KCC, like if KCC have a brain

But....everybody in this forum know KCC now...and everybody know the only man "Brain outside"

I have just somes brain cells, for move my legs and arms....and one cell for move eyes, and open mouth for eat
And it's really not enough for all understand, all the big knowledge of all the MASTERS of this forum

I go immediately see that....again one thousand of thanks