delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/12/29/07:35:08

Date: Mon, 29 Dec 1997 14:34:42 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: "S. M. Halloran" <mitch AT duzen DOT com DOT tr>
cc: djgpp AT delorie DOT com
Subject: Re: Winsock.h parse error problem
In-Reply-To: <199712291151.NAA00076@ankara.duzen.com.tr>
Message-ID: <Pine.SUN.3.91.971229142942.28407C-100000@is>
MIME-Version: 1.0

On Mon, 29 Dec 1997, S. M. Halloran wrote:

> Application programmers would 
> never, to my knowledge, ever need to directly manipulate the segment 
> registers (play with the selectors even if the OS permitted).  I 
> admit to the possibility that the definitions of NEAR and FAR may 
> have been expanded to include the concept of NEAR being a 32 
> bit-offset, and FAR being a 48-bit address (i.e., 16-bit selector in 
> combination with 32-bit offset).  I believe you are referrring to 
> that in your statements.

Correct.  And, at least in DJGPP, application code sometimes needs to use 
such far pointers when accessing e.g. video memory.  See the `_farpeekb' 
and related functions in the DJGPP library.

> I am not sure what you mean when you mention "small" model.

Small memory model means that data and code are each given a single 
segment, and all pointers are only offsets.  In real-mode programming, 
this means code and data cannot each exceed 64KB.  In 32-bit protected-
mode programming, the segments are 2GB.

> Finally the 
> applications programmer is liberated from most of these details; for 
> the application programmer, segments are gone for all intents and 
> purposes.

This is only true as long as you don't need to access memory-mapped 
hardware devices, portions of DOS and BIOS memory, and other low-level 
stuff.  Some programs cannot be written without these accesses.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019