«

[rlbell]

Originally posted by Anubis+Apr 12 2006, 10:45 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>QUOTE (Anubis @ Apr 12 2006, 10:45 PM)</td></tr><tr><td id='QUOTE'> <!--QuoteBegin-plix@Apr 12 2006, 10:53 AM
XP has a hard limit of 4GB which is a hardware limitation as well as a software one.* 32 bit processors simply cannot address more than 4GB (2^32 bits) and while I believe there are some Intel-specific extensions to deal with enlarging the address space, I double checked the Microsoft documentation of the issue and all 32b versions of Windows are still subject to this limit.

While the address size increases considerably with 64 bit processors (to the tune of 18 exabytes), I'm fairly certain that 64b Windows imposes a far lower software-level limit.

This is correct.

I worked on latop with 2GB of memory, and enables you work very fast with large files (for example movies) as it does not have to use pagefile all the time. [/b][/quote]
There are workarounds for this. The 8088 was only a sixteen bit processor, but it could address twenty-four bit address spaces using paged memory management. One of the CPU's system registers was eight bits long and stored the page number of the memory address, and all memory operations used the contents of the page register as the first eight bits of the twenty-four bit address. The M68000 family must also have had this feature, as my Macintosh had a megabyte of RAM (twenty bits worth of address space), but only a sixteen bit CPU.

You can have more address lines than the word size, but it complicates things, and slows things down. Now word sizes are at the point where there is no need for using memory offsets to get larger address spaces.

It is not just the operating system that determines how much memory you need. More is usually better, as one of the common computer bugs are memory leaks. these are snippets of code that grab dynamically allocatable memory, but never give it back, even after it is finished with it. The amount of memory available goes down, and the swap file gets bigger; until, the computer can only run by thrashing the disk. This is why it is a good idea to reboot your system periodically to keep it running fast for the rest of the time.

[plix]

Originally posted by rlbell+Apr 21 2006, 11:53 PM--></div><table border='0' align='center' width='95%' cellpadding='3' cellspacing='1'><tr><td>QUOTE (rlbell @ Apr 21 2006, 11:53 PM)</td></tr><tr><td id='QUOTE'>

There are workarounds for this. [/b]

...

<!--QuoteBegin-rlbell
These are snippets of code that grab dynamically allocatable memory, but never give it back, even after it is finished with it.* The amount of memory available goes down, and the swap file gets bigger; until, the computer can only run by thrashing the disk.* This is why it is a good idea to reboot your system periodically to keep it running fast for the rest of the time.[/quote]
Virtual memory essentially solves this problem as, when the process is killed, the virtual address space is freed and all associated memory freed. Try running a test program which malloc()s a lot of memory but doesn't free it, then kill it -- the allocated memory will be freed by the OS.

[win98]

Yeah I notice that with vmware which I am trialing.

[The Fifth Horseman]

This thread's a bit old, but the question is related...

How much RAM can Windows 98 SE handle, exactly?

[_r.u.s.s.]

Originally posted by the_fifth_horseman@May 4 2006, 10:13 AM
How much RAM can Windows 98 SE handle

=P

[win98]

512MB without editing some sys files I forgot which ones anyway to push it past you need to edit sys files.

[_r.u.s.s.]

it was.. written in my post?

[win98]

OK sorry.

[_r.u.s.s.]

i just get kinda pissed becouse in most of your posts dont say anything new, just only repeat what did others say

[win98]

I am just trying to help :blink: .