NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/os/mswindo/programm/misc/4241

Internet Message Format | 1992-12-15 | 3.6 KB

Path: sparky!uunet!lax.pe-nelson.com!lax!twbrown
From: [e-mail] (Tom W. Brown)
Newsgroups: comp.os.ms-windows.programmer.misc
Subject: Re: Segmented Memory Woes and Portability
Message-ID: <[e-mail]>
Date: 15 Dec 92 17:22:19 GMT
References: <wf=[e-mail]>
Sender: [e-mail]
Organization: PE-Nelson
Lines: 69

In article <wf=[e-mail]>, [e-mail] (Andrew Joseph Kompanek) writes:
|>
|> I recently started porting some data structure libraries I wrote on Unix
|> to the PC under Windows 3.1.  I'm using Borland C++ 3.1.
|>
|> I naively assumed that all of the segmented memory issues would be
|> more or less transparent to me and that the compiler would take care
|> of pointer conversions, alignment problems, etc.

Hahahahahahahahaha -- sorry, I'm not trying to be rude :-)


|>                                                        I figured if I
|> compiled my code with the Compact option, my pointer declarations
|> would be interpreted as far pointers and that I could address within a
|> 1 Mb address space without changing a bit of my code.  This doesn't
|> _seem_ to work, though I just started and still don't know very much
|> about the 80x86.
|>
|> So, if this doesn't work, what is the best way to write code portable to
|> 80x86 architectures -- both under DOS and in Windows programs and DLLs?

Use large model -- that's what we use and have had no problems.  It's
anticipated that large model will be the easiest to port to Windows/NT.

But realize -- until you use WIN32s or Windows/NT you are not in a 32-bit
environment, you are in a 16:16 segmented environment and a single selector
won't allow you to address over 64 Kb of memory.


|> Alternatively, is it possible to simply call GlobalAlloc() or whatever
|> the function is to allocate memory from Windows global heap, convert the handle
|> to a far/huge pointer (the pointer declarations somehow declared this way
|> implicitly), lock the memory then when you're done with it, convert the
|> pointer back to a handle, unlock and free it?  This seems like sensible
|> behavior -- assuming that this doesn't force Windows to keep in memory
|> stuff that should it should be able to move and swap in/out.

Certainly it's possible to do that though I've tried to stay away from huge
pointers because; 1) of the overhead in their use, 2) they chew up selectors,
and 3) the "conventional" normalized huge pointers can't be used in
protected mode Windows programming.


|>
|> As a programmer, it doesn't seem like I should have to deal with the
|> quirks of the processor I'm running on...

Sorry, but that's a little idealistic.  I'd hardly call the fact that
MSDOS and Windows currently operate in a 16:16 segmented mode a quirk, it's
a fact of life.  Start using WIN32s and/or Windows/NT where you have 16:32
segments that more closely mimic the address space you're used to.


|>
|> My understanding of the 386/486 is that it has better support for virtual
|> memory management and that its virtual 32-bit pointers look like contiguous,
|> unmoving addressable memory.  Is there a way to do this in Borland C++ 3.1?

Not currently -- when Borland provides support for 32-bit Windows then
you'll get this.



----------------------------------------------------------------------------
Tom Brown               |  "She turned me into a newt...
PE Nelson Systems       |                                  ... I got better"
[e-mail]   |                    Monty Python and the Holy Grail
----------------------------------------------------------------------------