Re: Bug in ... now text/binary mount points

[marcus at bighorn dot dr dot lucent dot com]

OK, well, Larry had this to say and I agree:

}This whole argument seems somewhat repetitive and rehashed (perhaps
}I've been on this list too long!;-))

I agree, and this is the last post I will make on the subject, but I'd like
to redress a couple of points that came up...

Mikey (jeffdb"REMOVETHIS"@netzone.com) says:
.Unfortunately there seems to be some confusion over
.what a "native" file mode is, personally I think that
.worrying what the "native" file mode is in an emulation
.dll is kind of backwards, an emulation dll is there to
.create a non "native" environment in the first place
.so having cygwin32 open files in TEXT mode by default
.just because 95/NT do is rather silly ;^)
.AND breaks many otherwise working posix programs ;^(

Of course, the posix programs that break are those that open text files
as binary files.  Unfortunately, POSIX also specifies that the default
way to treat files is as text files (i.e. if there is no "b" in the fopen()
second argument).  So, if you make text and binary mean the same thing,
then sure, it doesn't matter how the program specifies to open the file.
But, in a portable environment, it *does* make a difference.  Seems similar
to the pointer/int cross-assignment problems (remember "The whole world isn't
a VAX"?).

. ... I highly recommend
.running that way [with mount -b ], it is the least surprise environment
.for un*x/posix programmers trying to move 
.software to win32. (the whole point NO?)

.Unfortunately if you work that way, when you
.send the software to your customers/buddys
.and they install it, it sets up the default text!=binary
.mount table, and you get calls wondering why
.things don't work ;^(

And that's entirely my point.  It seems that in a world where files are
shared between NT/W95 and cygwin programs, you are going to constantly get
calls wondering why things don't work unless you do the proper translation
of text files.  Simply sweeping it under the rug and mounting things binary
is fine so long as you are only doing cygwin programs, but when you try to
interact with other, non-cygwin programs, the text file incompatibilities
will bite you.

.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.

Actually, we do have support contracts for GnuPro compilers for UnixWare, MIPS,
and now NT.  We are actually paying a "porting fee" to support the NT compiler
on Solaris (although it compiles out of the box, it aparently isn't a supported
platform!).  Although this is not really the cygwin platform (we're really
looking for more of a mingw32 platform), we are a PAYING customer.

"justin." <suicide@freakz.org> also wrote:
-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.

But there would be more productivity gained if one could also use NT programs
and cygwin programs interchangably on the same files.  If they don't agree
on what a text file looks like, this can be very problematic.

Pete Jordan says:
]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?

Well, going the other way may be a problem.  I actually live in both worlds
a little differently since I develop on Solaris, currently for an NT
environment, so I don't actually try to use both environments on the same
files.  However, can you create a .BAT file with a cygwin based editor and
have it execute properly?  If you edit a shell script with NOTEPAD, will it
work?  The source files for cygwin and mingw32 are packed as NT text files
(with CR-LF).  If I untar them on solaris, gcc doesn't mind the extra CR in
most places, but if a #define is meant to continue to the next line and
ends in a backslash, the extra CR after that defeats the continuation and
this causes problems.  Presumably this would also be a problem if the file
is binary mounted under cygwin.


So, perhaps it isn't as much of a problem as seems likely to me.  I know that
there have been repeated posts to this list complaining about various problems
with text/binary file modes.  It seems to me that simply saying "mount
everyting binary" does cover up the problem within the cygwin world, but it
seems that this isolates the cygwin world from the rest of the NT/W95
environment and diminishes its usefulness.  However, maybe the interoperability
problems are not as great as I had thought.  Also, it seems that unlike the
Unix world where most files are text files or executables, it seems that the
MicroSoft world contains relatively few text files, so perhaps it isn't as
great a problem if they can't be shared between the two worlds.

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".