bpcompat-1.0.zip_(re)

Wed, 28 May 1997 15:54:42 -0400 (EDT)

On Wed, 28 May 1997, The African Chief wrote:

> [1] - the DOS and CRT units are not portable to unix and Linux). This is
> obviously due to the use of functions from DOS.H and CTYPE.H and
> CONIO.H. Can anyone port those units to unix and Linux (or, put another
> way, are there any unix/Linux ports of dos.h, ctype.h and conio.h)?
> Without these, the DOS and CRT units will never port to unix/Linux. 

This is harder. I recommend not using any ports of dos.h, ctype.h and
conio.h (though I know of at least a port of conio.h), because they would
be required to build the units. Better make their functionality integrated
in the units, will also make them a tad faster.

> [2] the SYSTEM unit is not totally portable - because of "itoa()"  which
> I used in the "Str" procedure. itoa() converts an int to a CString. Is there 
> a unix/Linux equivalent of this? I can use an IFDEF to link the unix/Linux 
> equivalent if "__UNIX__" is defined.

If there is a Unix equivalent, it could be used both in the Unix version
and the DOS version, no? Would be cleaner...

> [3] - this is the surprise - "_fmode" is said to be undefined. I thought
> that this variable existed on all C platforms. This is obviously not so.
> What is the unix/Linux equivalent (to define globally whether open()
> will open a file in binary or text mode)? 
> 
> I need to make the SYSTEM unit totally portable, so I need fixes for the
> "itoa()"  and "_fmode" problems. Can any one shed any light? 

I'm not very knowledgeable of the standard C library, so I won't be much
able to help. But I'll ask some C-knowledgeable friends I have...

Pierre Phaneuf

"The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offense." - Edsger W. Dijkstra.

Pierre Phaneuf (pp@dilu.ml.org)