This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Why text=binary mounts


Several people have made comments to the effect that MS development 
environments are somehow not as good as Unix for developing software.  I 
would be interested in hearing why that perception exists.  I do not 
believe that it is entirely accurate.  MS's Visual C++ 4.0 and 5.0 (the 
environments I use on a daily basis) are quite good, even for developing 
command-line programs, and I've heard a lot of people say Borland's is even 
better.

Yeah, you don't have the GNU make utility (I'll be deep in the cold, cold 
ground before I figure out how to use that one, and not for lack of 
trying).  Yeah, you don't have EMACS (how do you open a file with it?). 
 Yeah, no vi.

My point here is that it seems to me that MS/Borland have the distinct 
usability advantage, and like it or not, we're all users.  So what is Unix' 
advantage over MS when it comes to software development?  Is it simply that 
the GNU stuff is available free?

Gary R. Van Sickle (tiberius@braemarinc.com)
Electrical Design Engineer
Braemar Inc.
11481 Rupp Dr.
Burnsville, MN 55337
(612) 890-5135 Ext. 144
Fax: (612) 882-6550


-----Original Message-----
From:	marcus@bighorn.dr.lucent.com [SMTP:marcus@bighorn.dr.lucent.com]
Sent:	Monday, January 12, 1998 10:59 AM
To:	gnu-win32@cygnus.com
Subject:	Re: Why text=binary mounts

Tomas Fasth <tomas.fasth@twinspot.net> writes:
> Microsoft Windows dominates as a desktop platform. This does not
> necessarily mean that it's a preferred platform in general for program
> development. Note that I said 'preferred'. A great majority of the
> programmers today have to make their living developing for MS Windows.
> But that does not mean that all these programmers are putting their vote
> on it as the preferred environment for program development. As an
> example, the steady growth of installed Linux and FreeBSD systems says
> otherwise.

It is an unfortunate fact of life now that Microsoft software controls 85%
of the computers in the world.  That's pretty dominant, and unfortunately,
it will likely have a strong hold on that market share for quite some time
to come.  Unix may have had a chance back in the late 80s when there was
a big attempt to unify the Unix market to combat Microsoft, but alas the
effort was doomed to failure by the dark forces of entropy.  Since then, 
the
world has been being taken over by Microsoft...

If you are writing software that you want to sell to the largest group of
users, you have to address it to Microsoft.  Sure, the remaining 15% of the
market can buy some product, but not all that much, plus that 15% is split
between all of the non-MS world, so only a very small portion is actually
Unix, MacOS, etc.  So, if you want to appeal to the largest user base, you
really have to work in the MS world.  That's a pretty good reason to 
"prefer"
MS.  Not that it's the nicest environment to write code in, but because it
gives the better return on your programming investment.

> ... I'm talking about Mac ('\r'), Unix ('\n') and DOS ('\r\n'),
> where the Mac choice is by far most hostile to the programmer community,
> since it seem to have been made most recently...

I guess it is possible...  The MacOS CR delimiter certainly dates back to
the beginnings of AppleDOS on the Apple ][, around 1976 or so, I think. 
 The
CR LF of DOS comes by way of CP/M, which came from RT-11 (and other DEC 
PDP-11
OSs), so it came from the late 60s.  Unix actually seems to be the odd-ball
by using LF as the delimiter.  How many times have you gotten into raw 
mode,
where the return key no longer terminates you input lines?  Using CR as
the delimiter seems most intuitive, since that's actually what you usually
type to terminate a line.  CR LF makes sense because that's actually what
you send to a TTY or CRT terminal to go to the next line.  There were some
chain printers that used to use LF to move to the start of the next line, 
but
this was hardly common.

BTW, I think that it is Unix-centric to think of CR as \r and LF as \n.  I
always thought that the original intent was that \n would represent 
whatever
the local newline character was, whether it was LF or something else. I 
have
never seen this pairing broken, and I'm sure it was wreck havoc on many
programs if it was changed.

Gary R. Van Sickle wrote:
} And while we're at it, is JPG the right way, or is PNG the right way? To
}people, text is text.  Why should it not be the same for a 300MHz Pentium
}II.  Or your SparcStation.  Or the Mac.

> Be real. If text is text, then why can't images just be images? You are
> comparing different end-of-line schemes with different formats of image
> encoding. I'm sure you can find imaging tools on DOS, Mac and Unix that
> do not support each other's formats of encoding.

That is his point, that he is comparing different formats of text encoding
with different formats of image encoding.

While I do think that Gary's view of a text file manipulation library is a
good one, it is not the path that POSIX/ANSI has taken.  I'm actualy not 
sure
who originally invented the idea of adding "b" to fopen calls to select
binary files (and leave the default as a text mode open), but everybody 
seems
to have blessed it.

There might be more milage in working up a word processing abstract format,
similar to BFD, but for text processing documents.  Of course, since I have
spent some time using BFD, maybe I will retract this suggestion...

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

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]