bpcompat-1.0.zip_(re)

Wed, 28 May 1997 10:38:43 +0100 (BST)

On Tue, 27 May 1997 18:49:32 -0400 (EDT) Pierre Phaneuf  wrote:
>On Mon, 26 May 1997, The African Chief wrote:
>
>> >Running gpc-970510 on a Red Hat Linux 4.1 system, kernel 2.0.27...
>> 
>> Can you please tell me which (if any) of the UNITS currently compiles
>> (without any change to the sources) under Linux? It is good to note 
>> these things in future releases. Thanks.
>
>Attached to this e-mail is the output of compiling each .pas files one
>after the others. 

Thanks. The output confirms what I already noted;

[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.

[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.

[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?

Thanks!

Looks like another update to BPCOMPAT is called for!

Best regards, The Chief 
Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant)
Author of:  Chief's Installer Pro v3.50 for Win16 and Win32.
Homepage:  http://ourworld.compuserve.com/homepages/African_Chief/
E-mail: laa12@cc.keele.ac.uk


The African Chief (laa12@cc.keele.ac.uk)