From: marcus AT bighorn DOT dr DOT lucent DOT com Subject: Re: Bug in ... now text/binary mount points 30 Sep 1997 08:29:45 -0700 Message-ID: <199709301514.JAA28417.cygnus.gnu-win32@chorus.dr.lucent.com> To: gnu-win32 AT cygnus 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." 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 AT cygnus DOT com" with one line of text: "help".