BPCOMPAT v1.10 -released!_(re)

Fri, 24 Oct 1997 09:48:19 +0100

Frank Heckenbach wrote:

> I assume Peter's description in the announcement of GPC-970624 in
> <199706250026.CAA18851@agnes.dida.physik.uni-essen.de> can be considered
> authoritative:
> 
> --- BEGIN QUOTE ---
> 
>   * GPC has new integer types now.  Below is a table with their sizes in
>     bits and their equivalents in (GNU) C.

[....]

Yes, that is authoritative enough :-)   Thanks!

> > > Procedures assgined to procedural variables can be in the main program now,
> > > so you can remove this comment for ExitProc.
> >
> > I am still having some problems with this.
> 
> Can you show us an example where this is a problem, so it can be fixed?

I had a problem with it in TESTMEM.PAS in the new bpcompat.
However, I have since discovered that the problem lies in mixing
the use of "ExitProc", and "AddExitProc" in the same program. Use
one or the other, and the problem disappears. Use both ==
infinite loop.

> Another detail concerning ExitProc: There is a little difference between
> how BP's and GPC's system.pas handle them. BP sets them to NIL before calling
> an ExitProc. The effect is, when an exit proc "forgets" to assign the next
> one to ExitProc, the chain will abort rather than infinitely calling the same
> exit proc. I think the following would be 100% compatible:
> 
> to end do
>   begin
>     var Tmp: Pointer;
>     while ExitProc<>nil do
>       begin
>         InOutRes := 0;
>         Tmp := ExitProc;
>         ExitProc := NIL;
>         PProcedure (Tmp)^
>       end
>   end;

Okay - thanks. I have replaced the code in SYSTEM.PAS with this
one.

> > > Assign is built-in now, so you can remove it from system.pas.

Actually, the CygWin32 version still does not have it - so I have
left it there (to be compiled only if __CYGWIN32__ is defined).

> > > Unit Printer:
> > >
> > > can be written now (at least for DJGPP).
> >
> > Done!
> 
> BTW: Do you close the printer file it in a "to end do" statement? BP, AFAIK,
> doesn't do so, but it's better to do.

Yes, I do. I have not seen BP's implementation. I only read about
it in the help file and wrote some code to do the same thing
(i.e., assign, and rewrite the Lst variable in a "to begin do"
statement, and then close it in a "to end do" statement). This is
all that the unit does (and from what I can see, that is all it
needs to do).

> > Yes, it is. This is how it is implemented in "AddNull", which was
> > in the strings unit before, but I have now moved it into the
> > system unit, since the system unit also uses that functionality.
> >
> > Any thoughts on whether the system unit should now export this
> > AddNull function so that it can be available globally? This would
> > introduce something which is not in the BP system unit.
> 
> I'm not sure if it should, since something like this will be built-in later,
> so programs shouldn't rely on the version in system.pas. Besides, I think,
> the name "AddNull" could be unclear or ambiguous (though I doubt someone
> would write a procedure of this name operating on numbers... ;-). I'd rather
> call it something like "Str2CString" or so...

Since all that it does is add a null terminator, perhaps I can
call it
"AddNullTerminator". The problem is that if it is not exported in
the SYSTEM unit, then I have to implement it in several units,
because the use of that functionality is widespread.

Best regards, The Chief
--------
Dr. Abimbola A. Olowofoyeku (The African Chief) 
Email: laa12@keele.ac.uk
Author of: Chief's Installer Pro 4.01 for Win16 and Win32: 
  Winner of PC PLUS Magazine Gold Award (April 1995 U.K. edition)
  http://ourworld.compuserve.com/homepages/African_Chief/
 
ftp://ftp.demon.co.uk/pub/ibmpc/win3/apps/chief/pro/chief401.zip

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