O_TEXT, in microsoft environment

[O_TEXT]

When opening a file with open and O_TEXT, in microsoft environment, and
then reading it with read, it is done in text mode.

What does text mode exactly mean?

How is it handled in reading?

How is it handled in writing?

does text mode has an impact on function returning position within the
file? If yes, which one?

[jacob navia]

O_TEXT wrote:

When opening a file with open and O_TEXT, in microsoft environment, and
then reading it with read, it is done in text mode.

What does text mode exactly mean?

How is it handled in reading?

How is it handled in writing?

does text mode has an impact on function returning position within the
file? If yes, which one?

DO YOUR OWN HOMEWORK!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Malcolm McLean]

"O_TEXT" <O_****@nospam. frwrote in message
news:fh******** ***@biggoron.ne rim.net...

When opening a file with open and O_TEXT, in microsoft environment, and
then reading it with read, it is done in text mode.

What does text mode exactly mean?

How is it handled in reading?

How is it handled in writing?

does text mode has an impact on function returning position within the
file? If yes, which one?

If you are printing out on an old-fashioned line printer you need to tell
the printer to move down to the next line, and also to return.
However if you are typing on a modern keyboard, usually the return button
will automatically move the cursor to the next line.
So the question is whether to represent newlines as "\n" or "\n\r".
Operating systems make different choices. However ANSI C has decided that
the "\n", or newline only route, will be used. So if you open a file in text
mode on an "\r\n" operating system the "\r" will be silently suppressed.
This is only good for files that actually represent text. Binary files might
have "\n\r" sequences embedded in them purely by chance.

So in the standard library we use

fopen(filename, "r");

to open in text mode for reading

fopen(filename, "rb")

to open in binary mode.

O_TEXT is just an alternative interface Microsoft have provided to the same
underlying system

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[O_TEXT]

Malcolm McLean a écrit :

>
"O_TEXT" <O_****@nospam. frwrote in message
news:fh******** ***@biggoron.ne rim.net...

>When opening a file with open and O_TEXT, in microsoft environment,
and then reading it with read, it is done in text mode.

What does text mode exactly mean?

How is it handled in reading?

How is it handled in writing?

does text mode has an impact on function returning position within the
file? If yes, which one?

If you are printing out on an old-fashioned line printer you need to
tell the printer to move down to the next line, and also to return.
However if you are typing on a modern keyboard, usually the return
button will automatically move the cursor to the next line.
So the question is whether to represent newlines as "\n" or "\n\r".
Operating systems make different choices. However ANSI C has decided
that the "\n", or newline only route, will be used. So if you open a
file in text mode on an "\r\n" operating system the "\r" will be
silently suppressed.
This is only good for files that actually represent text. Binary files
might have "\n\r" sequences embedded in them purely by chance.

So in the standard library we use

fopen(filename, "r");

to open in text mode for reading

fopen(filename, "rb")

to open in binary mode.

O_TEXT is just an alternative interface Microsoft have provided to the
same underlying system

okay, I understand the \r\n -\n translation mechanism.

But what I do not understand is whether read and lseek values are bytes
offset or character offset.

If you read 4096 bytes which contain 3900 translated characters, will
read return 4096 or 3900? what's about lseek?

[O_TEXT]

jacob navia a écrit :

O_TEXT wrote:

>When opening a file with open and O_TEXT, in microsoft environment,
and then reading it with read, it is done in text mode.

What does text mode exactly mean?

How is it handled in reading?

How is it handled in writing?

does text mode has an impact on function returning position within the
file? If yes, which one?

DO YOUR OWN HOMEWORK!

Malcom provides a better answer.

your answer is useless.
Moreover, you should learn keyboards contain a key which allow typing
non capitalized characters.

[Charlie Gordon]

"O_TEXT" <O_****@nospam. fra écrit dans le message de news:
fh***********@b iggoron.nerim.n et...

Malcolm McLean a écrit :

>>
"O_TEXT" <O_****@nospam. frwrote in message
news:fh******* ****@biggoron.n erim.net...

>>When opening a file with open and O_TEXT, in microsoft environment, and
then reading it with read, it is done in text mode.

What does text mode exactly mean?

How is it handled in reading?

How is it handled in writing?

does text mode has an impact on function returning position within the
file? If yes, which one?

If you are printing out on an old-fashioned line printer you need to tell
the printer to move down to the next line, and also to return.
However if you are typing on a modern keyboard, usually the return button
will automatically move the cursor to the next line.
So the question is whether to represent newlines as "\n" or "\n\r".
Operating systems make different choices. However ANSI C has decided that
the "\n", or newline only route, will be used. So if you open a file in
text mode on an "\r\n" operating system the "\r" will be silently
suppressed.
This is only good for files that actually represent text. Binary files
might have "\n\r" sequences embedded in them purely by chance.

So in the standard library we use

fopen(filename , "r");

to open in text mode for reading

fopen(filename , "rb")

to open in binary mode.

O_TEXT is just an alternative interface Microsoft have provided to the
same underlying system

okay, I understand the \r\n -\n translation mechanism.

But what I do not understand is whether read and lseek values are bytes
offset or character offset.

If you read 4096 bytes which contain 3900 translated characters, will read
return 4096 or 3900? what's about lseek?

This is highly Microsoft specific. You are referring to non standard
low-level I/O. You will get a more accurate answer from a microsoft
specific forum.

--
Chqrlie.

[Mark Bluemel]

O_TEXT wrote:

When opening a file with open and O_TEXT, in microsoft environment, and
then reading it with read, it is done in text mode.

If you want to know about microsoft specifics, there are probably more
appropriate groups in which to ask. We tend to concentrate on the C
language as defined by the ISO standard, rather than platform-specific
features.

What does text mode exactly mean?

If O_TEXT means opening in what the standard defines as a text stream,
it means what the standard says...

How is it handled in reading?
How is it handled in writing?

The standard says that that is implementation-defined, as I understand it.

does text mode has an impact on function returning position within the
file? If yes, which one?

The standard only provides one such function - ftell() - and defines it
as producing, in effect, "opaque" data for text streams. By this I mean
that the value can be used by fseek() on the same stream but has no
externally-meaningful value.

[Charlie Gordon]

"O_TEXT" <O_****@nospam. fra écrit dans le message de news:
fh***********@b iggoron.nerim.n et...

jacob navia a écrit :

>O_TEXT wrote:

>>When opening a file with open and O_TEXT, in microsoft environment, and
then reading it with read, it is done in text mode.

What does text mode exactly mean?

How is it handled in reading?

How is it handled in writing?

does text mode has an impact on function returning position within the
file? If yes, which one?

DO YOUR OWN HOMEWORK!

Malcom provides a better answer.

It's Malcolm actually.
But names don't matter do they O_TEXT ?

your answer is useless.

You should begin your phrases with a capital letter.

Moreover, you should learn keyboards contain a key which allow typing non
capitalized characters.

Keyboards do not "contain" keys.

Your question is probably not homework, but it is O/S specific. It is too
bad you were rude to Jacob, for he could have given you detailed answer,
Windows being his platform of choice.

--
Chqrlie.

[Richard Heathfield]

Charlie Gordon said:

<snip>

Your question is probably not homework, but it is O/S specific. It is
too bad you were rude to Jacob,

Yes indeed - and it was also too bad that Jacob was rude to him.

for he could have given you detailed
answer, Windows being his platform of choice.

Yes, but then C is his language of choice. Just because <foois your <bar>
of choice, that doesn't make you an expert <foo>er.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Charlie Gordon]

"Richard Heathfield" <rj*@see.sig.in valida écrit dans le message de news:
o4************* *************** **@bt.com...

Charlie Gordon said:

<snip>

>Your question is probably not homework, but it is O/S specific. It is
too bad you were rude to Jacob,

Yes indeed - and it was also too bad that Jacob was rude to him.

>for he could have given you detailed
answer, Windows being his platform of choice.

Yes, but then C is his language of choice. Just because <foois your
<bar>
of choice, that doesn't make you an expert <foo>er.

I used to waste my energy programming on DOS around these stupid Microsoft
specific text mode hacks. I even rewrote a C I/O library because I was
disgusted to see them do the \r\n translation at the low level interface
instead of just the stdio level. The benefits of bufferization were lost
because of this, as the low level I/O was not done on nice round aligned
blocks, leading to general slugishness.

I have since given up on this broken platform, and focus my development
efforts on Linux, only occasionally porting stuff to MingW or Cygwin.

Jacob makes a Windows based C compiler. He is certainly more up to date on
this issue than I am, and more an expert at it than most regulars on this
forum. Your constant bashing of his abilities is tiresome and provocative.
He makes mistakes, you make mistakes, I make mistakes, we all do, both on
technical issues and on communication skills. We are all on the same side
here, defending our language of choice, let's reserve our attacks for all
the crud out there that deserves it: java and C++ bloatware from all the big
names, MSFT and ORCL leading the pack...

--
Chqrlie.