System that could take more memory

Hello all,

First, Thanks for taking time to read this post.

I am software developer and would like to install and try out different versions of applications on my machine. Of late I noticed that some of the applications that I want to try and play require more and more memory [RAM] and I am at a point where I need your help.

I would like to get a machine which would could scale as the time goes by in terms of memory and at the same time I do not want to upgrade for a 64-bit OS because a lot of applications do not support at least at this point of time.

Example:
I work with an enterprise application that use to run fine with 2GB RAM, but the newer version requires at least 4GB of RAM. I know windows has its own limitations of accessing more than 3+ gig of RAM and I did not try other OS options.

Plz advice, if a server is a good option to get because I am ready to invest more at this time rather than just keeping buying newer machines as the times goes by, if so, then which server? what specs? etc.

Plz let me know if I am not clear with my problem.

Thanks,
Kriss

Hello Scott,
Thanks for you reply.
Your confusion is valid, its just my lack of understanding to some extent and the specifications sheet laid by the vendor.

What are your recommendations if I go with unix or linux instead of windows?

I just need a system which could scale in terms of memory say like upto 8GB or 10 GB in the future.
Thanks.

Kriss - As one of the board members has in a tag line: Unix is user friendly. It's just picky who it's friends are. Well.. I didn't get picked So I'm going to punt on the *ux question.

Fundamentally, it comes down to a simple math problem. 2^32 = 4GB worth of address space. And as I'm sure you're very aware, more than just RAM needs addresses. On a software level the default is that Windows reserves 2GB for system use, and leaves the other 2 for application usage. On a Hardware level, a good chunk of the address space used for the system is for hardware: System Bios, Mobo resources, Memory Mapped I/O, and other allocations for installed devices.

There is a functionality, called "Physical Address Extensions", that essentially adds another 4 bits worth of address space which could be used for the purpose of adding more resource. 32 bit limitations still apply (4GB ranges, etc etc etc), and all of your drivers must br written and tagged as Large_Address_Aware. The driver requirement badly hurts PAE in a consumer desktop environment, since very vbery few drivers are written that way. And as a developer, you should also be (painfully) aware of what happens when a device/driver asks for resource which isn't where the device/driver expects it to be... These limitations are why Microsoft have disabled PAE usage for address space purposes on all of their desktop operating systems.

Now - If you must, and you have the technical knowledge/resource available to you, it *is* possible...

Microsoft article about PAE:
http://www.microsoft.com/whdc/syst [...] ae_os.mspx

Here's a KB article from Microsoft which should help show you how: http://support.microsoft.com/kb/283037

Just know that it is a workaround, and that - unless you have a legitimate technical reason otherwise - you should use 64 bit Windows and skip the idea.

And yah - For the board at large: You guys are probably more than familiar with my usual rants against PAE on the desktop. It can be done - But you need a very carefully controlled environment to do it. In this case, the OP is a Developer and should have access to technical resources the general population do not. From here, I would expect the OP to take advantage and use the links provided As A Starting Point to determine if such a thing is applicable and viable for his intended usage. If you think you have those kind of chops, then knock yourself out... But know that this is one of those questions where if you have to ask, you probably shouldn't be screwing with it.

I believe the PHYSICAL_ADDRESS structure is 64bit whether you run in normal mode or PAE mode. So it doesn't need to be "tagged", it just need to not ignore the upper 32 bits.