I have recently discovered that POV_MALLOC() is just a
container-function for the regular ANSI C function malloc().  Since when
has malloc() been able to access EMS?  In all my other C and C++
compilers, malloc() can only get space off the heap,  i.e. you are
limited to the base 640K.    Is this a Win95 issue? Or a flat-model
memory issue?     I expected to see complicated DPMI interfacing in the
source, and all I found was POV_MALLOC().   My question is: what is this
hidden memory "trick" that I don't know about.  Thanks,

-------------------------------
Steve.

Post a reply to this message

In article <37ad1977@news.povray.org> , "Steve Horn <horn <dot> 74 @ osu" 
<"dot> edu."> wrote:

> I have recently discovered that POV_MALLOC() is just a
> container-function for the regular ANSI C function malloc().  Since when
> has malloc() been able to access EMS?  In all my other C and C++
> compilers, malloc() can only get space off the heap,  i.e. you are
> limited to the base 640K.    Is this a Win95 issue? Or a flat-model
> memory issue?     I expected to see complicated DPMI interfacing in the
> source, and all I found was POV_MALLOC().   My question is: what is this
> hidden memory "trick" that I don't know about.  Thanks,

Just a correct compiler setting and a good library allowing 32 bit
addressing under DOS - you are talking about DOS also the other question you
posted in this NG is Visual C++ related, right?
Or are you wondering about the difference between Win16 and Win32
applications?


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany

Post a reply to this message

"Steve Horn <horn <dot> 74 @ osu" <"dot> edu."> wrote:
: I have recently discovered that POV_MALLOC() is just a
: container-function for the regular ANSI C function malloc().  Since when
: has malloc() been able to access EMS?

  I think it doesn't. The compiler (djgpp, watcom or whatever) just calls
the dpmi driver which does the allocations. Since it works in 32-bit protected
mode, all the memory is available directly, without needing to use ems-pages.
  For example, this is entirely possible in djgpp and watcom:
malloc(100*1024*1024) /* allocate 100 Megs of memory */
  This works even if you have less than 100 Megs of physical RAM (the dpmi
driver creates a swap file).
  As I said, djgpp and watcom work in 32-bit protected mode, so there's no
64KB segment limits nor 640KB memory limit. You can allocate any amount
of any sized memory blocks (up to 4 Gigabytes). They don't call the DOS
memory allocation routines but the dpmi driver routines.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 8 Aug 1999 07:00:57 -0400, Nieminen Mika <war### [at] cctutfi> wrote:

>"Steve Horn <horn <dot> 74 @ osu" <"dot> edu."> wrote:
>: I have recently discovered that POV_MALLOC() is just a
>: container-function for the regular ANSI C function malloc().  Since when
>: has malloc() been able to access EMS?
>
>  I think it doesn't. The compiler (djgpp, watcom or whatever) just calls
>the dpmi driver which does the allocations. Since it works in 32-bit protected
>mode, all the memory is available directly, without needing to use ems-pages.
>  For example, this is entirely possible in djgpp and watcom:
>malloc(100*1024*1024) /* allocate 100 Megs of memory */
>  This works even if you have less than 100 Megs of physical RAM (the dpmi
>driver creates a swap file).
>  As I said, djgpp and watcom work in 32-bit protected mode, so there's no
>64KB segment limits nor 640KB memory limit. You can allocate any amount
>of any sized memory blocks (up to 4 Gigabytes). They don't call the DOS
>memory allocation routines but the dpmi driver routines.
>

Okay...that sounds good.  Now how can one get the amount of free
physical RAM left in EMS?   There seems to be no function in any of my
compilers to get this number.  (I have Borland Turbo C++ 3.0, MS Quick
C,  and MS Visual C++ v6.0... and Borland C++ 5.0 on disk not loaded
on my HD.)

Any suggestions?


---------------
Steve H.

>-- 
>main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
>):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Steve H. wrote in message <37bb0a9c.23790166@news.povray.org>...
>On 8 Aug 1999 07:00:57 -0400, Nieminen Mika <war### [at] cctutfi> wrote:
>
>>"Steve Horn <horn <dot> 74 @ osu" <"dot> edu."> wrote:
>>: I have recently discovered that POV_MALLOC() is just a
>>: container-function for the regular ANSI C function malloc().  Since when
>>: has malloc() been able to access EMS?
>>
>>  I think it doesn't. The compiler (djgpp, watcom or whatever) just calls
>>the dpmi driver which does the allocations. Since it works in 32-bit
protected
>>mode, all the memory is available directly, without needing to use
ems-pages.
>>  For example, this is entirely possible in djgpp and watcom:
>>malloc(100*1024*1024) /* allocate 100 Megs of memory */
>>  This works even if you have less than 100 Megs of physical RAM (the dpmi
>>driver creates a swap file).
>>  As I said, djgpp and watcom work in 32-bit protected mode, so there's no
>>64KB segment limits nor 640KB memory limit. You can allocate any amount
>>of any sized memory blocks (up to 4 Gigabytes). They don't call the DOS
>>memory allocation routines but the dpmi driver routines.
>>
>
>Okay...that sounds good.  Now how can one get the amount of free
>physical RAM left in EMS?   There seems to be no function in any of my
>compilers to get this number.  (I have Borland Turbo C++ 3.0, MS Quick
>C,  and MS Visual C++ v6.0... and Borland C++ 5.0 on disk not loaded
>on my HD.)


Download the source code to Fractint and borrow the EMS/XMS assembly
routines from the general.asm file, or just include the general.obj file in
your project and call the EMS/XMS routines.

Mark

Post a reply to this message

Steve H.  <horn.74> wrote:
: Okay...that sounds good.  Now how can one get the amount of free
: physical RAM left in EMS?

  Don't confuse the term "EMS" with "memory above 1 MB". EMS is just a
standard/driver (?) to access the memory.
  No program uses EMS anymore. With EMS you can use just 64 KB of memory
at a time. For example, you can't allocate 1 Meg of memory and use it
directly.

:   There seems to be no function in any of my
: compilers to get this number.  (I have Borland Turbo C++ 3.0, MS Quick
: C,  and MS Visual C++ v6.0... and Borland C++ 5.0 on disk not loaded
: on my HD.)

  There's no standard way to do it. Sometimes it's even an ambiguous thing.
As I said before, you can allocate 100 Megs even if there's not that much
RAM in the machine. In this case memory is RAM+Hard drive space, which can
be up to 4 Gigabytes. Even if you could get the amount of free memory, that
doesn't mean that you can allocate that amount of memory without swapping.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message