What is ReactOS' memory limit and how can it be modified?

[Konata]

(Asking about the more neglected 64-bit version, obviously)
Microsoft apparently only gives each version of Windows an upper limit of usable memory equivalent to what they can actually test it on, probably so they don't recreate the glitch in the 9x series. So it's a notoriously small amount compared to other operating systems (but still insanely massive). So what is ReactOS' memory limit? How can it be changed? Is it easy to change? Or is this a moot question until the Memory Manager is properly finished? Or is it moot because that part of the x64 version isn't even started yet?

[dizt3mp3r]

Well, I think you know the answer already. ReactOS is a 32bit o/s. ReactOS will provide aim to provide compatibility for 32 bit drivers. Lots of work to do to provide even this.

64bit may/will come later, a lot later.

Questions re: 64bit ReactOS are therefore academic...

[middings]

For the curious, this set of tables from Microsoft: Memory Limits for Windows and Windows Server Releases provides an overview. How Microsoft configured the PAE, AWE, and 4GT tricks is explained in the Windows Internals book(s).

[EmuandCo]

PAE or AWE are not available in ROS yet. And it never was recommended at all due to driver problems which showed up quite often with it being used to access RAM above 4 GiB limit. But yes, these limits in Windows are artificial. There are some patches to make Windows 7 SP1 x86 use 64 GiB RAM by patching a few bytes in NTOSKRNL. (http://www.unawave.de/windows-7-tipps/3 ... ml?lang=EN) ReactOS supports the limits Windows XP would have by now. Something around 3 - 3.75 GiB RAM depending on hardware. Not existing PAE means that no-execute is not working, too.

Explained nicely here: https://blogs.technet.microsoft.com/mar ... al-memory/

[middings]

Thanks for sharing the link to Mark Russinovich's blog, EmuandCo. I had forgotten that although the addressing hardware exists on-chip, the actual use of memory 'way up in the sky' has practical drawbacks.

[PurpleGurl]

So Microsoft enabled PAE when it could to make use of the hardware buffer overrun protection, but caps it at 3.75 or wherever like Daniel said because of compatibility (driver and/or hardware) reasons.

As for the defunct 64-bit build, while it can likely support a crapload, theoretically -- assuming it worked, practically, you likely won't find a regular machine that currently will allow more than 32GB to be installed. On most boards I've seen, 4 GB per socket is the limit, and they don't tend to have more than 8 sockets. Now, some of the Xeon boards are dual-CPU, and they may go up to 64 GB (8 sockets per physical CPU). However, I doubt if we have NUMA support, so likely, only one core of one CPU would currently run.

[Konata]

Thank you PurpleGurl, but I'm not too concerned with the hardware at the moment, I was more or less curious about the software side.
Unfortunately, I don't see much of a future for my ventures without a 64-bit ReactOS. I hope to one day learn enough about the architecture to properly contribute to 64-bit ReactOS.
Until then, thank you for your responses.

[middings]

I found a dual Xeon ATX form-factor motherboard that can accept up to 1.5 TB of ECC RAM. That is amazing.
The same seller had 25 (twenty-five) other motherboards that can accept up to 1 TB of RAM. Cooling is a challenge, I suppose.

[dizt3mp3r]

My first partial self-build PC was a IBM 286 6mhz PC with fully loaded 640K or RAM (£4,500). Then with two 4mb expansion cards for a 8mb RAM drive (£4,000 each) and an 80mb full height hard drive with 3rd party partitoning software (£450) I had an environment that could cross compile and build ADA programs for military hardware.

At that point it was probably the most powerful bit of PC kit available (for a short while). At the time unthinkable that much more memory/storage would ever be required, after all 1024 bytes is approximately the amount of storage required to store the text in one A4 sheet of paper. Well, that's what we thought...

I am currently of the opinion that a core2duo 2.5ghz with 4gb RAM and a terabyte of storage is enough for my needs for the near future (and strangely enough has been sufficient for the last 8 years or so). I am wrong of course.

[erkinalp]

On most boards I've seen, 4 GB per socket is the limit, and they don't tend to have more than 8 sockets..

My mobo supports 2x8GiB configuration. That mobo is from 2012.

[PurpleGurl]

My mobo supports 2x8GiB configuration. That mobo is from 2012.

Thanks. I wasn't really trying to nail it down with a dogmatic statement, so it is good to hear what others have used or seen to get more realistic numbers.

And I like how you used the correct units. I am old school before the standards committees redefined the terms to be more accurate and not conflict with the SI (metric) system, so that is why I used gigabyte as opposed to gibibyte, though gibibyte is the correct unit, since that is based on 2^10 (1024) and not 1000. On older hard drives, for instance, they used megabytes and gigabytes to mean mebibytes and gibibytes, but now, they really mean based on 1,000, and I first thought that was misleading, since they were using the redefined terminology, and a lot of us still remember the original (mis)usage of the terms.

Speaking of confusing terminology, throughput on SATA drives is one. Like I saw them use both 600 mb/s and 6 gb/s . At first glance, that appears off by a factor of 10, as 0.6 gb/s is not 6 gb/s. But they cheat in 2 ways to get the math to work. First, the smaller unit as used means bytes, while the larger unit means bits. But then, wouldn't the difference be by 8, not 10? Thus leading to counting the overhead in the speed to make it sound better. There are 2 start/stop bits, thus it is a 10-bit transport mechanism, despite 8 bits of cargo. Of course, to justify the differences, they might say one is transfer speed and the other is throughput, which superficially sounds like the exact same thing. Reminds me of modems. People wrongly exchanged baud rate (carrier signal) with transfer rate. For instance, a 9600 bps modem might really only be 4800 baud or whatever. The encoding technology is why baud and bps were not the same. If you use maybe a QAM system, then it's possible to have data flowing at twice the baud (much like DDR and memory speed vs. clock rate).

Yes, I know the topic has drifted some, but as for overall goals, we strive to be like Windows. As for what it can currently do or the x64 port can do, that is a whole other ballgame.

[demizen]

(Asking about the more neglected 64-bit version, obviously)
Microsoft apparently only gives each version of Windows an upper limit of usable memory equivalent to what they can actually test it on, probably so they don't recreate the glitch in the 9x series. So it's a notoriously small amount compared to other operating systems (but still insanely massive). So what is ReactOS' memory limit? How can it be changed? Is it easy to change? Or is this a moot question until the Memory Manager is properly finished? Or is it moot because that part of the x64 version isn't even started yet?

As far as I know, there are no fundamental memory limits to 32 bit systems. Linux systems have no ram limit set at 4GB, I am not sure if I understand why is windows kernel limited to 4GB but then again, windows software is not designed to utilize it.

I hope there will be no limits other than hardware imposed. I am planning on my first build today. I'll see if I can get the thing running on an old small form dual core Optiplex with 8 g ram and use it with presonus firestudio and Cubase.

[dizt3mp3r]

presonus firestudio and Cubase

Don't expect that to work.

[val]

As far as I know, there are no fundamental memory limits to 32 bit systems. Linux systems have no ram limit set at 4GB, I am not sure if I understand why is windows kernel limited to 4GB but then again, windows software is not designed to utilize it.

even in this very page, above it has been mentioned why there is such a limit - mainly it's due to compatibilty problems with plethora of drivers, which cannot deal properly with accessing memory above 4GB, DMA related stuff. It's not a kernel issue. when you should maintain compatibilty in order to have all existing codebase to work, always such problems arise. linux doesn't have such a limit just because they don't care about a someone's machine not working anymore. if you face such a problem of a buggy driver crashing the system there, you would need to run around and beg "maintainers" to patch that. if that will look for them "not critical", you'll end up with the same "limit".

I hope there will be no limits other than hardware imposed.

if you want your system would take advantage of using third party drivers, needed to run a machine at the full potential, you'll discard such a silly hope.

[demizen]

As far as I know, there are no fundamental memory limits to 32 bit systems. Linux systems have no ram limit set at 4GB, I am not sure if I understand why is windows kernel limited to 4GB but then again, windows software is not designed to utilize it.

even in this very page, above it has been mentioned why there is such a limit - mainly it's due to compatibility problems with plethora of drivers, which cannot deal properly with accessing memory above 4GB, DMA related stuff. It's not a kernel issue. when you should maintain compatibility in order to have all existing codebase to work, always such problems arise. linux doesn't have such a limit just because they don't care about a someone's machine not working anymore. if you face such a problem of a buggy driver crashing the system there, you would need to run around and beg "maintainers" to patch that. if that will look for them "not critical", you'll end up with the same "limit".

I hope there will be no limits other than hardware imposed.

if you want your system would take advantage of using third party drivers, needed to run a machine at the full potential, you'll discard such a silly hope.

I checked the rest of the stuff before and i tried to patch windows 7 to remove the limits. While i understand what you are saying, i assume that everyone is getting into this project hoping that all drivers will be rewritten at the market share inflection point. there is plenty of old code that begs to be rewritten. Linux distros have peaked there is a share that begs to be taken. hope, my man, is all we got. I use hackintosh to do what i need to do, but if we had a really invasive OS open to everyone that could take advantage of available code and any obsolete hardware out here would be really something for the peeps that cant afford the fancy shit.