Re: Bug in od, cat, etc reading binary files

Re: Bug in od, cat, etc reading binary files

[Earnie Boyd]

>From: marcus@bighorn.dr.lucent.com
>Date: Mon, 29 Sep 1997 08:09:17 -0600
>To: gnu-win32@cygnus.com
>Subject: Re: Bug in od, cat, etc reading binary files
>
>
>Hi..
>
>>The cygwin32 isn't for compatibility with NT it is to provide a 
>>mechanism for which those things that aren't can be ported to the 
win32 
>>environment.
>
>But for what reason?  If you can't use these things with the rest of 
the
>NT world, then what is the point?  Why not just run them in the Unix 
world
>where they are happier anyhow?
>
>>Because of this the cygwin32 layer must try to be 
>>compatible to both worlds (which it does, nicely).  The problem isn't 
>>cygwin32 it is the lack of tools ported without modification for 
binary 
>>versus text that is the problem.  Therefore remaining in the binary 
>>format is not an alternative it becomes necessary.
>
>Yes, well, if the requirements are that you must run some Unix programs 
on
>NT without modification, then using cygwin32 and binary mounts may be 
the
>solution.  However, I believe that the problem may need to be 
reconsidered
>because without the additional requirement of interoperability with the 
NT
>world, why require that it run on NT in the first place?  Just for the
>fun of it?
>
>marcus hall
>-

Well, if one can have the best of both worlds in one environment, why 
not?

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Bug in od, cat, etc reading binary files

[Larry Hall]

At 08:09 AM 9/29/97 -0600, marcus@bighorn.dr.lucent.com wrote:
>However, I think that it is important that the aim of the project be set
>at some point so that people know where things are heading.  Currently, it
>looks to me that cygwin is trying to create its own isolated pocket of Unix
>like behaviour on top of a win32 environment.  Now this is fine for the
>intelectual challenge and all, but is this of any real use otherwise?  It
>seems to me that if you want a Unix environment and don't care about
>interacting with the rest of the NT/W95 environment, then why not just run
>Linux and get a real Unix environment that will run faster and have less
>compatibility problems?  If you are running NT/W95, you must be doing this
>for some reason, right?  Probably that there are things that run in this
>environment that are important as well as the Unix programs ported to the
>cygwin world.  If they are both important, shouldn't they be able to
>communicate with each other?

<snip>

>But for what reason?  If you can't use these things with the rest of the
>NT world, then what is the point?  Why not just run them in the Unix world
>where they are happier anyhow?

<snip>

>Yes, well, if the requirements are that you must run some Unix programs on
>NT without modification, then using cygwin32 and binary mounts may be the
>solution.  However, I believe that the problem may need to be reconsidered
>because without the additional requirement of interoperability with the NT
>world, why require that it run on NT in the first place?  Just for the
>fun of it?

Marcus,

I think allot of this has already been covered by others but let me just
say that I think you are arguing from a general standpoint while I and others
are thinking more of specifics.  We have found it useful to work in this
environment on NT.  We have been able to work around any "incompatibilities".
To be honest, your main concern seems to be the "incompatibility" of text vs
binary files.  Speaking from experience, I have not found many places where
working with binary files in a Windows environment has caused problems.  In
the few places that I have noticed this difficulty (most notably the limited
parsing capability of the MSDEV class wizard), it is easily handled by 
converting the file to text on demand.  Its really not much of a problem in
this direction.  Trying to work in Windows and gnu-win32 with only text files
is much worse!  As far as the argument about "why not just work in linux?",
it seems to me the answer is obvious. 

This whole argument seems somewhat repetitive and rehashed (perhaps
I've been on this list too long!;-))  Perhaps its best if any further 
discussion on this subject be taken off-line.  I'm not sure there is any
additional value to discussing well-understood desires and needs on this
list at this time....

Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      (781) 239-1053
8 Grove Street                          (781) 239-1655 - FAX
Wellesley, MA  02181                             

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Bug in od, cat, etc reading binary files

[Earnie Boyd]

>Date: Sat, 27 Sep 1997 12:58:13 -0400
>To: marcus@bighorn.dr.lucent.com, gnu-win32@cygnus.com
>From: Larry Hall <lhall@rfk.com>
>Subject: Re: Bug in od, cat, etc reading binary files
>
>At 09:41 AM 9/26/97 -0600, marcus@bighorn.dr.lucent.com wrote:
>>> >It seems to me that if one wants to port software into the NT 
environment
>>> >then one has no choice but to run the normal way NT programs do 
(without
>>> 
>>> A. We are not porting to NT, we are porting to the cygwin32 API
>>> B. Most Un*x tools expect Binary IO, mounting without -b will break 
many
>configure scripts
>>
>>I have to agree with the original poster on this.  What good is the 
cygwin32
>>API on NT if it is not compatible with the rest of NT?  If you are 
going to
>>only use programs running in the cygwin32 world, then why not just run 
Linux
>>instead and get better performance and better compatibility?  If 
you're
>>running NT, it seems that you likely need it to run some other things 
that
>>only run on NT, so if cygwin32 is to be useful, it should also be able 
to
>>deal with files produced by or intended for these other programs.
>>
>>Sure, it may be a royal pain to have to deal with the compatibility 
problems,
>>and that's probably where a lot of the ugliness of NT comes from, but 
I think
>>that that's the reality of the NT world.  If you don't want to be 
compatible
>>with the rest of the NT world, why try to run on NT in the first 
place?
>>
>>marcus hall
>
>(I swore I was going to stay out of this!)
>
>Marcus,
>
>I don't think anyone will argue that having at least an option to get 
full
>Windows platform compatibility is a desirable thing.  However, your 
>implication that cygwin32 (or gnu-win32) is not useful without this 
option
>is a bit too broad.  For the general reason that cygwin32 allows 
>traditionally UNIX based programs to be ported quickly and easily to 
Windows
>platforms, cygwin32 is useful to many people in many areas.  Tossing 
this
>fact aside is close to insulting to all who create and work on cygwin32 
and
>those who have and are currently using it.  If Windows compatibility is 
>what you need from a development environment, I suggest you use for now
>ming32 or other commercial environments.  While I'm sure there will be 
>something in cygwin32 in the future that will address your desire, Rome 
>wasn't built in a day.  And since there are other environments out 
there 
>that would address the concern you have, I personally think the initial
>goal Cygnus targeted with this environment is the correct one, at least 
in 
>regards to the market which desires to quickly and easily port software 
from
>UNIX to Windows.  I think they have done allot to achieve that.  As 
always,
>there is more to do.  However, while it may be useful to state 
particular
>desires for enhancements and such, claiming that what is there now is 
not
>useful is overstating it.  Opening up yet another debate about what 
makes a
>useful environment for Windows is not relevant.  There are many out 
there.
>If this one doesn't serve your purpose at the moment, try a different 
one
>or make your own.
>
>Larry Hall                              lhall@rfk.com
>RFK Partners, Inc.                      (781) 239-1053
>8 Grove Street                          (781) 239-1655 - FAX
>Wellesley, MA  02181                             
>
>-

Bravo!

-        \\||//
---o0O0--Earnie--0O0o----
-earnie_boyd@hotmail.com-
------ooo0O--O0ooo-------


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Bug in od, cat, etc reading binary files

[justin.]

marcus@bighorn.dr.lucent.com wrote:

> Hi..
>
> >The cygwin32 isn't for compatibility with NT it is to provide a
> >mechanism for which those things that aren't can be ported to the win32
> >environment.
>
> But for what reason?  If you can't use these things with the rest of the
> NT world, then what is the point?  Why not just run them in the Unix world
> where they are happier anyhow?
>

So you can run your NT programs comfortably and some Unix programs and not
have to entirely switch operating systems which would be more productivity
lost than you would gain by switching to a Unix flavored OS.  Everything
doesnt have to be one sided. I dont agree with your little mindframe.

> >Because of this the cygwin32 layer must try to be
> >compatible to both worlds (which it does, nicely).  The problem isn't
> >cygwin32 it is the lack of tools ported without modification for binary
> >versus text that is the problem.  Therefore remaining in the binary
> >format is not an alternative it becomes necessary.
>
> Yes, well, if the requirements are that you must run some Unix programs on
> NT without modification, then using cygwin32 and binary mounts may be the
> solution.  However, I believe that the problem may need to be reconsidered
> because without the additional requirement of interoperability with the NT
> world, why require that it run on NT in the first place?  Just for the
> fun of it?
>

So you can have more power under a single OS without having to sacrafice time
and money.
Are you telling me, when i want to write a spreadsheet, i boot to nt, and when
i want to use something unix, switch there, and juggle that forever?


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Bug in od, cat, etc reading binary files

[Pete Jordan]

marcus@bighorn.dr.lucent.com () wrote:

> It seems that the thing that causes the most problems communicating
> with each other is the wholesale mounting of filesystems in binary
> mode.  This cures some big problems in the Unix view of processes in
> the cygwin world, but makes it totally impossible to share text files
> between the cygwin world and the rest of the NT/W95 world.

Eh? All my mounts are binary and it causes me virtually no problems at
all. My (Windows) text editor both understands and can be persuaded to
create LF-terminated files, VC++ is happy with them, in fact most apps are
(Delphi being the only notable exception here).

Where's the problem?

Pete Jordan ~ Horus Communications ~ http://www.horus.cix.co.uk/

"Is a polar bear a rectangular bear after a coordinate transform?"
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Bug in od, cat, etc reading binary files

[Mikey]

On Mon, 29 Sep 1997 08:09:17 -0600, you wrote:

>
>Hi..
>
>>The cygwin32 isn't for compatibility with NT it is to provide a 
>>mechanism for which those things that aren't can be ported to the win32 
>>environment.
>
>But for what reason?  If you can't use these things with the rest of the
>NT world, then what is the point?  Why not just run them in the Unix world

You can use anything with anything, you just have to figure out how. ;^)

>where they are happier anyhow?
>
>>Because of this the cygwin32 layer must try to be 
>>compatible to both worlds (which it does, nicely).  The problem isn't 
>>cygwin32 it is the lack of tools ported without modification for binary 
>>versus text that is the problem.  Therefore remaining in the binary 
>>format is not an alternative it becomes necessary.
>
>Yes, well, if the requirements are that you must run some Unix programs on
>NT without modification, then using cygwin32 and binary mounts may be the
>solution.  However, I believe that the problem may need to be reconsidered
>because without the additional requirement of interoperability with the NT
>world, why require that it run on NT in the first place?  Just for the
>fun of it?

Because many many many people don't like 
cmd.exe/command.com, and vc++/developer stupiDo, and the
entire MS philosophy, they want tools that 
operate the way they are accustomed to,
the way those tools operate under unix.

But many many many bosses don't like 
having employees use linux/freeBSD/
pick your favorite un*x clone on their work computers, 
the cygwin32 environment is a compromise
solution for people who must develop 
FOR win32, but want to develop UNDER
unix.

Say linux at home, and cygwin32 at work?
or linux for large compiles, cygwin32 for testing?

I would think a Solaris/win32 developer
as you mentioned in another post you were
would appreciate this arrangement.

You can use your shell scripts and makefiles
unmodified either way.

Being a compromise, it is not going to 
be perfect for everyone, if you don't like
it, don't use it, but don't criticize it for not 
being what you want, when it never
told you it was going to be in the first place.

It is also still a work in progress, 
and the progress is going to be in the
direction that cygnus's PAYING 
customers ask for, do you have a
software or support contract with 
Cygnus? Neither do I.

>
>marcus hall
>-
>For help on using this list (especially unsubscribing), send a message to
>"gnu-win32-request@cygnus.com" with one line of text: "help".
>

(jeffdbREMOVETHIS@netzone.com)
delete REMOVETHIS from the above to reply
         Mikey
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Bug in od, cat, etc reading binary files

[marcus]

My question:
>I have to agree with the original poster on this.  What good is the cygwin32
>API on NT if it is not compatible with the rest of NT?  If you are going to
>only use programs running in the cygwin32 world, then why not just run Linux
>instead and get better performance and better compatibility?  If you're
>running NT, it seems that you likely need it to run some other things that
>only run on NT, so if cygwin32 is to be useful, it should also be able to
>deal with files produced by or intended for these other programs.

Larry Hall's response:

}I don't think anyone will argue that having at least an option to get full
}Windows platform compatibility is a desirable thing.  However, your 
}implication that cygwin32 (or gnu-win32) is not useful without this option
}is a bit too broad.  For the general reason that cygwin32 allows 
}traditionally UNIX based programs to be ported quickly and easily to Windows
}platforms, cygwin32 is useful to many people in many areas.  Tossing this
}fact aside is close to insulting to all who create and work on cygwin32 and
}those who have and are currently using it.

I am sorry if I have given this impression to anybody.  I believe that the
cygwin development is very good and fully support it (in principal, and in
bug fixes).

However, I think that it is important that the aim of the project be set
at some point so that people know where things are heading.  Currently, it
looks to me that cygwin is trying to create its own isolated pocket of Unix
like behaviour on top of a win32 environment.  Now this is fine for the
intelectual challenge and all, but is this of any real use otherwise?  It
seems to me that if you want a Unix environment and don't care about
interacting with the rest of the NT/W95 environment, then why not just run
Linux and get a real Unix environment that will run faster and have less
compatibility problems?  If you are running NT/W95, you must be doing this
for some reason, right?  Probably that there are things that run in this
environment that are important as well as the Unix programs ported to the
cygwin world.  If they are both important, shouldn't they be able to
communicate with each other?

It seems that the thing that causes the most problems communicating with
each other is the wholesale mounting of filesystems in binary mode.  This
cures some big problems in the Unix view of processes in the cygwin world,
but makes it totally impossible to share text files between the cygwin
world and the rest of the NT/W95 world.  This is what is causing the
greatest separation of the two worlds that I see.  It's certainly not an
easy problem to solve, but I think that the wholesale "just mount everything
as binary" probably isn't really the right solution.

}  If Windows compatibility is 
}what you need from a development environment, I suggest you use for now
}ming32 or other commercial environments.

In fact, this is pretty much what I am doing, but I am actually interested
in cross compiling from a Solaris machine for an NT target.

}... If this one doesn't serve your purpose at the moment, try a different
}one or make your own.

As a basically ming32 type user, it may be totally out of place of me to
comment on the cygwin environment's development direction.  I was echoing
another user's statement that things would be more useful if they conformed
to the NT/W95 environment's standards for what a text file looks like.
Otherwise, it seems to me that you get a Unix world on an NT/W95 box that
can't talk to anything else on the NT/W95 box.  Maybe things aren't really
that isolated, though.  If all of the cygwin mount points are binary, what
useful interaction is there between cygwin and NT/W95?  If there is none,
what advantage is there in running cygwin on NT/W95 over running Linux?
If there isn't some good answer to these questions, then I think that it
is important to try to make cygwin work with non-binary mount points so that
it will be more generally useful.

marcus hall

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Bug in od, cat, etc reading binary files

[marcus]

Hi..

>The cygwin32 isn't for compatibility with NT it is to provide a 
>mechanism for which those things that aren't can be ported to the win32 
>environment.

But for what reason?  If you can't use these things with the rest of the
NT world, then what is the point?  Why not just run them in the Unix world
where they are happier anyhow?

>Because of this the cygwin32 layer must try to be 
>compatible to both worlds (which it does, nicely).  The problem isn't 
>cygwin32 it is the lack of tools ported without modification for binary 
>versus text that is the problem.  Therefore remaining in the binary 
>format is not an alternative it becomes necessary.

Yes, well, if the requirements are that you must run some Unix programs on
NT without modification, then using cygwin32 and binary mounts may be the
solution.  However, I believe that the problem may need to be reconsidered
because without the additional requirement of interoperability with the NT
world, why require that it run on NT in the first place?  Just for the
fun of it?

marcus hall
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Bug in od, cat, etc reading binary files

[Larry Hall]

At 09:41 AM 9/26/97 -0600, marcus@bighorn.dr.lucent.com wrote:
>> >It seems to me that if one wants to port software into the NT environment
>> >then one has no choice but to run the normal way NT programs do (without
>> 
>> A. We are not porting to NT, we are porting to the cygwin32 API
>> B. Most Un*x tools expect Binary IO, mounting without -b will break many
configure scripts
>
>I have to agree with the original poster on this.  What good is the cygwin32
>API on NT if it is not compatible with the rest of NT?  If you are going to
>only use programs running in the cygwin32 world, then why not just run Linux
>instead and get better performance and better compatibility?  If you're
>running NT, it seems that you likely need it to run some other things that
>only run on NT, so if cygwin32 is to be useful, it should also be able to
>deal with files produced by or intended for these other programs.
>
>Sure, it may be a royal pain to have to deal with the compatibility problems,
>and that's probably where a lot of the ugliness of NT comes from, but I think
>that that's the reality of the NT world.  If you don't want to be compatible
>with the rest of the NT world, why try to run on NT in the first place?
>
>marcus hall

(I swore I was going to stay out of this!)

Marcus,

I don't think anyone will argue that having at least an option to get full
Windows platform compatibility is a desirable thing.  However, your 
implication that cygwin32 (or gnu-win32) is not useful without this option
is a bit too broad.  For the general reason that cygwin32 allows 
traditionally UNIX based programs to be ported quickly and easily to Windows
platforms, cygwin32 is useful to many people in many areas.  Tossing this
fact aside is close to insulting to all who create and work on cygwin32 and
those who have and are currently using it.  If Windows compatibility is 
what you need from a development environment, I suggest you use for now
ming32 or other commercial environments.  While I'm sure there will be 
something in cygwin32 in the future that will address your desire, Rome 
wasn't built in a day.  And since there are other environments out there 
that would address the concern you have, I personally think the initial
goal Cygnus targeted with this environment is the correct one, at least in 
regards to the market which desires to quickly and easily port software from
UNIX to Windows.  I think they have done allot to achieve that.  As always,
there is more to do.  However, while it may be useful to state particular
desires for enhancements and such, claiming that what is there now is not
useful is overstating it.  Opening up yet another debate about what makes a
useful environment for Windows is not relevant.  There are many out there.
If this one doesn't serve your purpose at the moment, try a different one
or make your own.

Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      (781) 239-1053
8 Grove Street                          (781) 239-1655 - FAX
Wellesley, MA  02181                             

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Bug in od, cat, etc reading binary files

[Earnie Boyd]

>From: marcus@bighorn.dr.lucent.com
>Date: Fri, 26 Sep 1997 09:41:22 -0600
>To: gnu-win32@cygnus.com
>Subject: Re: Bug in od, cat, etc reading binary files
>
>> >It seems to me that if one wants to port software into the NT 
environment
>> >then one has no choice but to run the normal way NT programs do 
(without
>> 
>> A. We are not porting to NT, we are porting to the cygwin32 API
>> B. Most Un*x tools expect Binary IO, mounting without -b will break 
many configure scripts
>
>I have to agree with the original poster on this.  What good is the 
cygwin32
>API on NT if it is not compatible with the rest of NT?  If you are 
going to
>only use programs running in the cygwin32 world, then why not just run 
Linux
>instead and get better performance and better compatibility?  If you're
>running NT, it seems that you likely need it to run some other things 
that
>only run on NT, so if cygwin32 is to be useful, it should also be able 
to
>deal with files produced by or intended for these other programs.
>
>Sure, it may be a royal pain to have to deal with the compatibility 
problems,
>and that's probably where a lot of the ugliness of NT comes from, but I 
think
>that that's the reality of the NT world.  If you don't want to be 
compatible
>with the rest of the NT world, why try to run on NT in the first place?
>
>marcus hall
>-

Marcus

The cygwin32 isn't for compatibility with NT it is to provide a 
mechanism for which those things that aren't can be ported to the win32 
environment.  Because of this the cygwin32 layer must try to be 
compatible to both worlds (which it does, nicely).  The problem isn't 
cygwin32 it is the lack of tools ported without modification for binary 
versus text that is the problem.  Therefore remaining in the binary 
format is not an alternative it becomes necessary.

-        \\||//
---o0O0--Earnie--0O0o----
-earnie_boyd@hotmail.com-
------ooo0O--O0ooo-------


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Bug in od, cat, etc reading binary files

[marcus]

> >It seems to me that if one wants to port software into the NT environment
> >then one has no choice but to run the normal way NT programs do (without
> 
> A. We are not porting to NT, we are porting to the cygwin32 API
> B. Most Un*x tools expect Binary IO, mounting without -b will break many configure scripts

I have to agree with the original poster on this.  What good is the cygwin32
API on NT if it is not compatible with the rest of NT?  If you are going to
only use programs running in the cygwin32 world, then why not just run Linux
instead and get better performance and better compatibility?  If you're
running NT, it seems that you likely need it to run some other things that
only run on NT, so if cygwin32 is to be useful, it should also be able to
deal with files produced by or intended for these other programs.

Sure, it may be a royal pain to have to deal with the compatibility problems,
and that's probably where a lot of the ugliness of NT comes from, but I think
that that's the reality of the NT world.  If you don't want to be compatible
with the rest of the NT world, why try to run on NT in the first place?

marcus hall
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Bug in od, cat, etc reading binary files

[Mikey]

On Thu, 25 Sep 97 17:37:37 est, you wrote:

>
>I want to add my comments to the above thread:
>
>>Questions: How do I do these in the GNU-Win32 world? How do I:
>>    * set the analog of MSVC++5.0's _fmode
>>    * call the analog of MSVC++5.0's int _setmode(int handle, int mode)
>
>Some time back I posted a request with the same questions under "text&binary
>modes" and had no replies.
>
>It seems to me that if one wants to port software into the NT environment
>then one has no choice but to run the normal way NT programs do (without

A. We are not porting to NT, we are porting to the cygwin32 API
B. Most Un*x tools expect Binary IO, mounting without -b will break many configure scripts

>the -b mount flag) otherwise your text files will confuse NT programs.
>The binary mount is pretty useless: why would one want to run in your
>own UNIX world on top of NT when the performance was so poor?

C. Posix compliance has not yet been completed, so of course performance hasn't been optimized
     1st things 1st.

>So the only real use for software like gnuwin32 is to move stuff over -
>and then one is left with "When in Rome...."
>If M$ need _setmode() the gnuwin32 does too otherwise there are things that
>you just can't do - mainly fixing stdin/stdout/stderr and pipes because
>you were given them in the wrong mode.
>
>Have I got this wrong???

D. Yes

>
>Thanks, Eric Mills.
>-
>For help on using this list (especially unsubscribing), send a message to
>"gnu-win32-request@cygnus.com" with one line of text: "help".
>

(jeffdbREMOVETHIS@netzone.com)
delete REMOVETHIS from the above to reply
         Mikey
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Bug in od, cat, etc reading binary files

[Eric Mills]

I want to add my comments to the above thread:

>Questions: How do I do these in the GNU-Win32 world? How do I:
>    * set the analog of MSVC++5.0's _fmode
>    * call the analog of MSVC++5.0's int _setmode(int handle, int mode)

Some time back I posted a request with the same questions under "text&binary
modes" and had no replies.

It seems to me that if one wants to port software into the NT environment
then one has no choice but to run the normal way NT programs do (without
the -b mount flag) otherwise your text files will confuse NT programs.
The binary mount is pretty useless: why would one want to run in your
own UNIX world on top of NT when the performance was so poor?
So the only real use for software like gnuwin32 is to move stuff over -
and then one is left with "When in Rome...."
If M$ need _setmode() the gnuwin32 does too otherwise there are things that
you just can't do - mainly fixing stdin/stdout/stderr and pipes because
you were given them in the wrong mode.

Have I got this wrong???

Thanks, Eric Mills.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Bug in od, cat, etc reading binary files

[Earnie Boyd]

>Date: Mon, 22 Sep 1997 11:03:56 -0400
>To: Eric De Mund <ead@ixian.com>, GNU-Win32 List <gnu-win32@cygnus.com>
>From: Larry Hall <lhall@rfk.com>
>Subject: Re: Bug in od, cat, etc reading binary files
>Cc: Joe Peterson <joe@jump.com>
>
>At 01:30 AM 9/22/97 -0700, Eric De Mund wrote:
>>GNU-Win32 People,
>>
>>    Joe Peterson <joe@jump.com> to <gnu-win32@cygnus.com>:
>>    ] Sorry if this is documented somewhere, but I could not find
>>    ] mention of it. I find that when, for example, using "od" to look
>>    ] at a binary file, if a ctrl-Z is encountered, the reading stops.
>>    ] This is because the fopen presumably does a "r" rather than a 
"rb"
>>    ] (a pc-ism).
>>    ]
>>    ] Other programs like "cat" and possibly others have this problem 
as
>>    ] well...
>>
>>GNU-Win32 cat(1) does have this problem, as does md5sum(1), rendering
>>them significantly less useful. It's the understanding of this Unix
>>developer new to the Windows world that the equivalent of Microsoft's
>>Visual C++ 5.0 Run-Time Library function _setmode(3) is required 
(global
>>variable _fmode in that development world setting the default file-
>>translation mode of all files *except* stdin, stdout, and stderr).
>>
>>Questions: How do I do these in the GNU-Win32 world? How do I:
>>    * set the analog of MSVC++5.0's _fmode
>>    * call the analog of MSVC++5.0's int _setmode(int handle, int 
mode)
>>
>>Thank you,
>>Eric De Mund
>>
>>"Magazines all too frequently lead to books and should be regarded by 
the
>>prudent as the heavy petting of literature." --Fran Lebowitz
>
>Eric,
>
>You're half right in your understanding.  The problem is due to "text"
>files in Windows and the need to open files in binary mode in order to
>"get things right".  You have 2 choices:
>
>  - Recompile offending code, either setting the mode or changing all
>    file open commands to use the "b" (for binary) flag.
>
>  - mount (via the mount command) your filesystems as binary (-b) so 
that
>    all files are automatically treated as binary just like in UNIX.  
This
>    step is usually the easiest and best in the long run but also tends
>    to cause short term headaches since all the "text" files that you 
>    currently have will be filled with <cr>s which bash and other 
things 
>    will barf on.  Reinstalling the system using cygwin tar/gzip or 
>    translating all your system files (at least) usually handles the 
>    problems.
>
>Larry Hall                              lhall@rfk.com
>RFK Partners, Inc.                      (781) 239-1053
>8 Grove Street                          (781) 239-1655 - FAX
>Wellesley, MA  02181                             
>
>-
>For help on using this list (especially unsubscribing), send a message 
to
>"gnu-win32-request@cygnus.com" with one line of text: "help".
>


Eric,

I chose the second option.  Check the mail archives for further info.

-        \\||//
---o0O0--Earnie--0O0o----
-earnie_boyd@hotmail.com-
------ooo0O--O0ooo-------


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Bug in od, cat, etc reading binary files

[Larry Hall]

At 01:30 AM 9/22/97 -0700, Eric De Mund wrote:
>GNU-Win32 People,
>
>    Joe Peterson <joe@jump.com> to <gnu-win32@cygnus.com>:
>    ] Sorry if this is documented somewhere, but I could not find
>    ] mention of it. I find that when, for example, using "od" to look
>    ] at a binary file, if a ctrl-Z is encountered, the reading stops.
>    ] This is because the fopen presumably does a "r" rather than a "rb"
>    ] (a pc-ism).
>    ]
>    ] Other programs like "cat" and possibly others have this problem as
>    ] well...
>
>GNU-Win32 cat(1) does have this problem, as does md5sum(1), rendering
>them significantly less useful. It's the understanding of this Unix
>developer new to the Windows world that the equivalent of Microsoft's
>Visual C++ 5.0 Run-Time Library function _setmode(3) is required (global
>variable _fmode in that development world setting the default file-
>translation mode of all files *except* stdin, stdout, and stderr).
>
>Questions: How do I do these in the GNU-Win32 world? How do I:
>    * set the analog of MSVC++5.0's _fmode
>    * call the analog of MSVC++5.0's int _setmode(int handle, int mode)
>
>Thank you,
>Eric De Mund
>
>"Magazines all too frequently lead to books and should be regarded by the
>prudent as the heavy petting of literature." --Fran Lebowitz

Eric,

You're half right in your understanding.  The problem is due to "text"
files in Windows and the need to open files in binary mode in order to
"get things right".  You have 2 choices:

  - Recompile offending code, either setting the mode or changing all
    file open commands to use the "b" (for binary) flag.

  - mount (via the mount command) your filesystems as binary (-b) so that
    all files are automatically treated as binary just like in UNIX.  This
    step is usually the easiest and best in the long run but also tends
    to cause short term headaches since all the "text" files that you 
    currently have will be filled with <cr>s which bash and other things 
    will barf on.  Reinstalling the system using cygwin tar/gzip or 
    translating all your system files (at least) usually handles the 
    problems.

Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      (781) 239-1053
8 Grove Street                          (781) 239-1655 - FAX
Wellesley, MA  02181                             

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: Bug in od, cat, etc reading binary files

[Eric De Mund]

GNU-Win32 People,

    Joe Peterson <joe@jump.com> to <gnu-win32@cygnus.com>:
    ] Sorry if this is documented somewhere, but I could not find
    ] mention of it. I find that when, for example, using "od" to look
    ] at a binary file, if a ctrl-Z is encountered, the reading stops.
    ] This is because the fopen presumably does a "r" rather than a "rb"
    ] (a pc-ism).
    ]
    ] Other programs like "cat" and possibly others have this problem as
    ] well...

GNU-Win32 cat(1) does have this problem, as does md5sum(1), rendering
them significantly less useful. It's the understanding of this Unix
developer new to the Windows world that the equivalent of Microsoft's
Visual C++ 5.0 Run-Time Library function _setmode(3) is required (global
variable _fmode in that development world setting the default file-
translation mode of all files *except* stdin, stdout, and stderr).

Questions: How do I do these in the GNU-Win32 world? How do I:
    * set the analog of MSVC++5.0's _fmode
    * call the analog of MSVC++5.0's int _setmode(int handle, int mode)

Thank you,
Eric De Mund

"Magazines all too frequently lead to books and should be regarded by the
prudent as the heavy petting of literature." --Fran Lebowitz
--
Eric De Mund <ead@ixian.com>  |  PGP Key Fingerprint:
http://www.ixian.com/ead/     |  5349b223 af6c2081 eddd4c81 aac9d1a5
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Bug in od, cat, etc reading binary files

[Joe Peterson]

Sorry if this is documented somewhere, but I could not find mention of
it.  I find that when, for example, using "od" to look at a binary file,
if a ctrl-Z is encountered, the reading stops.  This is because the
fopen presumably does a "r" rather than a "rb" (a pc-ism).

Other programs like "cat" and possibly others have this problem as
well...

				Joe
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".