[comp.windows.ms.programmer] Huge pointers in BC++

aaron@jessica.Stanford.EDU (Aaron Wallace) (04/20/91)

Hi!  I just got my Borland C++, and in general it looks real nice for Windows
stuff.  I'm trying to move over some stuff from MS C 6 to BC++ and have a 
question:  I use huge pointers a lot in my code to go through GlobalAlloc'd
blocks of memory.  I noticed that BC++ by default implements huge pointers
in a way that is certain to cause UAEs under protected mode.  There's a
switch for "fast" huge pointers that may implement them correctly, but
I can't say.  Does BC++ correctly use the __ahincr to do huge arithmetic?
I'd assumed it does--how else could you say it does Windows if it doesn't?
Now I'm not certain, and my program that otherwise worked fine when compiled
with MSC dies when compiled with BC++.  Well, to be fair it only dies when it
goes near huge pointers, but I can't be sure what the exact cause is.

If the answer is RTFM, which FM?  

Thanks in advance!

Aaron Wallace

cadsi@ccad.uiowa.edu (CADSI) (04/20/91)

From article <1991Apr19.172703.24638@leland.Stanford.EDU>, by aaron@jessica.Stanford.EDU (Aaron Wallace):
> Hi!  I just got my Borland C++, and in general it looks real nice for Windows
> stuff.  I'm trying to move over some stuff from MS C 6 to BC++ and have a 
> question:  I use huge pointers a lot in my code to go through GlobalAlloc'd
> blocks of memory.  I noticed that BC++ by default implements huge pointers
> in a way that is certain to cause UAEs under protected mode.  There's a
> switch for "fast" huge pointers that may implement them correctly, but
> I can't say.  Does BC++ correctly use the __ahincr to do huge arithmetic?
> I'd assumed it does--how else could you say it does Windows if it doesn't?
> Now I'm not certain, and my program that otherwise worked fine when compiled
> with MSC dies when compiled with BC++.  Well, to be fair it only dies when it
> goes near huge pointers, but I can't be sure what the exact cause is.
> 
> If the answer is RTFM, which FM?  

As far as I know, you can't use the BC++ with its Huge pointers in Windows.
I don't have my manuals here at my office, but I do remember reading
something like this.

|----------------------------------------------------------------------------|
|Tom Hite					|  The views expressed by me |
|Manager, Product development			|  are mine, not necessarily |
|CADSI (Computer Aided Design Software Inc.	|  the views of CADSI.       |
|----------------------------------------------------------------------------|

ebergman@isis.cs.du.edu (Eric Bergman-Terrell) (04/20/91)

Well Petzold covers memory allocation & memory models rather well.  What
memory model are you using?

I'm using the medium model, and use far pointers for globalalloced memory
without a problem (I too am using BC++ 2.0)...


Terrell

aaron@jessica.stanford.edu (Aaron Wallace) (04/22/91)

In article <1991Apr19.221458.12071@ccad.uiowa.edu> cadsi@ccad.uiowa.edu (CADSI) writes:
>From article <1991Apr19.172703.24638@leland.Stanford.EDU>, by aaron@jessica.Stanford.EDU (Aaron Wallace):
>> Hi!  I just got my Borland C++, and in general it looks real nice for Windows
>> stuff.  I'm trying to move over some stuff from MS C 6 to BC++ and have a 
>> question:  I use huge pointers a lot in my code to go through GlobalAlloc'd
>> blocks of memory.  I noticed that BC++ by default implements huge pointers
>> in a way that is certain to cause UAEs under protected mode.  There's a
>> switch for "fast" huge pointers that may implement them correctly, but
>> I can't say.  Does BC++ correctly use the __ahincr to do huge arithmetic?
>> I'd assumed it does--how else could you say it does Windows if it doesn't?
>> Now I'm not certain, and my program that otherwise worked fine when compiled
>> with MSC dies when compiled with BC++.  Well, to be fair it only dies when it
>> goes near huge pointers, but I can't be sure what the exact cause is.
>> 
>> If the answer is RTFM, which FM?  
>
>As far as I know, you can't use the BC++ with its Huge pointers in Windows.
>I don't have my manuals here at my office, but I do remember reading
>something like this.

Using the fast huge pointers did seem to work after all--the UAEs were cause
by an infinitely more embarassing "bug"  (Yes, I confess, I *thought* I had
told BCC+ to make everything exportable...!)

Anyway, BCC+ seems to work like a charm--why can't Microsoft write compilers?
Do they actually use their own?  Maybe that's why it takes them so long to
come out with new software...  

Aaron Wallace