Memory Allocation
14 messages in this thread
When writing an IPAS using Metaware and PharLap, can the memory allocation/free
be done with the Win32 API functions GlobalAlloc/GlobalFree?
If not what are the recommended DOS functions when an allocation is for a
bitmap object whose size is greater than 65536 bytes?
If you're using either Metaware or Watcom, take a look at the docs
concerning malloc. You will notice that the argument for malloc is a
32 bit entity. Your limit for a malloc is 4 gigabytes, not 64k. 3D
Studio runs in a 32 bit environment and both Watcom and Metaware are
32 bit compilers.
I understand that malloc can get GT 65535 when in 32bit compile. My
question first addressed the availability of GlobalAlloc, and what
recomended function to use if GlobalAlloc is not usable. The PharLap
manuals tend to indicate that the Win32 API is available for
GlobalAlloc and GlobalFree. I wanted to know whether the PharLap
support for these calls is "operable" in the Autodesk 3DS IPAS
implementation arena. So "Can I use GlobalAlloc and GlobalFree", or
must I use standard DOS functions malloc/free? If both are available
for IPAS, which is recommended or is it DON'T CARE?
I'm not sure why you care about GlobalAlloc and/or GlobalFree. The
malloc() function isn't a standard "DOS" function. It's a standard C
library function. Though there are other ways of messing around with
memory, malloc is the "standard" way to allocate memory in any
environment you use C. Windows has its own set of "kludgy" memory
allocation functions as Windows itself is a kludge specially when it
comes to memory. That's due to the way memory is layed out in the x86
plus all the different modes Windows has to deal with (or learned how
to deal with along the way from real mode only, to 286 16Meg limit
mode, and then to 32 bit flat memory mode).
Bottom line, just go ahead and use malloc. Don't spend too much time
with the PharLap library unless you need some specific interaction
with the hardware and/or with the real mode running underneath. The
only reason to allocate memory directly from PharLap would be if you
wanted to have your own selector and your own set of protections. For
that you would have to mess around with the 3D Studio configuration
as all available memory gets allocated to it by default.
I asked about the Win functions cause I have a core Library of "source
code" which I compile to Win16 DLL, Win32DLL, and DOS/DPMI32 static
library.
If the DOS/DPMI32 static library can be used in an IPAS && I can keep
on using the Win memory functions, I would like to do so for the Win
functions are more preferred for Win16 than are malloc and free. I
am aware that I can use conditional defines to switch from malloc to
GlobalAlloc. BUT, my line of inquiry is directed at eliciting a
broader understanding of IPAS 3DS operation, and optimal methods. SO
AGAIN, can the GlobalAlloc/Free functions be used in IPAS and if not,
then malloc is obvious. But if the Win functions can be used I would
rather experiment with their use. But I'd rather forgo the
experimentation if someone can tell me categorically that it won't
work and is inoperable for IPAS usage.
<< But if the Win functions can be used I would rather experiment
with their use. But I'd rather forgo the experimentation if someone
can tell me categorically that it won't work and is inoperable for
IPAS usage. >>
I'm now back from Chicago. Regarding your experimentation, the Win
functions were *not* tested by Autodesk's QA department during the
developement of the IPAS3 SDK nor documented. Therefore it is not an
Autodesksupported feature . I'd be interested in hearing about any
results from your experiments tho'.
OK will do. For the time being I have replaced all of my library
calls to GlobalAlloc, GlobalFree, GlobalLock, GlobalUnlock with my
own MemoryAlloc, (etc) functions.
then in my functions I used conditional defines to adapt the method
from Win to DOS functions as in:
#ifdef DPMI
return (HGLOBAL)malloc (…..
#else
return (HGLOBAL)GlobalAlloc (…..
#endif
This way it is easy to conduct the experiment by switching between DOS
and WIN type memory functions.
I have a similar approach to FILE IO functions, and will now convert
my MEMORY IO group as well.
I put your questions past one of the developers…
"The features that the developer is refering to are part of the TNT
(Pharlap 6.0) extender. 3D Studio was not made with that version of
the extender, so none of those features will be available to the IPAS
routine.
Ciao,Grant"
OH NO!
So how do I know what PharLap features are supported?
The IPAS docs say version x.x and later (I can't remember what x.x was
given). Do you have any list of what the features of x.x are, or do
I need to query PharLap tech support for this?
I will be needing to create alias descriptors in the Global Descriptor
table?
Can I do this with the version of PharLap run-time shipped with 3DS?
I have never tried doing what you're doing so I don't know if those
functions are supported or not. You didn't explain you had a bunch of
code already using those which now makes perfect sense. If you were
just starting to write code from scratch, it would not make much
sense to be worring about the PharLap library.
Instead of doing your #ifdef/#else/#endif, you could simple #undef
GlobalAlloc and #define GlobalAlloc to malloc in one of you header
files. This will allow you to use the source unchanged. It's a pain
to keep track of every place you invoke a certain function so it's
easier to just redefine it.
Except that GlobalAlloc and malloc have differing prototypes. So it
is easier to manage with a shell function as I described.
Also, the shell function can deal with certain nuances of
implementation which a global define cannot.
You're making life hard for yourself. Use libraries of functions. I have
several hundred thousand lines of C code that compile and run portably on
several platforms, including Win32s/WinNT.
For example, I have a 'tstdio.lib' that makes portable versions of the most
useful functions found in the traditional 'stdio' library. For example, there's
a function declared 'void *tAllocMem( size_t size )' which maps to the correct
memory allocation function on different systems. There's a header file that
contains the prototype that gets included everywhere, so you get prototype
protection.
Within the code for tAllocMem(), there are essentially #ifdefs for each
compiler or OS. Your makefiles can link the proper version of the library. If
you are careful, you can even use the same makefile for different platforms.
Using #define methods to replace functions is dangerous.
I'm not using defines.
I am using the same method you espouse.
Someone else suggested the defines.