AVR compilers
mc
What do people think of each of these...?
CodeVision C for AVR
ImageCraft C for AVR
IAR C for AVR
gcc for AVR
BASCOM for AVR
Any of them notoriously good or notoriously bad?
Integration with AVR Studio and STK500 are desirable.
Jeroen
"mc" <mc_no...@uga.edu> wrote in message
news:41e0c8b3$1...@mustang.speedfactory.net...
I only have experience with ICCAVR, and I think it's quite a good compiler.
Easy to use, fast, cheap, generates reseonable code, a simple IDE, and works
well with AVRStudio. The Application Builder that generates initialisation
code is very handy.
Jeroen
Rich Webb
>OK, another deep theological question...
Yup. Nothin' like a Sunday to start a religious war. ;-)
>What do people think of each of these...?
>
>CodeVision C for AVR
Insufficient info.
>ImageCraft C for AVR
Great value. Excellent technical support. Source-level debugging with
AVR Studio (C statements as comments in the assembler output); programs
via the STK500. Active user community. Sensible constructs to
accommodate the AVR's Harvard architecture into C's point of view.
>IAR C for AVR
Expensive.
>gcc for AVR
GPL, which may or may not be an issue. Active user community.
>BASCOM for AVR
BASIC?
>Any of them notoriously good or notoriously bad?
Not really.
--
Rich Webb Norfolk, VA
Bryan Hackney
> On Sun, 9 Jan 2005 00:38:33 -0500, "mc" <mc_no...@uga.edu> wrote:
>
>
>>OK, another deep theological question...
>
>
> Yup. Nothin' like a Sunday to start a religious war. ;-)
>
>
>>What do people think of each of these...?
>>
>
>>gcc for AVR
>
>
> GPL, which may or may not be an issue. Active user community.
The GPL-ness of GCC is not an issue, and never has been. Support, or rather
someone to talk to when you get lonely, might be one.
[...]
Ulf Samuelsson
The IAR compiler is generally the one recommended by Atmel Norway,
due to its superior code generation. It has some amazing tricks.
* Global variables in registers.
* Will find identical code pieces and generate subroutines.
There is a free 4 k limited C compiler, but if you want more,
then it will set yuo back a significant amount.
On the other hand, I know Richard at Imagecraft is constantly looking to
improve code.
and is planning a free 4 kB compiler himself.
GCC is free, but I did not try it.
AVR Studio supports the file format of WinAVR (both to be downloaded from
www.avrfreaks.net)
and there will be tighter integration with AVR Studio this year
(actually any .3rd party C compiler can improve integtration, when this
function is released)
--
Best Regards,
Ulf Samuelsson u...@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB
David
It is for some people, either because they don't understand the gcc
licensing and mistakenly think it means their own code must be gpl'ed, or
because they *do* understand the licensing and know that this provides the
user with a guarentee of availability, flexibility, and reliability that
can't be achieved any other way.
gcc can produce some excellent optomised code - it benifits from all the
same front-end optomisations and extensions as other gcc ports. It is
also cross-platform, which is important to some people. The combination
of gcc with gdb and a selection of front-ends is flexible and powerful,
but it's not everyone's cup of tea. While the support is enthusiastic and
helpful (you are talking directly to the authors on the mailing list),
avr-gcc is not as friendly out-of-the-box as, say, ImageCraft (though
winavr goes some way towards this).
ImageCraft has always been synonymous with good support and ease of use.
IAR has (as far as I have heard - I haven't used IAR tools more than very
briefly, and never on an avr) a reputation for generating very small and
fast code, but I haven't heard "IAR" and "good service and support" in the
same sentence. Being Atmel's favourite compiler may give it some
advantages for the end user - the AVR is not, as Atmel claims, "C
friendly". It was designed and built as "IAR-C friendly", which is not
the same thing.
> [...]
Anton Erasmus
>OK, another deep theological question...
>
>
>What do people think of each of these...?
>
>CodeVision C for AVR
This is quite reasonable for a beginner. It comes with a lot of
libraries to drive all the peripherals and specific other devices
which are often used. To read the temperature from a 1Wire
DS18B20 and display it on a 2x16 line LDC display will take
even a beginner less than an hour.
Apparently it is a lot closer to Standard C than it used to be so
porting code to one of the more advanced compilers later
on should be fairly easy.
>ImageCraft C for AVR
>IAR C for AVR
>gcc for AVR
Imagecraft if you are on a budget. (They also have a version that
supports the RAMless AVRs properly)
IAR If you have a big budget and want to use the officially
recommended compiler by Atmel.
gcc if you want a good quality compiler for free, that can run under
most Osses used to develop under. If you are using gcc to develop
code for other MCUs, then it can have advantages even over the IAR
solution.
>BASCOM for AVR
Same sort of thing as CodeVision, except that it is a sort of basic.
Easy to get going with devices it supports, but if you want to use
something they do not support, then it is musch more difficult to
expand than a C solution would be.
>
>Any of them notoriously good or notoriously bad?
>
>Integration with AVR Studio and STK500 are desirable.
>
Of course the above is MHO.
Regards
Anton Erasmus
Johnny
>OK, another deep theological question...
>
>
>What do people think of each of these...?
>
>CodeVision C for AVR
This one is not very efficient compared to Imagecraft and IAR. Code
size was too big to get my approval.
>ImageCraft C for AVR
Excellent value and efficient compiler. I never had a problem with
using it in a commerical product. Integration with AVR studio is good
also.
>IAR C for AVR
Embedded workbench IDE tools are quite good. But I think the main
reason to buy it is if reliability is a top priority. On performance
basis, I found it is equivalent to Imagecraft.
>gcc for AVR
>BASCOM for AVR
Never tried these.
Dave Hansen
>OK, another deep theological question...
>
>
>What do people think of each of these...?
>
>CodeVision C for AVR
>ImageCraft C for AVR
>IAR C for AVR
>gcc for AVR
>BASCOM for AVR
We have both CodeVision and avr-gcc. I write my code to compile under
either (It's not as hard as you probably think).
CVAVR makes things extremely easy -- it'll write your initialization
code for you, including a skeletal framework with a "put your code
here" comment. It includes an IDE with single-button "check syntax"
and "build" commands. It includes a chip programmer that's fairly
easy to use, and can be invoked automatically upon a successful build,
it provides single-button interface to AVRStudio, it provides
libraries for common tasks like LCD interface, it even has a built-in
terminal for printf-type debugging. And it's cheap.
avr-gcc generates better code (unless you use a lot of library
routines -- CVAVR sacrifices C compatibility for smaller libraries),
but requires more work -- you need to learn how to use make, what all
the cryptic command-line options do, and find the other utilities you
need (like a programmer and simulator). But it's free. And it
complies better with the C standard. If you're running Windoze, look
for WinAVR, it's a complete installable package for avr-gcc including
editor, simulator, debugger, chip programmer, example makefile, etc.
in a single download. Makes entry that much easier.
CVAVR has some nice features for dealing with the Harvard architecture
of the AVR. For example, to have a table of constants stored in
flash, the code for CVAVR might look like
flash unsigned char table[] = {3, 2, 1};
...
result = value * table[idx];
The same code in avr-gcc would look something like
#include <avr\pgmspace.h>
...
unsigned char table [] PROGMEM = {3, 2, 1};
...
result = value * pgm_read_byte(&table[idx]);
Similarly, CVAVR gives you an EEPROM storage modifier that lets you
read and write EEPROM like RAM (at the source level, anyway...)
eeprom unsigned char calibration;
...
calibration = calibrate_instrument();
...
result = measure() * calibration;
Avr-gcc give you library routines to acces EEPROM.
HTH,
-=Dave
--
Change is inevitable, progress is not.
Jarek Pawelczyk
My number one is: IAR - great tool, works with asm and with C/EC++ :) And if
You have JTAG ICE
it's the best choice. You can debug programs with JTAG with C-Spy debbuger
included in IDE. Unfortunetly
there are no examples for this compiler. You have to try how to make
everything without help :(
Download trial version from IAR webpage and they give you new trial license
without problem when previous had expried.
And when you lern C for IAR compiler You can easily switch to other families
that IAR supports ARM,51,etc...
I haven't used ImageCraft and CodeVision because they don't have built in
debugger for JTAG ICE.
The next tool is GCC for AVR with Visual Micro Lab (www.amtools.net) IDE.
With VMLab you can
build virtual prototypes and I find it very useful. It automaticly generates
makefiles :). And GCC have one
of the best support. There is a lot of examples on internet. This one
doesn't support JTAG ICE debugging and
must be used with AVR Studio software.
BASCOM AVR - extremly simple, lot of examples and good support. I think it
have great programming module (I used it
instead of AVR ISP before I bought JTAG :) only for programming). Bascom
generates larger files than C or assembly. But if
you do only prototyping it's ok. There is a large library that contains many
useful functions such as 1-wire, I2C, RS, LCD and
simulator for them so prototype can be built in minutes !!! without writing
libraries on your own.
BTW my friend uses ImageCraft C compiler and AVR Studio for programming with
JTAG. He says that he won't change it for
anything else :)
Jaroslaw Pawelczyk
Rich Webb
<david....@westcontrol.removethis.com> wrote:
>On Sun, 09 Jan 2005 18:14:39 +0000, Bryan Hackney wrote:
>
>> Rich Webb wrote:
>>> On Sun, 9 Jan 2005 00:38:33 -0500, "mc" <mc_no...@uga.edu> wrote:
>>>
>>>
>>>>OK, another deep theological question...
>>>
>>>
>>> Yup. Nothin' like a Sunday to start a religious war. ;-)
>>>
>>>
>>>>What do people think of each of these...?
>>>>
>> [...]
>>>
>>>>gcc for AVR
>>>
>>>
>>> GPL, which may or may not be an issue. Active user community.
>>
>> The GPL-ness of GCC is not an issue, and never has been. Support, or rather
>> someone to talk to when you get lonely, might be one.
>>
>
>It is for some people, either because they don't understand the gcc
>licensing and mistakenly think it means their own code must be gpl'ed, or
>because they *do* understand the licensing and know that this provides the
>user with a guarentee of availability, flexibility, and reliability that
>can't be achieved any other way.
I'm with you all the way and I understand that the GPL is not "viral"
(as some large software empires might like people to believe) but that's
not the only issue.
Which license is used for the libraries that the AVR gcc port links
with, GLP or the LGPL? (Asking because I genuinely don't know; I'm a
happy ICC-AVR user.)
To paraphrase RMS's explanation of this: using the LGPL ("Lesser" or
(older usage) "Library" GPL) permits using the libraries in proprietary
programs; using the ordinary GPL for a library makes it available only
for free programs.
For many embedded systems the distinction might be moot, regardless of
which license is used, as the cost to the customer may be only "for the
hardware" but the firmware is "free."
mc
"Ulf Samuelsson" <u...@atmel.nospam.com> wrote in message
news:34en7tF...@individual.net...
>
> The IAR compiler is generally the one recommended by Atmel Norway,
> due to its superior code generation. It has some amazing tricks.
> * Global variables in registers.
> * Will find identical code pieces and generate subroutines.
> There is a free 4 k limited C compiler, but if you want more,
> then it will set yuo back a significant amount.
Is there a 4k limited version? All I saw on IAR's demo page was that it was
30-day-limited. I haven't downloaded it yet.
> On the other hand, I know Richard at Imagecraft is constantly looking to
> improve code.
> and is planning a free 4 kB compiler himself.
Right, I've downloaded that in "release candidate" form (ICC V7 RC4) and
there seem to be some problems with the way it installs -- I assume that is
just a matter of the way the setup file is constructed. (Sample projects
are missing files that ought to be in them, etc.) Also I keep getting the
error message "code location 0 already contains a value" from one of the
library files during linkage. What does that mean? Wrong version of the
library file?
Thanks!
mc
"Rich Webb" <bbe...@mapson.nozirev.ten> wrote in message
news:88p2u0d8s2tlc5aio...@4ax.com...
>>BASCOM for AVR
>
> BASIC?
Yes. BASIC has its uses in situations where adhocity is a virtue.
Thanks for the other information.
Grant Edwards
> Which license is used for the libraries that the AVR gcc port
> links with, GLP or the LGPL?
It's under GPL with an exception.
> (Asking because I genuinely don't
> know; I'm a happy ICC-AVR user.)
You're free to link libgcc into non-free code and distribute
the resulting binaries any way you want:
GPL + the runtime exception (from gcc/libgcc2.c):
GCC is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as
published by the Free Software Foundation; either version 2,
or (at your option) any later version.
In addition to the permissions in the GNU General Public
License, the Free Software Foundation gives you unlimited
permission to link the compiled version of this file into
combinations with other programs, and to distribute those
combinations without any restriction coming from the use of
this file. (The General Public License restrictions do apply
in other respects; for example, they cover modification of
the file, and distribution when not linked into a combine
executable.)
--
Grant Edwards grante Yow! Everybody is going
at somewhere!! It's probably
visi.com a garage sale or a disaster
Movie!!
la...@larwe.com
One thing I REALLY REALLY like about this toolchain is that it's
possible to put all the steps - compile, link and flash - in your
makefile. In particular, it's possible to put the fuse flags in your
make file, so you can "make flash" and get a totally blank chip
configured correctly. The absence of a method to specify fuses in the
main HEX file is a serious limitation of Atmel's upload systems.
You can also do a one-step flash, EEPROM and fuse setup command with a
little makefile tinkering. And if you have suitable external
command-line utilities, you can do an auto-read of the cal byte(s) and
put them into EEPROM.
You can integrate avrgcc with any programming text editor. uisp - the
most common companion ISP program - also supports the STK500
comprehensively, as well as numerous other programming interfaces.
Again, you can put a suitable target in your makefile to set the STK500
up to the correct Vcc and clock speed for your application.
It's very easy to use avrgcc, in fact it has to be the most painless
gcc variant I've ever built and used. I can't compare it against any
other AVR C compilers, but I like it :) And it works properly and
flawlessly under Linux, which is vitally important to me.
Richard M.
>>On the other hand, I know Richard at Imagecraft is constantly looking to
>>improve code.
>>and is planning a free 4 kB compiler himself.
>>
>>
>
>Right, I've downloaded that in "release candidate" form (ICC V7 RC4) and
>there seem to be some problems with the way it installs -- I assume that is
>just a matter of the way the setup file is constructed. (Sample projects
>are missing files that ought to be in them, etc.) Also I keep getting the
>error message "code location 0 already contains a value" from one of the
>library files during linkage. What does that mean? Wrong version of the
>library file?
>
>Thanks!
>
>
>
Can you be more specific with the "problem?" Double check the
Project->Options->Path to make sure the paths match where you install. I
just got the bright idea (ha ha) that I should modify the driver to
always look at <install root>\include for headers and <install root>\lib
instead of relying just on the settings in those boxes.
As for the "code location 0 already contains a value," I thought I fixed
that. Anyway, go to Project->Options->Target->Device and you probably
have "Custom" set up, which has text address as 0. I thought I changed
that to 2 :-) Anyway, location 0 already has the reset vector in the
startup code and hence you get that msg.
--
// richard
http://www.imagecraft.com
mc
"Richard M." <ric...@imagecraft.com> wrote in message
news:41E335E9...@imagecraft.com...
> Can you be more specific with the "problem?" Double check the
> Project->Options->Path to make sure the paths match where you install. I
> just got the bright idea (ha ha) that I should modify the driver to always
> look at <install root>\include for headers and <install root>\lib instead
> of relying just on the settings in those boxes.
I corresponded with support today - some of the example projects apparently
aren't right. The paths were correct. But I think your bright idea is a
good one.
> As for the "code location 0 already contains a value," I thought I fixed
> that. Anyway, go to Project->Options->Target->Device and you probably have
> "Custom" set up, which has text address as 0. I thought I changed that to
> 2 :-) Anyway, location 0 already has the reset vector in the startup code
> and hence you get that msg.
That was exactly it. I thought Application Builder would set the device
type in project options; it doesn't.
I need to get better at reading this assembly language. It's very nice to
be able to see the output of the compiler.
Thanks for responding!
Michael
P.S. How about installing in C:\Program Files? Or do you have components
that don't like long filenames? In general, I'm pretty picky about wanting
all my application software to follow Windows conventions. So far, I'm
pleased to see that you haven't made any of the common big blunders (the
most common of which is wanting to write in the install directory at run
time; on a secure machine, ordinary users don't have permission to write
there). Keep up the good work!
--
Michael Covington
Associate Director, Artificial Intelligence Center
The University of Georgia - www.ai.uga.edu/mc
CBFalconer
>
... snip ...
>
> To paraphrase RMS's explanation of this: using the LGPL ("Lesser"
> or (older usage) "Library" GPL) permits using the libraries in
> proprietary programs; using the ordinary GPL for a library makes
> it available only for free programs.
Correction - a GPLd library can be used in programs for sale,
however the program source must be freely available for at most the
cost of reproduction. At the same time the author of a GPLd
library can always license it under whatever terms he desires, and
thus remove any obligations on the part of the user.
Things owned by GNU and available under GPL do not have this
option, because GNU chooses not to so license their property.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Ulf Samuelsson
--
Best Regards,
Ulf Samuelsson u...@a-t-m-e-l.com
This is a personal view which may or may not be
share by my Employer Atmel Nordic AB
"mc" <mc_no...@uga.edu> skrev i meddelandet
news:41e29d49$1...@mustang.speedfactory.net...
David
>> gcc for AVR
>
> One thing I REALLY REALLY like about this toolchain is that it's
> possible to put all the steps - compile, link and flash - in your
> makefile. In particular, it's possible to put the fuse flags in your
> make file, so you can "make flash" and get a totally blank chip
> configured correctly. The absence of a method to specify fuses in the
> main HEX file is a serious limitation of Atmel's upload systems.
>
> You can also do a one-step flash, EEPROM and fuse setup command with a
> little makefile tinkering. And if you have suitable external
> command-line utilities, you can do an auto-read of the cal byte(s) and
> put them into EEPROM.
It's worth noting that you can do exactly the same with most other
compilers. Sometimes there are restrictions (for example, the trial
version of ImageCraft and, I believe, IAR, only run from within their
IDE), but most tools have command-line versions. When working with
ImageCraft's compiler, I have pretty much the same makefile as when using
avr-gcc (up to and including using cpp from gcc to generate dependancy
information automatically), and do a "make flash" in the same way.
David
>
> P.S. How about installing in C:\Program Files? Or do you have components
> that don't like long filenames? In general, I'm pretty picky about wanting
> all my application software to follow Windows conventions. So far, I'm
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. Most useful development tools are,
at heart, command line based (even if they have a pretty face on top), and
life is vastly easier if paths are shorter and preferably don't have
spaces. Just make yourself a "c:\progs" directory and put useful
development stuff in there, leaving "program files" for your open office,
firefox, the gimp, and other useful windowed programs.
David
>>>>
>>>>>gcc for AVR
>>>>
>>>>
>>>> GPL, which may or may not be an issue. Active user community.
>>>
>>> The GPL-ness of GCC is not an issue, and never has been. Support, or rather
>>> someone to talk to when you get lonely, might be one.
>>>
>>
>>It is for some people, either because they don't understand the gcc
>>licensing and mistakenly think it means their own code must be gpl'ed, or
>>because they *do* understand the licensing and know that this provides the
>>user with a guarentee of availability, flexibility, and reliability that
>>can't be achieved any other way.
>
> I'm with you all the way and I understand that the GPL is not "viral"
> (as some large software empires might like people to believe) but that's
> not the only issue.
>
Absolutely - and a good point to bring up.
> Which license is used for the libraries that the AVR gcc port links
> with, GLP or the LGPL? (Asking because I genuinely don't know; I'm a
> happy ICC-AVR user.)
>
There are two areas where the licenses are important for the run-time
system. There are the gcc libraries (which cover things like the code
generated by multiplication operators, or snippets used for interrupt
prologue and epilogues - i.e., routines that are generated by the compiler
rather than added by the linker), and the C support library (avr-libc).
Another poster has already quoted the gcc library license, which is GPL
with an exception to use it unrestricted at run-time. The avr-libc is a
modified BSD-style license, starting:
The contents of avr-libc are licensed with a Modified BSD License.
All of this is supposed to be Free Software, Open Source, DFSG-free,
GPL-compatible, and OK to use in both free and proprietary applications.
> To paraphrase RMS's explanation of this: using the LGPL ("Lesser" or
> (older usage) "Library" GPL) permits using the libraries in proprietary
> programs; using the ordinary GPL for a library makes it available only
> for free programs.
>
This sort of attitude is the difference between "open source" advocates
(who would of preference license a library under the LGPL, giving people
the freedom to choose their own license for their own code) and "free
software" advocates (who would of preference license a library under the
GPL, forcing users to make more code free).
It doesn't make much of a difference to users of embedded compilers like
avr-gcc - LGPL'ed code can be dynamically linked to non-(L)gpl'ed code but
not staticly linked. The idea is that if you sell a closed-source binary
which uses an LGPL'ed library, the end user can update their library and
still use it with the binary. That makes a lot of sense on big systems
(i.e., desktops or bigger), and means binaries can take advantage
of security fixes or improvements in libraries. But you may not staticly
link LGPL'ed code to non-(L)gpl'ed code without at least providing
unlinked object files (or source code) to the end user as well as the
binary. This is far from ideal for most embedded systems outside the
hobby and accademic arenas, so in general you must avoid LGPL'ed libraries
as well as GPL'ed code.
Of course, the above applies only to target libraries (i.e., the bits
running on the avr). Host libraries (as used by gcc itself, for example),
are an entirely different matter, and most users will either not care
about the particulars of the license, or see the GPL or LGPL as an
advantage.
> For many embedded systems the distinction might be moot, regardless of
> which license is used, as the cost to the customer may be only "for the
> hardware" but the firmware is "free."
You'll think differently if you use GPL'ed code in your embedded software
and your competitor, having bought one of your boards, has the legal right
to your source code. The GPL is a two-edged sword.
Richard M.
>"Richard M." <ric...@imagecraft.com> wrote in message
>news:41E335E9...@imagecraft.com...
>
>
>
>>Can you be more specific with the "problem?" Double check the
>>Project->Options->Path to make sure the paths match where you install. I
>>just got the bright idea (ha ha) that I should modify the driver to always
>>look at <install root>\include for headers and <install root>\lib instead
>>of relying just on the settings in those boxes.
>>
>>
>
>I corresponded with support today - some of the example projects apparently
>aren't right. The paths were correct. But I think your bright idea is a
>good one.
>
>
>
Hi Michael, you actually did catch a bug also - in the old days, due to
historical reasons, we shipped header files with names like
avr.h avrclassic.h <-- really ancient, like 1999 :-)
io8515.h ioM103.h etc.
io????v.h <-- latest
The last set, with the "v" suffix, has a consistent naming scheme for
the interrupt vector, so for example, you can write something like
#pragma interrupt_handler uart:UART_ISR
....
and by changing the initial #include from one header to another, you do
not need to manually adjust the vector # (one nitpick with the AVR si
that sometimes the vector moves between CPUs....)
Anyway, for V7, I figure we will get rid of the old and only supply the
io???v.h files and forgot to update all the examples projects. Oops.
>>As for the "code location 0 already contains a value," I thought I fixed
>>that. Anyway, go to Project->Options->Target->Device and you probably have
>>"Custom" set up, which has text address as 0. I thought I changed that to
>>2 :-) Anyway, location 0 already has the reset vector in the startup code
>>and hence you get that msg.
>>
>>
>
>That was exactly it. I thought Application Builder would set the device
>type in project options; it doesn't.
>
>
>
Not everyone uses the AppBuilder and some people use the AppBuilder to
"check out" the capability of the other CPUs, so there is no direct
tie-in in that sense. It goes the other way though, the AppBuilder will
pick up whatever you set in the Project option for the device target.
>I need to get better at reading this assembly language. It's very nice to
>be able to see the output of the compiler.
>
>
>
Yes, I think we have one of the more readable interspersed C and asm
listing around. I like the feature a lot when I was coding embedded
systems so it's a feature very important for me to get right.
>Thanks for responding!
>
>Michael
>
>
>P.S. How about installing in C:\Program Files? Or do you have components
>that don't like long filenames? In general, I'm pretty picky about wanting
>all my application software to follow Windows conventions. So far, I'm
>pleased to see that you haven't made any of the common big blunders (the
>most common of which is wanting to write in the install directory at run
>time; on a secure machine, ordinary users don't have permission to write
>there). Keep up the good work!
>
>
>
Shouldn't be any problems with spaces or long file names (well, not any
more anyway :-) ) The V6 licensing is a bit more PITA in that it does
want to write here and there and who knows where, which is one major
reason we are junking it on V7.
Thanks for your interests.
Ville Voipio
> You can integrate avrgcc with any programming text editor. uisp - the
> most common companion ISP program - also supports the STK500
> comprehensively, as well as numerous other programming interfaces.
Plus the nice added bonus of being able to specify the
programming cable pinout (at least avrdude allows this).
I do use the same cable for two types of CPLDs (with
a slightly modified Altera JAM player), ARM ISP functions
(with armtool) and AVRs (with avrdude). Making arrangements
like this with commercial tools is often impossible.
The quality of the code generated by avr-gcc is not always
optimal. However, the overhead is rather slight, and the
general optimization capabilities of gcc are good. Also,
the quality of the code has improved with new versions of gcc.
It would be nice to see comparisons between different compilers
with real-life applications. The unfortunate thing is that
the source code optimized for compiler A may be pessimized
for compiler B, so making such comparisons is difficult.
- Ville
--
Ville Voipio, Dr.Tech., M.Sc. (EE)
CBFalconer
>
... snip ...
>
> It would be nice to see comparisons between different compilers
> with real-life applications. The unfortunate thing is that
> the source code optimized for compiler A may be pessimized
> for compiler B, so making such comparisons is difficult.
However source code should be optimized for readability and
maintainability, and optimization left to the code generator. The
results should be quite viable for compiler comparisons.
This does not preclude algorithmic improvement.
Bryan Hackney
> On Mon, 10 Jan 2005 23:38:09 +0000, Rich Webb wrote:
>
>
> It doesn't make much of a difference to users of embedded compilers like
> avr-gcc - LGPL'ed code can be dynamically linked to non-(L)gpl'ed code but
> not staticly linked. The idea is that if you sell a closed-source binary
> which uses an LGPL'ed library, the end user can update their library and
> still use it with the binary. That makes a lot of sense on big systems
> (i.e., desktops or bigger), and means binaries can take advantage
> of security fixes or improvements in libraries. But you may not staticly
> link LGPL'ed code to non-(L)gpl'ed code without at least providing
> unlinked object files (or source code) to the end user as well as the
> binary. This is far from ideal for most embedded systems outside the
> hobby and accademic arenas, so in general you must avoid LGPL'ed libraries
> as well as GPL'ed code.
>
What you have said here is new and foreign to me. It's late, and I can't
think, but I wanted to post a big HUH? as a bookmark for later processing.
mc
"David" <david....@westcontrol.removethis.com> wrote in message
news:pan.2005.01.11....@westcontrol.removethis.com...
> On Mon, 10 Jan 2005 21:20:05 -0500, mc wrote:
>
>>
>> P.S. How about installing in C:\Program Files? Or do you have components
>> that don't like long filenames? In general, I'm pretty picky about
>> wanting
>> all my application software to follow Windows conventions. So far, I'm
>
> 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 naming it "Program Files" was a mistake. It should have been
"progs" for complete compatibility with software that doesn't recognize long
filenames, and for quicker typing. Likewise "Documents and Settings" should
have been "usr". Apart from that, I think it was a good idea.
"My documents" was a good idea too.
A lot of people don't seem to realize that this isn't 1988 and Windows isn't
DOS. Windows is a multi-user operating system and the location of "My
Documents" depends on how you're set up. For instance, in our lab, it's on
a shared disk on the network.
Also, ordinary users (non-administrators) don't have permission to write in
Program Files.
All of this should be familiar in UNIX, where ~ points to your home
directory wherever it is, and ordinary users don't write in /usr/local/bin.
But some Windows software developers don't seem to understand these
concepts. They get it into their head that the program *has* to be in some
particular place and the user *has* to be able to write in the install
directory.
Many Windows developers are also unaware that Windows has a command line and
that useful things can be done there.
To see it all done right, try Microsoft Visual Studio. To read a brief but
technically detailed rant on the subject, see
www.covingtoninnovations.com/michael/blog/0404/index.html#040401.
I hasten to add that ImageCraft C DOES NOT HAVE THESE FAULTS as far as I
can tell. Once I figured out that it doesn't select any processor by
default, I got it going just fine.
mc
>>That was exactly it. I thought Application Builder would set the device
>>type in project options; it doesn't.
>>
> Not everyone uses the AppBuilder and some people use the AppBuilder to
> "check out" the capability of the other CPUs, so there is no direct tie-in
> in that sense. It goes the other way though, the AppBuilder will pick up
> whatever you set in the Project option for the device target.
Ah! Now I know which order to run them in. Thanks!
(You're giving great support for a product I haven't paid a cent for! :)
Meindert Sprang
news:41e4...@mustang.speedfactory.net...
> I think naming it "Program Files" was a mistake. It should have been
> "progs" for complete compatibility with software that doesn't recognize
long
> filenames, and for quicker typing. Likewise "Documents and Settings"
should
> have been "usr". Apart from that, I think it was a good idea.
>
> "My documents" was a good idea too.
They're all bad ideas for another reason: they are different in the
different language versions of windows. Also,
windows itself uses both the long names as the short ones in the registry at
different places. A real mess.
I once bought an application that was in Dutch. It also contained a registry
patch, which pointed to the German version of "Program Files".....
geez......
No need to mention that it absolutely would not install properly on an
english Windows 2000......
> I hasten to add that ImageCraft C DOES NOT HAVE THESE FAULTS as far as I
> can tell. Once I figured out that it doesn't select any processor by
> default, I got it going just fine.
Imagecraft is just perfect. It doesn't even use pathnames in it's project
files, so you can just copy them to a different directory and recompile. A
big hand for Richard!
Meindert
mc
"Meindert Sprang" <mhsp...@NOcustomSPAMware.nl> wrote in message
news:10uapio...@corp.supernews.com...
> "mc" <mc_no...@uga.edu> wrote in message
> news:41e4...@mustang.speedfactory.net...
>> I think naming it "Program Files" was a mistake. It should have been
>> "progs" for complete compatibility with software that doesn't recognize
> long
>> filenames, and for quicker typing.
> They're all bad ideas for another reason: they are different in the
> different language versions of windows.
That's bad, but there is a Windows system call to find out the actual name
and location. (Program Files need not reside on C:.) People should use
these system calls or environment variables rather than hard-coding the
name.
Richard M.
>(You're giving great support for a product I haven't paid a cent for! :)
>
>
>
My philosophy is that while I can't please everyone all the time, at
least I should try with the reasonable requests. My experience is that
one p*off (non-)user can do more damage than 10 happy customers. We just
recently have a "lecturer" threatening to use us as a "bad example of
customer support" on his book or something. It was a long story, may be
one of these days we will put it up on the "Hall of Shame," especially
if said person actually would use us as an example. There are two sides
to every story...
To get back on topic: that space in filename support was a PITA. Took
forever to find all the places. I eventually got yet another bright idea
that: Windows "windowed" programs handle spaces fine. It's when we write
the paths to be used by command line programs that run into trouble. In
our case, the IDE generates the makefile, to be used by make, to invoke
the command line driver, which invokes different compiler passes (uh
oh...), and no amount of quoting seems to be sufficient :-) So we just
make sure that everywhere we may talk to a non-windowed program, we
convert long file names to short file names when there are spaces in the
names(ugh), and in the few places that we read info back from command
line programs, we do the reverse conversion. There are some systems that
don't support long/short name conversion, so we pop up a warning when
something weird may happen - for example, you may end up opening a file
twice, once with short name and once with long name, but it is rare to
happen (long filename is fine, just spaces that are difficult to
handle), and rare OS that has the problems (W98? I don't remember)
Richard M.
>Imagecraft is just perfect. It doesn't even use pathnames in it's project
>files, so you can just copy them to a different directory and recompile. A
>big hand for Richard!
>
>Meindert
>
>
>
The Salvo guy who ports his RTOS to lots of different compilers and
chips said ours is one of the easiest to create new project examples
precisely for this sort of reasons. We used to use absolute paths but
customers said that relative paths would be much easier to move and
share projects so I made the changes. A lot of the features of the
products are customer driven in that sense. One way to look at it is
that we have many times more customers than the companies that charge
20x our prices, so any ways to eliminate customers calling or emailing
us is a good thing :-)
mc
line arguments and makefiles?
c:> "C:\Program Files\myprog.exe" "this is a long filename.asm"
or the like?
UNIX allows spaces in filenames too -- isn't this how they do it?
mc
> mc wrote:
>
>>(You're giving great support for a product I haven't paid a cent for! :)
>>
> My philosophy is that while I can't please everyone all the time, at
> least I should try with the reasonable requests.
Right... Also, I may have been of some use to you as a tester, being a total
beginner, and thus not knowing what *not* to try! :)
Keep up the good work.
la...@larwe.com
Spaces are escaped in UNIX, at least at the command line. e.g. "/My\
Long\ Directory/filename".
Richard M.
Yes, the problem we had was that if we put quotes around the filename in
the makefile, the driver still needs to be modified to re-add the quotes
when it calls the compiler passes. Then all the different programs, e.g.
programs that look at the debug files, the map files etc. again have to
be carefully with preserving the quotes. All in all, a big mess.
mc
> Yes, the problem we had was that if we put quotes around the filename in
> the makefile, the driver still needs to be modified to re-add the quotes
> when it calls the compiler passes. Then all the different programs, e.g.
> programs that look at the debug files, the map files etc. again have to be
> carefully with preserving the quotes. All in all, a big mess.
Yes, it is. Compared to DOS, Windows has changed the rules on us much more
than is obvious.
Fortunately, you are allowed to put quotes around all file names, not just
those with blanks in them.
As I said, keep up the good work. These things must be frustrating.
David
>
> "David" <david....@westcontrol.removethis.com> wrote in message
> news:pan.2005.01.11....@westcontrol.removethis.com...
>> On Mon, 10 Jan 2005 21:20:05 -0500, mc wrote:
>>
>>>
>>> P.S. How about installing in C:\Program Files? Or do you have components
>>> that don't like long filenames? In general, I'm pretty picky about
>>> wanting
>>> all my application software to follow Windows conventions. So far, I'm
>>
>> 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 naming it "Program Files" was a mistake. It should have been
> "progs" for complete compatibility with software that doesn't recognize long
> filenames, and for quicker typing. Likewise "Documents and Settings" should
> have been "usr". Apart from that, I think it was a good idea.
>
> "My documents" was a good idea too.
The idea of having a single well-defined place (or a few places) for
programs is a good one - it is only the name that is bad. It is also only
half done - there is still endless piles of junk that gets installed under
the windows directory. Similarly, the idea of "My documents" is good
(infinitely better than the old "standard" of putting documents in the
creating program's directory), but the name is terrible, especially when
buried under several layers. Despite claims, desktop windows is still
basically a single-user system. Directories on a server need to be
seperated for different users, but on a desktop machine there are seldom
more than a couple of different users (and that's only really for home
machines). Why someone thought that a directory such as
"d:\Documents and Settings\David.DAVID1700\My Documents" is a good idea,
compared to just "d:\home\david" or even "d:\david" is beyond me.
ian_...@hotmail.com
mc
> Despite claims, desktop windows is still
> basically a single-user system.
Not in my lab. We have roaming user profiles. Any user can sit down at any
PC and get his own desktop and his own files. This quickly reveals to us
which pieces of software don't follow Windows standards!
> Why someone thought that a directory such as
> "d:\Documents and Settings\David.DAVID1700\My Documents" is a good idea,
> compared to just "d:\home\david" or even "d:\david" is beyond me.
It becomes David.1700 only if you've logged in 1700 times and each time the
machine crashed and didn't delete the previous one.
But in any case you can easily identify this directory through an
environment variable.
Anton Erasmus
<ric...@imagecraft.com> wrote:
[Snipped]
>
>To get back on topic: that space in filename support was a PITA. Took
>forever to find all the places.
[Snipped]
Under DOS and Windows there are many programs which cannot handle a
short 8.3 directory name that actually uses the extention field in the
directory name. I have'nt checked if Imagecraft does this.
Directory names such as
project.001
So if one has a path of c:\project.0\source\ver.0\main.c a hell of a
lot of software under DOS and Windows freaks out even though this
was allowed from the beginning.
Regards
Anton Erasmus
Rich Webb
<david....@westcontrol.removethis.com> wrote:
[we're getting 'way off topic but this IS usenet... ;-) ]
>machines). Why someone thought that a directory such as
>"d:\Documents and Settings\David.DAVID1700\My Documents" is a good idea,
>compared to just "d:\home\david" or even "d:\david" is beyond me.
Among all the reasons that Bill Gates should face a firing squad, the
"feature" of replacing the more-or-less industry standard forward slash
to separate path components with the more-or-less industry standard
escape character should be right up towards the top of the list.
--
Rich Webb Norfolk, VA
Ulf Samuelsson
components
> >>> that don't like long filenames? In general, I'm pretty picky about
> >>> wanting
> >>> all my application software to follow Windows conventions. So far,
I'm
> >>
> >> 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 naming it "Program Files" was a mistake. It should have been
> > "progs"
What about "/usr/local/bin" ;-)
> > for complete compatibility with software that doesn't recognize long
> > filenames, and for quicker typing. Likewise "Documents and Settings"
should
> > have been "usr". Apart from that, I think it was a good idea.
> >
> > "My documents" was a good idea too.
>
Learn Swedish and install Swedish Windows :-)
Then it is called "C:\Program" instead of "C:\Program Files"
--
Best Regards
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 Sweden.
mc
<ian_...@hotmail.com> wrote in message
news:1105608904.5...@f14g2000cwb.googlegroups.com...
> and after sending to support wait for a week before getting an answer.
Who? I've been getting nearly instant responses from ImageCraft and I'm not
even a paying customer (yet). (Next time my lab needs a lot of AVR
development setups, I know whose compiler I'm going to favor...)
mc
"Rich Webb" <bbe...@mapson.nozirev.ten> wrote in message
news:ecvdu05oldk3hd402...@4ax.com...
> Among all the reasons that Bill Gates should face a firing squad, the
> "feature" of replacing the more-or-less industry standard forward slash
> to separate path components with the more-or-less industry standard
> escape character should be right up towards the top of the list.
That predates him, or rather, it's a consequence of something that predates
him. When MS-DOS was acquired from Seattle Computer, / was already used to
introduce optional arguments. Bill was stuck with that, and couldn't change
it because application software was also doing it. So the directory
separator had to be \.
Do all operating systems have to be JUST LIKE UNIX? Is UNIX the only good
operating system the world ever saw?
David
>> >>> P.S. How about installing in C:\Program Files? Or do you have
> components
>> >>> that don't like long filenames? In general, I'm pretty picky about
>> >>> wanting
>> >>> all my application software to follow Windows conventions. So far,
> I'm
>> >>
>> >> 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 naming it "Program Files" was a mistake. It should have been
>> > "progs"
>
> 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.
>
>> > for complete compatibility with software that doesn't recognize long
>> > filenames, and for quicker typing. Likewise "Documents and Settings"
> should
>> > have been "usr". Apart from that, I think it was a good idea.
>> >
>> > "My documents" was a good idea too.
>>
> Learn Swedish and install Swedish Windows :-)
> Then it is called "C:\Program" instead of "C:\Program Files"
I live in Norway, so Swedish sounds to me like badly pronounced Norwegian :-)
In the Norwegian version of windows, it's called "c:\programfiler", which
is better than "Program Files", but not enough to make me switch!
David
>
> "Rich Webb" <bbe...@mapson.nozirev.ten> wrote in message
> news:ecvdu05oldk3hd402...@4ax.com...
>
>> Among all the reasons that Bill Gates should face a firing squad, the
>> "feature" of replacing the more-or-less industry standard forward slash
>> to separate path components with the more-or-less industry standard
>> escape character should be right up towards the top of the list.
>
> That predates him, or rather, it's a consequence of something that predates
> him. When MS-DOS was acquired from Seattle Computer, / was already used to
> introduce optional arguments. Bill was stuck with that, and couldn't change
> it because application software was also doing it. So the directory
> separator had to be \.
>
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.
> Do all operating systems have to be JUST LIKE UNIX? Is UNIX the only good
> operating system the world ever saw?
Can you think of a better one, for general purpose use? There have been
plenty of good OS'es which have come and gone, but *nix in all its forms
has survived. About the only serious competition for a solid, stable,
well-designed popular general-purpose OS was VMS, which has some
definite advantages over *nix, but which is being killed off by HP (for
reasons beyond the understanding of most people other than the
conspiricy-theorists).
Anyway, things like the use of / are better described as being part of
posix, which is a much wider standard.
David
>
> "David" <david....@westcontrol.removethis.com> wrote in message
> news:pan.2005.01.13....@westcontrol.removethis.com...
>
>> Despite claims, desktop windows is still
>> basically a single-user system.
>
> Not in my lab. We have roaming user profiles. Any user can sit down at any
> PC and get his own desktop and his own files. This quickly reveals to us
> which pieces of software don't follow Windows standards!
>
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.
>> Why someone thought that a directory such as
>> "d:\Documents and Settings\David.DAVID1700\My Documents" is a good idea,
>> compared to just "d:\home\david" or even "d:\david" is beyond me.
>
> It becomes David.1700 only if you've logged in 1700 times and each time the
> machine crashed and didn't delete the previous one.
Actually, the machine name is DAVID1700, so this indicates a
locally-authenticated user.
>
> But in any case you can easily identify this directory through an
> environment variable.
You can, to some extent - but it can cause other problems. I've got too
much software that I have to run to be able to mess too much with default
settings (even having windows installed on drive d: causes trouble
sometimes). I've also had windows (w2k) crash and corrupt a fair amount
of my "documents and settings" area, so I prefer to leave it for programs
that insist on using it, and store my files elsewhere.
Rich Webb
>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\\...");
etc. Not to mention that the damned '\' key is in a different location
on EVERY DAMNED KEYBOARD! <sigh>
Grant Edwards
>>> Among all the reasons that Bill Gates should face a firing
>>> squad, the "feature" of replacing the more-or-less industry
>>> standard forward slash to separate path components with the
>>> more-or-less industry standard escape character should be
>>> right up towards the top of the list.
>>
>> That predates him, or rather, it's a consequence of something
>> that predates him. When MS-DOS was acquired from Seattle
>> Computer, / was already used to introduce optional arguments.
>> Bill was stuck with that, and couldn't change it because
>> application software was also doing it. So the directory
>> separator had to be \.
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 "-".
--
Grant Edwards grante Yow! It's OKAY --- I'm an
at INTELLECTUAL, too.
visi.com
CBFalconer
>
... 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
Hans-Bernhard Broeker
> "David" <david....@westcontrol.removethis.com> wrote in message
> news:pan.2005.01.11....@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 (bro...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Ulf Samuelsson
>
> 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.
mc
> 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.)
mc
>> 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.
mc
"Rich Webb" <bbe...@mapson.nozirev.ten> wrote in message
> On Thu, 13 Jan 2005 19:10:21 -0500, "mc" <mc_no...@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.
mc
> 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.
mc
"Ulf Samuelsson" <u...@a-t-m-e-l.com> wrote in message
news:34v9acF...@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?
David
>
> "David" <david....@westcontrol.removethis.com> wrote in message
> news:pan.2005.01.14....@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.
David
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.
Dave Hansen
>
>"Rich Webb" <bbe...@mapson.nozirev.ten> wrote in message
>news:9nkfu0ljh7tnj8qkf...@4ax.com...
>> On Thu, 13 Jan 2005 19:10:21 -0500, "mc" <mc_no...@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\\...");
But the operating system (as opposed to the command.com) has _always_
accepted the forward slash as a directory separator in system calls.
Try it.
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
No thanks. Just another Microsoft "embrace and extend" trap.
Regards,
-=Dave
--
Change is inevitable, progress is not.
Rich Webb
>On Fri, 14 Jan 2005 10:40:57 -0500, "mc" <mc_no...@uga.edu> wrote:
>
>>
>>"Rich Webb" <bbe...@mapson.nozirev.ten> wrote in message
>>news:9nkfu0ljh7tnj8qkf...@4ax.com...
>>> On Thu, 13 Jan 2005 19:10:21 -0500, "mc" <mc_no...@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\\...");
>
>But the operating system (as opposed to the command.com) has _always_
>accepted the forward slash as a directory separator in system calls.
>Try it.
Yup, I know. The printf() example was a plucked-from-midair attempt to
dummy-up a "user prompt" that would need the extra escapes to show
something in the expected form.
>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
>
>No thanks. Just another Microsoft "embrace and extend" trap.
Isn't "embrace, extend, eliminate" the complete quote? Not that MS would
ever want to eliminate standard C or C++ in favor of C#. Would they?
mc
"Rich Webb" <bbe...@mapson.nozirev.ten> wrote in message
>>>So don't use C. Use C#, designed for Windows. You then have the option
>>>to
>>
>>No thanks. Just another Microsoft "embrace and extend" trap.
>
> Isn't "embrace, extend, eliminate" the complete quote?
Quoting whom?
> Not that MS would
> ever want to eliminate standard C or C++ in favor of C#. Would they?
I would like to eliminate them both in favor of anything that is not so
error prone. C and C++ are designed around the false belief that the
programmer will never make a mistake and the data will never overflow the
buffer. See:
http://c2.com/cgi/wiki?CeeLanguageAndBufferOverflows
I refer to C as UPL (Uninitialized Pointer Language). It has introduced
whole classes of bugs and security holes that would never existed (except
maybe in ham-fisted assembly code).
I like C# because it has the syntactic conciseness of C++ with the
clear-headedness of the Pascal/Modula/Oberon tradition. It was invented by
Anders Hejlsberg, the impementor of Turbo Pascal, whom Microsoft hired away
from Borland. I wish there were C# compilers that were not tied to the
Microsoft .NET environment; in principle, this is possible, although it
might have to be a subset implementation. Even a non-object-oriented C#
subset, for expressing algorithms, would be very nice to use on micros.