🚀 go-pugleaf

Michael Brill (yikes@netcom.com) wrote:

: I'm developing an app on the NeXT that I'd like to take the bulk
: of to either Windows and/or Macintosh.  I think I know how to 
: port everything but the UI and memory management.  Note that the
: pieces of the app I want to port are just plain old ANSI C.

: As far as the UI goes, I'm not going to worry about now.  What I
: am worried about is memory management.  I've scanned through the
: Windows docs and understand how memory management works there
: (getting handle, locking, operating, unlocking) and I'm looking
: for an established scheme to make the port seamless between Unix
: and Windows/Mac.

I was doing almost the same thing for the last couple of month --
transferring apps from X Windows to MS Windows.  The first 90% of
the time where spent trying to write my own memory-manager which
would allow me to use plain malloc()/free() from the UNIX code.
Only recently I found out that if I use MS C/C++ 7.0, Windows 3.1
and large memory model, I can just go ahead and use malloc() and
free() without having to worry about all that handles stuff. 
Moreover, using malloc/free under C 7/Win 3.1/Large memory model
is even better than using GlobalLock/Alloc/Unlock/Free calls
because malloc/free do their own memory management.

The summary of all that is that if you not targetting for real-mode
and if you are using MS C &, you do not have to worry about memory-
management AT ALL !!

The only question I have is why Microsoft does not tell about it
in any of the manuals that are shipped with SDK 3.1/MS C 7.0 ?
(Even though when I asked a Microsoft customer support person,
he confirmed that all of the above is true)


-- 
---------------------------------------------------------
Alex Vinogradov
Cornell Cooperative Extension, Electronic Technology Group
avinogra@empire.cce.cornell.edu