Date: Sun, 16 Apr 1995 02:38:10 -0300 (ADT)
From: Bill Davidson <bdavidson AT ra DOT isisnet DOT com>
Subject: Re: port borland to djgpp
To: Mark Mathews <mmathews AT genesis DOT tiac DOT net>
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu



On Wed, 12 Apr 1995, Mark Mathews wrote:

> poke, pokeb                       <DOS.H>
>  
>  - poke stores an integer value at the memory location segment:offset
>  - pokeb stores a byte value at the memory location segment:offset
>  
> Declaration:
>  - void poke(unsigned segment, unsigned offset, int value);
>  - void pokeb(unsigned segment, unsigned offset, char value);

Assuming you want to modify some system-specific byte in conventional 
memory (about the only use for these, typically to change something in 
the BIOS data area), try something like:
#define poke(seg, off, val)  _farpokew(_go32_conventional_mem_selector(),
	(unsigned long)((seg)<<4)+(off), (short)val)
(but all on one line, or using line-continuation chars), and similarly 
for pokeb().  A big problem porting this stuff to djgpp is that under 
Borland et al. an int is 16 bits and so is a short, 
while under gcc an int is 32 bit and a short is 16 bits.  So if you have a 
lot of code that assumes that an int is 16 bits (to change a word in memory 
or a register, etc.) you have to either do a lot of casts or extensively 
re-write your code.  Eg., above if val is defined to be an int, then a cast 
to short risks losing information (and the compiler should complain), 
so you change its definition to short, then find that it takes it's value 
from a function that returns an int, so you rewrite the function to return 
a short but...

>   FP_OFF, FP_SEG, and MK_FP macros        <DOS.H>

Do your best to just eliminate these, since there is no far in gcc.  If 
you have a function that expects a parameter that is int far *, just 
change it to int * and ditch the MK_FP macro that supplies the pointer.
This assumes the address is in your program's address space, not conv. mem.  
This occasionally gets tricky; I'm working on a port now where one 
function makes a far pointer, passes it to another, which splits it into 
segment and offset and hands those to another function (via a cast) which 
_may_ reassemble the pointer and hand it to another function (in a 
different source file, which is prototyped in a header file...) depending 
on another parameter, etc.

I hope this doesn't sound discouraging.  The problem isn't gcc, it's all 
these kludges we inherited from the 8086 architecture.  I guess segmented 
memory seemed like a great idea at the time (20 bit address space with 16 
bit registers) but now we have flat memory if we want it!

Good luck
Bill Davidson
bdavidson AT ra DOT isisnet DOT com