Memory usage

[Mike Smith]

I have a Fortran program originally written to run with DOS which I have now
compiled and modified to run with Windows 7/8 in a command window.

The program when running with old DOS Microsoft software and then current
hardware would commonly run out of memory as 640K RAM was a common limit.

My new hardware has 8GB of RAM will the program need more than just
re-building to support the extra RAM? it has been compiled and built using
Open Watcom.

Thanks for any comments.



Regards,

Mike Smith

[dpb]

On 02/17/2015 2:28 AM, Mike Smith wrote:
> I have a Fortran program originally written to run with DOS which I have
> now compiled and modified to run with Windows 7/8 in a command window.
>
> The program when running with old DOS Microsoft software and then
> current hardware would commonly run out of memory as 640K RAM was a
> common limit.
>
> My new hardware has 8GB of RAM will the program need more than just
> re-building to support the extra RAM? it has been compiled and built
> using Open Watcom.

...

The 32-bit flat memory model supports 4GB code and data.

--

[Lynn McGuire]

> The 32-bit flat memory model supports 4GB code and data.e

2 GB unless you have the /LARGEMEMORY switch implemented which gets you 3 GB.

Lynn

[dpb]

Been too long since I actually built a Watcom executable but I recalled

"n the flat memory model, the application's code and data must total
less than 4GB in size. Segment registers CS, DS, SS and ES point to the
same linear address space (this does not imply that the segment
registers contain the same value). That is, a given offset in one
segment refers to the same memory location as that offset in another
segment. Essentially, a flat model operates as if there were no segments."

??

--

[Lynn McGuire]

Windows reserves 2 GB for the kernel and so there is 2 GB for the user.
http://blogs.technet.com/b/askperf/archive/2007/03/23/memory-management-demystifying-3gb.aspx

Lynn

[dpb]

OK, that's the OS restrictions, _not_ the actual executable sizes
supported by the compiler.

--

[Lynn McGuire]

True, very true. I would not be surprised if Linux and Unix do the same also.

Thanks,
Lynn

[dpb]

On 02/18/2015 3:35 PM, Lynn McGuire wrote:
> On 2/18/2015 10:13 AM, dpb wrote:
>> On 02/17/2015 1:39 PM, Lynn McGuire wrote:

...

>>> Windows reserves 2 GB for the kernel and so there is 2 GB for the user.

...

>> OK, that's the OS restrictions, _not_ the actual executable sizes
>> supported by the compiler.

...

> True, very true. I would not be surprised if Linux and Unix do the same
> also.

...

Oh, Linux is, as always much more obtuse... :)

By default w/o PAE-enabled hardware, iirc it reserves 1GB for kernel/3GB
per process, similar to the option in Windows.

But, the kernel is PAE-aware and if the hardware/chipset supports it, it
will make use of it and with a bunch of alternate incantations you can,
I think, manage to get to as much as a 64GB address space.

I'd have to go look up all the possibilities but they're myriad and
complex... :)

--

[Lynn McGuire]

I am not a big fan of myriad and complex methods. They tend to have myriad and complex ways to fail.

Been there, done that. Especially desperately trying to find spare memory in Win16.

Lynn

[dpb]

On 02/20/2015 12:52 PM, Lynn McGuire wrote:
> On 2/20/2015 10:06 AM, dpb wrote:

...


[re: linux memory management]

>> I'd have to go look up all the possibilities but they're myriad and
>> complex... :)
>
> I am not a big fan of myriad and complex methods. They tend to have
> myriad and complex ways to fail.
>
> Been there, done that. Especially desperately trying to find spare
> memory in Win16.

Unix/Linux/etc. are actually quite stable...configuration possibilities
are more arcane and multiple than are available under Windows but
reliability is quite good, particularly, comparatively.

I was, however, particularly partial to DEC/VMS...

--