Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cs.yale.edu!spolsky-joel
From: spolsky-joel@cs.yale.edu (Joel Spolsky)
Newsgroups: comp.windows.ms
Subject: Re: Pleasures and Penanties of the Large Model
Message-ID: <26008@cs.yale.edu>
Date: 5 Sep 90 01:49:26 GMT
References: <82934@aerospace.AERO.ORG>
Sender: news@cs.yale.edu
Organization: Yale University Computer Science Dept., New Haven, CT 06520-2158
Lines: 29
Nntp-Posting-Host: zoo-gw.cs.yale.edu
Originator: spolsky@suned.CS.Yale.Edu

In article <82934@aerospace.AERO.ORG> slewis@aerospace.aero.org () writes:
>	If I have a well behaved application which requires say about 10K of
>local storage and 200K global storage which it manages with the GlobalAlloc
>mechanism, is there any real penalty in specifying the large model and buying
>a great simplification on my pointer management???

First, the penalty is that you will take a serious hit in performance
when you go to the large memory module, because pointers become 32
bits which cannot be shuffled about all at once (except in the 32 bit
memory model). Of course I would bet that most of your pointers are 32
bit LPSTR's from GlobalLock anyway...

In real-mode windows, using the large memory model locks down all your
global memory; this is not a nice thing to do especially in real mode
where there is so little memory to start with... however, in 386 enhanced
mode, large model does not lock things down because the 386 hardware
can cope with the fact that far *'s do not have to be absolute
addresses.

In short, the nicest way to forever eliminate the problems of near and
far pointers is to just require your program to run in enhanced mode
only. This might or might not be appropriate for your application. It
buys you the additional advantage that you can lock down all your
memory at allocation time and keep it locked, without hogging any
memory.

Joel Spolsky
spolsky@cs.yale.edu                                        Talk Hard.
Speaking for no one.