AVR compilers

Started by mc January 9, 2005
"David" <david.nospam@westcontrol.removethis.com> wrote in message 
news:pan.2005.01.14.07.57.58.643000@westcontrol.removethis.com...

>> What about "/usr/local/bin" ;-) > > Much better - anything without spaces or other awkward characters. Of > course, in a *nix system this would be on your path, so you wouldn't have > to type it - and if you did, bash completion makes it much faster to type.
And anything you want can also be on your path in Windows too. Sheesh, don't people know Windows has paths??? In Windows we don't put all the executables (nor links to them) in one folder, because we expect everything to be bigger than UNIX -- more programs installed, etc. -- and it is.
"David" <david.nospam@westcontrol.removethis.com> wrote in message 
news:pan.2005.01.14.08.11.45.142000@westcontrol.removethis.com...
> On Thu, 13 Jan 2005 19:10:21 -0500, mc wrote:
> Yes, IIRC the use of / for arguments came from CP/M, which predates QDOS > (the anscestor of MSDOS). One less bullet hole for Bill, although there > are plenty left. However, he could have picked something else for the > directory seperator, since \ was a standard escape character (especially > for C) at the time.
Remember that UNIX and C weren't terribly widespread in 1981. Other operating systems with their own notations, such as VAX/VMS, were also poised to conquer the world. $AT $LEAST $WE $DON\'T $HAVE to use VAX/VMS notations! :)
> Anyway, things like the use of / are better described as being part of > posix, which is a much wider standard.
So use the Posix shell for Windows, if you want to. ("Windows Services for UNIX." A free download from Microsoft. There's really little reason to stick with the DOS-like command prompt; if you're serious about command prompts, you can get a UNIX-like one.)
"David" <david.nospam@westcontrol.removethis.com> wrote in message 
news:pan.2005.01.14.08.21.48.689000@westcontrol.removethis.com...

> You are unusual - very few use a full roaming profile setup (as distinct > from just file-server based home directories) successfully. The reason is > simple - lots of software doesn't work properly with it, because it is not > a natural way for windows to work. Many offices which need the effect of > roaming profiles prefer to use a windows terminal server setup instead, > although obviously that doesn't work for everything either.
Blame the software. Microsoft has been trying for *years* to get software to follow certain standards, but software authors (especially freeware) keep wanting to pretend that they're running DOS, and that everybody is administrator of his own machine. There actually is very, very little software that we can't run. We often have to fiddle with the way it installs itself, though. We complain loudly to manufacturers when software, for no good reason, has been rigged to be incompatible with multi-user Windows. Perhaps the only thing really wrong with Windows is that it's upward-compatible with DOS, so a lot of programmers have never quite realized that it's not DOS.
"Rich Webb" <bbew.ar@mapson.nozirev.ten> wrote in message 
news:9nkfu0ljh7tnj8qkfd1p0ap3s0budv3fmb@4ax.com...
> On Thu, 13 Jan 2005 19:10:21 -0500, "mc" <mc_no_spam@uga.edu> wrote: > >>Do all operating systems have to be JUST LIKE UNIX? Is UNIX the only good >>operating system the world ever saw? > > No, but for any system that uses C (or a relative) it's a PITA. > > printf("Enter backup path, formatted as \\\\machine\\dir\\subdir\\...");
So don't use C. Use C#, designed for Windows. You then have the option to put @ in front of a string to turn off escaping within it: Console.Write(@"Enter backup path, formatted as \\machine\dir\subdir\..."); Come to think of it, why not pop up an open file dialog and let the user use the GUI for what it's worth? I'll be the first to admit that if you want everything to work exactly like UNIX, then UNIX does that job better than Windows. I just don't think that should be the ideal.
Grant Edwards wrote:
>
... snip ...
> > Bah. MS-DOS system calls had always accepted "/" as the > directory path separator, and windows ones still do, dont' > they?. I know the C library calls certainly accept "/". > > For many, many years there was a switch in MS-DOS you could > throw that changed the option character to "-".
For all systems, back to and including CP/M, the "option char" has nothing to do with the OS, but is a characteristic of the individual programs, including the shell/CCP. Neither CP/M nor MsDOS 1.x had any concept of directory, however they did divide the file system into individual disks. Bill & brethren grafted Unix style directory hierarchy onto MsDOS 2.0, and this was the point at which the conflict appeared. Part of the problem is that MsDOS did not insist on separating the option char from the previous word with a blank. One more foolishness, only exceeded by allowing blanks within file and directory names, and also rechristening directories as folders. -- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson
mc <mc_no_spam@uga.edu> wrote:

> "David" <david.nospam@westcontrol.removethis.com> wrote in message > news:pan.2005.01.11.07.52.30.616000@westcontrol.removethis.com...
> > Just because "Program Files" is a convention, doesn't mean it is a good > > idea. In fact, it is an apallingly bad idea, and the microsoftie who > > thought of it should be strung up beside the even bigger halfwit who > > thought up the "my documents" scheme.
I think thhose are actually two copies of the very same scheme.
> I think naming it "Program Files" was a mistake.
I happen to believe they did that on purpose, with malicious intent. They did it to force down long filenames with spaces inside as deeply down every single customer's throat as they possibly could, and while at it, break as many third-party programs as possible in a single shot. In other words, they broke compatibility with shortname-only program on purpose, not by mistake. -- Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de) Even if all the snow were burnt, ashes would remain.
> I happen to believe they did that on purpose, with malicious intent. > > They did it to force down long filenames with spaces inside as deeply > down every single customer's throat as they possibly could, and while > at it, break as many third-party programs as possible in a single > shot. In other words, they broke compatibility with shortname-only > program on purpose, not by mistake.
On the other hand, this forces the third party vendors to do something about the problem with white space in names. There are still a few programs out there which does not accept space in filenames and this is irritating. -- Best Regards, Ulf Samuelsson. Ulf at atmel dot com These comments are intended to be my own opinion and they may, or may not be shared by my employer, Atmel Nordic AB.
"Ulf Samuelsson" <ulf@a-t-m-e-l.com> wrote in message 
news:34v9acF4h3tm2U1@individual.net...
>> I happen to believe they did that on purpose, with malicious intent. >> >> They did it to force down long filenames with spaces inside as deeply >> down every single customer's throat as they possibly could, and while >> at it, break as many third-party programs as possible in a single >> shot. In other words, they broke compatibility with shortname-only >> program on purpose, not by mistake. > > On the other hand, this forces the third party vendors to do something > about > the problem with white space in names. > There are still a few programs out there which does not accept space in > filenames > and this is irritating.
Yes... I agree with Ulf here. One of the biggest annoyances of Windows is that third party software vendors think the OS is much more restricted than it really is, and they want to impose their own restrictions on it (fixed install locations, no blanks in filenames, require everybody to write in folders that only administrators can write in, etc.). The purpose of operating systems is not merely to stagnate. Were computers perfect in 1978?
On Fri, 14 Jan 2005 10:34:16 -0500, mc wrote:

> > "David" <david.nospam@westcontrol.removethis.com> wrote in message > news:pan.2005.01.14.07.57.58.643000@westcontrol.removethis.com... > >>> What about "/usr/local/bin" ;-) >> >> Much better - anything without spaces or other awkward characters. Of >> course, in a *nix system this would be on your path, so you wouldn't have >> to type it - and if you did, bash completion makes it much faster to type. > > And anything you want can also be on your path in Windows too. Sheesh, > don't people know Windows has paths??? >
Of course I know it has paths. But because windows doesn't have proper links, I have a few directories in the path filled with either copies of executables (for small utilities) or little batch files for starting bigger programs. And I also know that windows (NT4 onwards) has file-name completion. It's not as good as that of bash (for many reasons), but it is a time-saver.
> In Windows we don't put all the executables (nor links to them) in one > folder, because we expect everything to be bigger than UNIX -- more programs > installed, etc. -- and it is.
Putting all executables into one folder is a bad idea - it is fine for small programs, but not idea for big programs with lots of extra bits and pieces. Putting links into one folder is an excellent idea - it is fast, organsied, easy to use, and flexible. Most *nix systems strike a good balance of a mixture of these. The reason windows doesn't do this is that to start with, it has virtually no small, self-contained programs (except for ports of *nix utilities), and it doesn't have symbolic links ("shortcuts" are less than half-way there). I presume the comment about windows systems having more programs was merely being sarcastic.
On Fri, 14 Jan 2005 10:36:26 -0500, mc wrote:

> > "David" <david.nospam@westcontrol.removethis.com> wrote in message > news:pan.2005.01.14.08.11.45.142000@westcontrol.removethis.com... >> On Thu, 13 Jan 2005 19:10:21 -0500, mc wrote: > >> Yes, IIRC the use of / for arguments came from CP/M, which predates QDOS >> (the anscestor of MSDOS). One less bullet hole for Bill, although there >> are plenty left. However, he could have picked something else for the >> directory seperator, since \ was a standard escape character (especially >> for C) at the time. > > Remember that UNIX and C weren't terribly widespread in 1981. Other > operating systems with their own notations, such as VAX/VMS, were also > poised to conquer the world. $AT $LEAST $WE $DON\'T $HAVE to use VAX/VMS > notations! :) > >> Anyway, things like the use of / are better described as being part of >> posix, which is a much wider standard. > > So use the Posix shell for Windows, if you want to. ("Windows Services for > UNIX." A free download from Microsoft. There's really little reason to > stick with the DOS-like command prompt; if you're serious about command > prompts, you can get a UNIX-like one.)
I do use a unix-like one regularly - cygwin and bash. Cygwin, along with other free (as in "free speach", not merely "cost-free download") software, makes windows a fairly complete system. Don't get me wrong - I think there are a lot of good things about windows, and there are plenty of bad things about *nix. There's place for both and for mixtures of systems. But MS has gone out of its way to make life awkward for "power users", such as those of use who can use more that two fingers when we type.