gnat 3.07 DOS

gnat 3.07 DOS

[Michael F Brenner]

Preliminary Feedback: the gnat 3.07 DOS: (1) More things work 
than worked under 3.05. (2) Some things work a lot faster.
(3) All EXEs are about twice as big as gnat 3.05 before stripping,
but they strip (using SLIMFAST.BAT) down to about 10K more 
than their 3.05 size, (4) There may be a couple of new problems.
First, we may have to start a new stream_IO thread, because
we seem to be getting extra carriage returns on some stream_io
writes. I am not sure yet, but it seems that when you write to 
a stream_io file or a text_io stream file to the console (no pipe)
it looks about right, but when you write a a text_io stream
to a pipe to a file, it may be writing an extra carriage return.
Also, some applications that worked under 3.05 are getting 
sigseg interrupt 08 DOS hangs. As a result it will take a 
couple of days to test the public domain software we were using.

Things someone could look into: (A) Were the symbols REALLY stripped
from the runtime routines? (B) How can we write streams of bytes
in a way that they work the same way from a pipeline or to
an internally opened filename, preferably in a way that works
unchangingly between DOS and un*x? 

If preliminary testing does not eliminate any problems, they will
be submitted as bug reports.

Re: gnat 3.07 DOS

[Douglas Rupp]

In article <5c36l5$5u3@top.mitre.org>,
Michael F Brenner <mfb@mbunix.mitre.org> wrote:
>Things someone could look into: (A) Were the symbols REALLY stripped
>from the runtime routines?

The DOS 3.07 READ.ME addresses this.

Re: gnat 3.07 DOS

[Jerry van Dijk]

Michael F Brenner <mfb@mbunix.mitre.org> wrote in article
<5c36l5$5u3@top.mitre.org>...

> Preliminary Feedback: the gnat 3.07 DOS: (1) More things work 
> than worked under 3.05. (2) Some things work a lot faster.
> (3) All EXEs are about twice as big as gnat 3.05 before stripping,
> but they strip (using SLIMFAST.BAT) down to about 10K more 
> than their 3.05 size,

Yes, I have the same experiences. Also error checking is improved
again.

>  (4) There may be a couple of new problems.

Lets see...

> First, we may have to start a new stream_IO thread, because
> we seem to be getting extra carriage returns on some stream_io
> writes.

Hmmm, although I'm doing a lot of file scanning/parsing right now
I haven't run into this (yet?).

I hardly dare to ask, but are you sure it's not a file format
translation
(unix (LF) to DOS (LF/CR) problem ? Both GNAT and DJGPP have
options controlling the translation.

> Also, some applications that worked under 3.05 are getting 
> sigseg interrupt 08 DOS hangs. As a result it will take a 
> couple of days to test the public domain software we were using.

That is really odd.You are not using djgpp 2.01 ?

Note that *DOS error 8* (what is what in djgpp the signal number 
means) is 'out of memory'.

> Things someone could look into: (A) Were the symbols REALLY stripped
> from the runtime routines?

In 3.05 the 'strip' utility was automatically run when building a
executable, this
has been left out of 3.07. To get back to the 3.05 filesizes use:

exe2coff file.exe
strip --strip-all file
coff2exe file
del file

 (B) How can we write streams of bytes
> in a way that they work the same way from a pipeline or to
> an internally opened filename, preferably in a way that works
> unchangingly between DOS and un*x? 

By setting the proper file format options, see GNAT and DJGPP docs.

BTW although we should be glad ACT has provided us yet again with
a new version of GNAT/DOS, it would have been even nicer if:

a) DJGPP v2.01 was used as a platform, the incompatibilities are a
    major PITA;

b) GNAT would use the DJGPP Long Filename Support when running
    in a Win95 DOS box.

Jerry.