1. DOS and nulls (was: 0-based Indexing)
> From: gertie at visionsix.com
> Subject: Re: 0-based Indexing
>
>
[snip]
>>
>> In which way does it frown?
>> The basic display functions (int 21/09 and BIOS int 10/0E and 13) will
>> happily print nulls, provided the current codepage supports them.
>> Besides, for all the DOS calls I know which take an ASCIZ string as
>> pointed argument, that arguent is a file, path or machine name, where
>> #0-#1F are not allowed or either relevant.
>> Or did I overlook anything?
>
>
> Jeeze, excuse me. In dos4 and using Turbo Pascal on a 386 in 1994(?),
> when writing a txt file with a null char in it, there wasn't a problem. When
> reading it back in, dos would truncate the file at the null char. Your mileage
>
> may vary.
>
mmm... DOS has two sets of file operation calls. The older one (DOS 1 &
2) may cause what you experoenced. The newer calls introduced by DOS 3.x
can red binary files with any ASCII values without truncating anything.
And I have no idea of which version of Turbo Pascal you were using at
that time, but I'm pretty sure it used the older set of functions for
obvious compatibility reasons.
Or the TP read() introduced this because it was not expecting control
characters other than ^Z for EOF.
I would not expct this to happen with TP5+ and DOS 5+.
> Look, i have met only one other computer programmer in real life, ever, even
> going back to the Z80/6502/8035 days. I know only one person who even
> HAS a puter in this state now.
Sorry for the references to Intel machine instructions. ASM was so
useful long ago... Still is IMO but for much more specific purposes.
> So while you guys have puter jobs, and easily
> make yourself understood because you speak to other programmers daily,
> WEEKS go by here between times i even SEE another human,,, let alone
> speak to one.
>
> Kat
Whew... I assumed I had got your meaasge quite clear.
I think I'm just a bit too far away to help... :)
CChris
2. Re: DOS and nulls (was: 0-based Indexing)
- Posted by gertie at visionsix.com
Jul 17, 2003
On 17 Jul 2003, at 19:12, Christian.CUVIER at agriculture.gouv.fr wrote:
>
>
> > Date: Thu, 17 Jul 2003 09:27:09 -0500
> > From: gertie at visionsix.com
> > Subject: Re: 0-based Indexing
> >
> >
> [snip]
>
>
> >> In which way does it frown?
> >> The basic display functions (int 21/09 and BIOS int 10/0E and 13) will
> >> happily print nulls, provided the current codepage supports them.
> >> Besides, for all the DOS calls I know which take an ASCIZ string as
> >> pointed argument, that arguent is a file, path or machine name, where
> >> #0-#1F are not allowed or either relevant.
> >> Or did I overlook anything?
> >
> >
> > Jeeze, excuse me. In dos4 and using Turbo Pascal on a 386 in 1994(?),
> > when writing a txt file with a null char in it, there wasn't a problem. When
> > reading it back in, dos would truncate the file at the null char. Your
> > mileage
> > may vary.
> >
> mmm... DOS has two sets of file operation calls. The older one (DOS 1 &
> 2) may cause what you experoenced. The newer calls introduced by DOS 3.x
> can red binary files with any ASCII values without truncating anything.
> And I have no idea of which version of Turbo Pascal you were using at
> that time, but I'm pretty sure it used the older set of functions for
> obvious compatibility reasons.
Note i said txt files.
> Or the TP read() introduced this because it was not expecting control
> characters other than ^Z for EOF.
> I would not expct this to happen with TP5+ and DOS 5+.
Note i said txt files. Even so, TP5 did not have a full set of commands for txt
file manipulation.
Kat
