Beginner's guide to MinGW?
MikeC
I know this isn't a C-language related question, but before I get into C, I
have to have a compiler.
In fact, I have been using DJGPP for many years, but I have recently
upgraded to a 64-bit CPU machine, and the old DOS programs I wrote with it,
and DJGPP itself, won't run on it. For this reason, I'd like to upgrade to
MinGW, and I'm sure there are people on this user group that could point the
way.
What I'm looking for is a really simple manual that will hold my hand till I
get going, and have compiled and run my first C program. After that, I
should be OK.
I tried the user forum on the MinGW site, but found them none too helpful.
It's populated by people who don't willingly tolerate newbies.
I have found a fair amount on the web about it, but it's all about other
languages, and I want something that specifically tells me how to compile
and run a C program. I've been trying for a long time, but I'm clearly not
understanding something.
Many thanks,
MikeC
jacob navia
Well,use lcc-win. It is a free compiler that is MUCH easier to use for a
beginner than mingw.
http://www.q-software-solutions.de
Download the tutorial too, that explains the C language and learns you
how to get up and running in C.
jacob
Disclaimer:
This message is written by the author of lcc-win. So, it is a biased
advice. Use with care :-)
osmium
"MikeC" <my.address@end_of.post> wrote in message
news:U5Kdnb46e_RmXwvW...@bt.com...
To compile a C program, type the source file name and end the name with
".c". Do not fiddle with the OS settings. If you do not provide an
extension, .c++ will be provided automatically. Because of these rules, C++
programs are easier to compile and run. It is quite easy to forget you are
"doing" c if you change the file name often, as I sometimes do with trivial
programs.
There is a book designed expressly for your situation, _C++ Weekend Crash
Course_ by Stephen Davis. It includes an old version of the MingW compiler
to get you started. Of course you will need a floppy disk to use the pre
pack one.
Mark Hobley
> I'd like to upgrade to
> MinGW, and I'm sure there are people on this user group that could point the
> way.
Hi Mike. The only information I have on this is a simple hello world program:
http://markhobley.yi.org/mingw/helloworld/index.html
You will need to run this from within Cygwin on a Microsoft Windows based
machine.
At the time of writing, that was written for an i586 based system. The 64 bit
compiler may have a different prefix on the name. I haven't really looked at
this.
Here are some notes that I have on Cygwin:
http://markhobley.yi.org/cygwin/index.html
I don't know where in the country you are, but if you are within reach of the
Staffordshire or West Midlands area, I could have a look at this with you to
see if we can get you up and running.
Mark.
--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/
Phred Phungus
If you two ever cruise through New Mexico, come rig me up with it too.
My mingw experience was never what it promised to be. I wouldn't say
"user error" was the problem; I would say that "user's mound of errors"
definitely was.
--
fred
Phred Phungus
Mike, there's worse advice to take than this. Jacob gets thrown around
here like a chew toy, but lcc was one of the better C options I had on
windows. It was very good in spots.
--
fred
MikeC
"MikeC" <my.address@end_of.post> wrote in message
news:U5Kdnb46e_RmXwvW...@bt.com...
Folks,
Thanks to one and all. I'm in Basingstoke, so not really convenient for
Staffordshire, but I'll follow up the links tomorrow night and see where I
get.
Thanks again,
Mike.
>
MikeC
"Phred Phungus" <Ph...@example.invalid> wrote in message
news:7vo7ib...@mid.individual.net...
It's a great idea Fred, I was in Albuquerque some years ago and thought it
a really nice spot. Really nice!
Thanks to everybody who responded. It's a bit late now (01:00), but I'll
follow up the links tomorrow night - uh, sorry - today night.
All of the Best,
MikeC.
REH
Look at the manuals at the GCC site (gcc.gnu.org). MinGW is not much
more than GCC targeted for Windows. You create and compile programs
the same as you would any installation of GCC. There are GUI frontends
to MinGW, but I prefer just an editor and makefiles (or actually JAM
files these days). A simple example:
gcc -o hello.exe hello.c
from the command prompt would compile the file hello.c and create the
executable hello.exe.
REH
REH
> To compile a C program, type the source file name and end the name with
> ".c". Do not fiddle with the OS settings. If you do not provide an
> extension, .c++ will be provided automatically. Because of these rules, C++
> programs are easier to compile and run. It is quite easy to forget you are
> "doing" c if you change the file name often, as I sometimes do with trivial
> programs.
>
I think you are describing something other than MinGW itself, possibly
someone's frontend (such as Visual MinGW or Dev-C++) or possibly the
behavior of your own editor.
REH
Nick Keighley
> MikeC a crit :
> > I know this isn't a C-language related question, but before I get into
> > C, I have to have a compiler.
> > In fact, I have been using DJGPP for many years, but I have recently
> > upgraded to a 64-bit CPU machine, and the old DOS programs I wrote with
> > it, and DJGPP itself, won't run on it. For this reason, I'd like to
> > upgrade to MinGW, and I'm sure there are people on this user group that
> > could point the way.
>
> > What I'm looking for is a really simple manual that will hold my hand
> > till I get going, and have compiled and run my first C program. After
> > that, I should be OK.
> > I tried the user forum on the MinGW site, but found them none too
> > helpful. It's populated by people who don't willingly tolerate newbies.
>
> > I have found a fair amount on the web about it, but it's all about other
> > languages, and I want something that specifically tells me how to
> > compile and run a C program. I've been trying for a long time, but I'm
> > clearly not understanding something.
>
> Well,use lcc-win. It is a free compiler that is MUCH easier to use for a
> beginner than mingw.
>
> http://www.q-software-solutions.de
>
> Download the tutorial too, that explains the C language and learns you
> how to get up and running in C.
>
> Disclaimer:
> This message is written by the author of lcc-win. So, it is a biased
> advice. Use with care :-)- Hide quoted text -
Microsoft's "Visual C++ Express" is another free compiler. And despite
the weird name it compiles bog-standard C. Reasonable IDE. Some say it
is a very large download. I can't say I noticed.
Kenny McCormack
Nick Keighley <nick_keigh...@hotmail.com> wrote:
...
>Microsoft's "Visual C++ Express" is another free compiler. And despite
>the weird name it compiles bog-standard C. Reasonable IDE. Some say it
>is a very large download. I can't say I noticed.
Note that compilers from MS only compile some old version of standard C.
MS has not kept up-to-date with the current standard.
Nick Keighley
> In article <8570349a-efc2-432a-b7e4-61e88c299...@q16g2000yqq.googlegroups.com>,
> Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
> >Microsoft's "Visual C++ Express" is another free compiler. And despite
> >the weird name it compiles bog-standard C. Reasonable IDE. Some say it
> >is a very large download. I can't say I noticed.
>
> Note that compilers from MS only compile some old version of standard C.
> MS has not kept up-to-date with the current standard.
but happily Microsoft are completly up to date with the most portable
version of the C standard (1989/1990). They do try and encourage you
to use some odd extensions though. [disable the warning about "using
unsafe function strcpy"]
Branimir Maksimovic
Is C++ completely compatible with C 89/90? Basic idea of C++ is
to be compatible with C, while you can use syntactic sugar in
order to write less code.
Problem is now if they are not compatible and let's say if you write
C/C++ you can;t write C99/C++ ;)
Technically one would expect same behavior, but if one is used to
C++ now it is difficult to move to C99 or vice versa.
Greets
Sometimes online sometimes not
Richard
> On Thu, 11 Mar 2010 03:40:45 -0800 (PST)
> Nick Keighley <nick_keigh...@hotmail.com> wrote:
>
>> On 11 Mar, 10:58, gaze...@shell.xmission.com (Kenny McCormack) wrote:
>> > In article
>> > <8570349a-efc2-432a-b7e4-61e88c299...@q16g2000yqq.googlegroups.com>,
>> > Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
>>
>> > >Microsoft's "Visual C++ Express" is another free compiler. And
>> > >despite the weird name it compiles bog-standard C. Reasonable IDE.
>> > >Some say it is a very large download. I can't say I noticed.
>> >
>> > Note that compilers from MS only compile some old version of
>> > standard C. MS has not kept up-to-date with the current standard.
>>
>> but happily Microsoft are completly up to date with the most portable
>> version of the C standard (1989/1990). They do try and encourage you
>> to use some odd extensions though. [disable the warning about "using
>> unsafe function strcpy"]
>
> Is C++ completely compatible with C 89/90? Basic idea of C++ is
> to be compatible with C, while you can use syntactic sugar in
> order to write less code.
LOL. What a load of nonsense. That is not the "Basic idea of C++" at
all. Where on earth did you learn that?
> Problem is now if they are not compatible and let's say if you write
> C/C++ you can;t write C99/C++ ;)
>
> Technically one would expect same behavior, but if one is used to
> C++ now it is difficult to move to C99 or vice versa.
No it isn't. They are different languages with a similar subset.
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
Branimir Maksimovic
Well, first target audience for C++ were C programmers.
So basically C with classes was original idea.
>
> > Problem is now if they are not compatible and let's say if you write
> > C/C++ you can;t write C99/C++ ;)
> >
> > Technically one would expect same behavior, but if one is used to
> > C++ now it is difficult to move to C99 or vice versa.
>
> No it isn't. They are different languages with a similar subset.
Oh, unfortunately they are different languages, not fortunately.
Have you ever thought why is C99 not so successful and widely
adopted? VC++ note "++" in it's name ;)
Richard
So what? Its nothing to so with "syntactic sugar" to write less code.
>>
>> No it isn't. They are different languages with a similar subset.
> Oh, unfortunately they are different languages, not fortunately.
> Have you ever thought why is C99 not so successful and widely
> adopted? VC++ note "++" in it's name ;)
They are different languages. I dont know what you are trying to say. C
was always going to fall by the wayside as OO language attracted the
masses.
>
> Greets
REH
> Oh, unfortunately they are different languages, not fortunately.
Why unfortunately? If they were the same, why even bother having both?
REH
Branimir Maksimovic
Because one want to program in C and use some features from C++
on top of C code.
I mean things would be simpler. Basic idea is compatibility.
and c++ is C89/90 based language with added exceptions,
templates (automatic calling of init/deinit, copy, assign functions
that take first parameter as struct) and syntactic sugar.
osmium
Surely, someone must have used the dreaded word "subset" in this thread.
The notion of a subset can be very helpful. For example, I don't know of
*anyone* that has a handle on the complete list of words used in the English
language.
This is not meant to imply that a subset in the C/C++ case was *possible*,
just that it could have been a nice goal. Which is not meant to imply that
it in fact was a goal.
As I see it, the C-C++ relationship was "get the camel into the tent".
Richard Bos
> On 9 Mar, 22:20, jacob navia <ja...@jacob.remcomp.fr> wrote:
> > MikeC a crit :
>
> > > I know this isn't a C-language related question, but before I get into
> > > C, =A0I have to have a compiler.
> > Well,use lcc-win. It is a free compiler that is MUCH easier to use for a
> > beginner than mingw.
> > Disclaimer:
> > This message is written by the author of lcc-win. So, it is a biased
> > advice. Use with care :-)- Hide quoted text -
>
> Microsoft's "Visual C++ Express" is another free compiler. And despite
> the weird name it compiles bog-standard C. Reasonable IDE. Some say it
> is a very large download. I can't say I noticed.
Dev-C++ is another, rather simple but efficient one; Code::Blocks yet
another. Both of those are based on gcc+MinGW. PellesC is another
implementation based on lcc.
For starters, my favourite would be Dev-C++. If you want to build a real
project, one of the others may be more your thing.
Richard
Seebs
> Because one want to program in C and use some features from C++
> on top of C code.
Bad idea.
If you're going to write C++, write C++. Using little bits of C++ creates
particularly unmaintainable code, because no two people trying to use
"just a little" C++ will pick the same features. You'll thus have some hunks
of code using C idioms and some using C++ idioms for the same things.
> I mean things would be simpler. Basic idea is compatibility.
Not really, anymore. There's some compatibility, but it's not really all
that much, and I don't think it's particularly good to try to rely on it.
> and c++ is C89/90 based language with added exceptions,
And some overlap with C99.
> templates (automatic calling of init/deinit, copy, assign functions
> that take first parameter as struct) and syntactic sugar.
It's a lot more than that, now. C with Classes was pretty much just syntactic
sugar. C++ is really a pretty distinct language.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Branimir Maksimovic
Seebs <usenet...@seebs.net> wrote:
> On 2010-03-11, Branimir Maksimovic <bm...@hotmail.com> wrote:
> > Because one want to program in C and use some features from C++
> > on top of C code.
>
> Bad idea.
>
> If you're going to write C++, write C++. Using little bits of C++
> creates particularly unmaintainable code, because no two people
> trying to use "just a little" C++ will pick the same features.
Hm, you can;t write c++ , especially if doing low level things.
But put on top c++ classes and syntactic sugar, wrap it up
no problem ;)
> You'll thus have some hunks of code using C idioms and some using C++
> idioms for the same things.
Well, that depends on how things are organized.
You can have pure C modules and C++ modules linked in one program.
>
> > I mean things would be simpler. Basic idea is compatibility.
>
> Not really, anymore. There's some compatibility, but it's not really
> all that much, and I don't think it's particularly good to try to
> rely on it.
True ;(
No, that is not useful for pragmatic approach.
>
> > and c++ is C89/90 based language with added exceptions,
>
> And some overlap with C99.
C99 grrrrr. ;)
>
> > templates (automatic calling of init/deinit, copy, assign functions
> > that take first parameter as struct) and syntactic sugar.
>
> It's a lot more than that, now. C with Classes was pretty much just
> syntactic sugar. C++ is really a pretty distinct language.
Unfortunately.
Greets!
REH
> On Thu, 11 Mar 2010 05:52:02 -0800 (PST)
>
> > On Mar 11, 7:19 am, Branimir Maksimovic <bm...@hotmail.com> wrote:
> > > Oh, unfortunately they are different languages, not fortunately.
>
> > Why unfortunately? If they were the same, why even bother having both?
>
> Because one want to program in C and use some features from C++
> on top of C code.
> I mean things would be simpler. Basic idea is compatibility.
> and c++ is C89/90 based language with added exceptions,
> templates (automatic calling of init/deinit, copy, assign functions
> that take first parameter as struct) and syntactic sugar.
If you want to program in C++, do so. If you want C, then program in
C. The languages are more different then you think. Even simple things
likes the types of character or enumeration literals, and the rules
for "main" are different. Other subtleties will eventually bite you. C
has tentative declarations. C++ does not. C has implicit conversions
that C++ does. const in C and C++ is very different. And much more...
The C++ core language is much more different from C90 than you
describe it.
REH
REH
> If you want to program in C++, do so. If you want C, then program in
> C. The languages are more different then you think. Even simple things
> likes the types of character or enumeration literals, and the rules
> for "main" are different. Other subtleties will eventually bite you. C
> has tentative declarations. C++ does not. C has implicit conversions
> that C++ does. const in C and C++ is very different. And much more...
> The C++ core language is much more different from C90 than you
> describe it.
>
Err, I mean "tentative definitions."
REH
Nick Keighley
> On Thu, 11 Mar 2010 13:09:16 +0100
> Richard <rgrd...@gmail.com> wrote:
> > Branimir Maksimovic <bm...@hotmail.com> writes:
> > > On Thu, 11 Mar 2010 03:40:45 -0800 (PST)
> > > Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
> > >> On 11 Mar, 10:58, gaze...@shell.xmission.com (Kenny McCormack)
> > >> > Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
<snip>
> > >> > >Microsoft's "Visual C++ Express" is another free compiler. And
> > >> > >despite the weird name it compiles bog-standard C. [...]
Note Well: it compiles C. In other words the package includes a C
compiler as well as a C++ compiler.
<snip>
> > >> [...] Microsoft are completly up to date with the most
> > >> portable version of the C standard (1989/1990). [...]
>
> > > Is C++ completely compatible with C 89/90? Basic idea of C++ is
> > > to be compatible with C, while you can use syntactic sugar in
> > > order to write less code.
>
> > LOL. What a load of nonsense. That is not the "Basic idea of C++" at
> > all. Where on earth did you learn that?
>
> Well, first target audience for C++ were C programmers.
> So basically C with classes was original idea.
C++ is a lot more than "C with classes". I don't think Bjarne
Stroustrup ever had the motives you attribute to him. He wasn't trying
to superset C.
> > > Problem is now if they are not compatible and let's say if you write
> > > C/C++ you can;t write C99/C++ ;)
>
> > > Technically one would expect same behavior, but if one is used to
> > > C++ now it is difficult to move to C99 or vice versa.
>
> > No it isn't. They are different languages with a similar subset.
AOL: I quite agree
> Oh, unfortunately they are different languages, not fortunately.
It's neither fortunate nor unfortunate; merely true.
> Have you ever thought why is C99 not so successful and widely
> adopted? VC++ note "++" in it's name ;)
despite the name VC++ includes a C compiler (though not a C99
compiler)
If I were naming it it would be called "Microsoft C and C++ Compiler
Package" but Microsoft marketing never contacted me about a job.
--
Sesame Street today is brought to you by the number e
and the colour 1850K!
Kenny McCormack
Nick Keighley <nick_keigh...@hotmail.com> wrote:
>On 11 Mar, 12:19, Branimir Maksimovic <bm...@hotmail.com> wrote:
>> On Thu, 11 Mar 2010 13:09:16 +0100
>> Richard <rgrd...@gmail.com> wrote:
>> > Branimir Maksimovic <bm...@hotmail.com> writes:
>> > > On Thu, 11 Mar 2010 03:40:45 -0800 (PST)
>> > > Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
>> > >> On 11 Mar, 10:58, gaze...@shell.xmission.com (Kenny McCormack)
>> > >> > <8570349a-efc2-432a-b7e4-61e88c299...@q16g2000yqq.googlegroups.com>,
>> > >> > Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
>
><snip>
>
>> > >> > >Microsoft's "Visual C++ Express" is another free compiler. And
>> > >> > >despite the weird name it compiles bog-standard C. [...]
>
>Note Well: it compiles C. In other words the package includes a C
An old, non-current version of 'C'.
Keith Thompson
> On 11 Mar, 12:19, Branimir Maksimovic <bm...@hotmail.com> wrote:
>> Well, first target audience for C++ were C programmers.
>> So basically C with classes was original idea.
>
> C++ is a lot more than "C with classes". I don't think Bjarne
> Stroustrup ever had the motives you attribute to him. He wasn't trying
> to superset C.
"C with classes" was the original name of the language.
[...]
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Branimir Maksimovic
Keith Thompson <ks...@mib.org> wrote:
> Nick Keighley <nick_keigh...@hotmail.com> writes:
> > On 11 Mar, 12:19, Branimir Maksimovic <bm...@hotmail.com> wrote:
> [...]
> >> Well, first target audience for C++ were C programmers.
> >> So basically C with classes was original idea.
> >
> > C++ is a lot more than "C with classes". I don't think Bjarne
> > Stroustrup ever had the motives you attribute to him. He wasn't
> > trying to superset C.
>
> "C with classes" was the original name of the language.
>
> [...]
>
Problem with c++ is that Bjarne imposed rules on language which
what he considered "good C". Somthing like java did for C++.
Other thing is that because of function overloading he had
to use name mangling which made language pretty useless
for interfacing with another languages...
Other thing is exceptions which violate rule "what you
don;t use you don;t have cost".
But c++ is most closest to C still, and there is no
other language that can successfully replace assembler
then C.
Other languages that used C syntax and don;t have to
do anything with C are rather pointless IMO. ;)
Greets!
Nathan
>
> > "C with classes" was the original name of the language.
>
> > [...]
>
> Problem with c++ is that Bjarne imposed rules on language which
> what he considered "good C". Somthing like java did for C++.
> Other thing is that because of function overloading he had
> to use name mangling which made language pretty useless
> for interfacing with another languages...
> Other thing is exceptions which violate rule "what you
> don;t use you don;t have cost".
> But c++ is most closest to C still, and there is no
> other language that can successfully replace assembler
> then C.
Before we declare this "successfully replace" status, I think we
should put it to a test.
int main(void)
{
unsigned ebx;
unsigned ecx;
ebx = 5;
for (ecx = 0; ecx < 5; ecx++)
{
ebx++;
}
return 42;
}
$ gcc -c -o asm.o asm.c
$ objdump -d asm.o
asm.o: file format elf32-i386
Disassembly of section .text:
00000000 <main>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 83 ec 10 sub $0x10,%esp
6: c7 45 fc 05 00 00 00 movl $0x5,-0x4(%ebp)
d: c7 45 f8 00 00 00 00 movl $0x0,-0x8(%ebp)
14: eb 08 jmp 1e <main+0x1e>
16: 83 45 fc 01 addl $0x1,-0x4(%ebp)
1a: 83 45 f8 01 addl $0x1,-0x8(%ebp)
1e: 83 7d f8 04 cmpl $0x4,-0x8(%ebp)
22: 76 f2 jbe 16 <main+0x16>
24: b8 2a 00 00 00 mov $0x2a,%eax
29: c9 leave
2a: c3 ret
Dang! I'd say this here new-fangled "C" assembler doesn't know its
ASM from a hole in the ground. :)
Nathan.
[ a.l.a added ]
H. Peter Anvin
Perhaps you should turn optimization on:
: tazenda 39 ; gcc -m32 -c -O2 -fomit-frame-pointer test.c
: tazenda 40 ; objdump -dr test.o
test.o: file format elf32-i386
Disassembly of section .text:
00000000 <main>:
0: b8 2a 00 00 00 mov $0x2a,%eax
5: c3 ret
Unlike the author of your code snippet, the compiler can tell that the
previous code is useless.
-hpa
Nathan
> On 03/12/2010 08:05 PM, Nathan wrote:
>
> > }
>
> 00000000 <main>:
> 0: b8 2a 00 00 00 mov $0x2a,%eax
> 5: c3 ret
>
So we know that "return N;" is guaranteed to set the contents of EAX.
Are there any guaranteed methods of setting EBX?
Nathan.
Seebs
> So we know that "return N;" is guaranteed to set the contents of EAX.
No, we don't.
We know that it did in a particular function compiled with a particular
compiler with particular settings for a particular target. We don't
know that it would always do the same even for this function -- it might
compile differently if it were compiled along with particular other
functions, or with different compiler flags, or...
In short, no, it is not "guaranteed".
jacob navia
Yes, because according to the ABI (Application Binary Interface) all
functions set their return value (when they have one, and when it
is a type that fits in 32 bits) in EAX. Note that the next instruction
(in this case) is return, so setting EAX doesn't buy you much.
The EAX register is used universally by all compilers (that I know of)
to set the result in the Intel architecture. st(0) is the register
used for returning a floting point value, the pair EDX:EAX is used for
64 bit returns in 32 bit programs, RAX is used in 64 bit programs.
Note that EBX is not given any special significance under windows, besides
that it is a register that should keep its value across function calls,
so there is no way to set it using high level constructs. Under 32 bit linux
I think EBX is used to hold a pointer to the GOT in shared object, so
you can't set it at all in "picture" mode, unless you save it...
jacob navia
> On 2010-03-13, Nathan <nathan...@gmail.com> wrote:
>> So we know that "return N;" is guaranteed to set the contents of EAX.
>
> No, we don't.
>
> We know that it did in a particular function compiled with a particular
> compiler with particular settings for a particular target. We don't
> know that it would always do the same even for this function -- it might
> compile differently if it were compiled along with particular other
> functions, or with different compiler flags, or...
>
> In short, no, it is not "guaranteed".
>
> -s
I have never seen any compiler unde the Intel architecture that
doesn't place the return value (when there is one of course, and
when it fits 32 bits) in the EAX register.
Can you name a compiler or a combination of compiler+flags
that would place the return value in another register?
jacob navia
>
> Before we declare this "successfully replace" status, I think we
> should put it to a test.
>
> int main(void)
> {
> unsigned ebx;
Here you declare a local variable called "ebx"
> unsigned ecx;
>
Another one
> ebx = 5;
You assign 5 to the local variable ebx
> for (ecx = 0; ecx < 5; ecx++)
> {
> ebx++;
> }
>
> return 42;
> }
>
> $ gcc -c -o asm.o asm.c
> $ objdump -d asm.o
>
> asm.o: file format elf32-i386
>
>
> Disassembly of section .text:
>
> 00000000 <main>:
> 0: 55 push %ebp
> 1: 89 e5 mov %esp,%ebp
> 3: 83 ec 10 sub $0x10,%esp
Make space for 2 local variables, "ecx" and "ebx". Since the
compiler wants to keep the stack aligned, it subtracts 16
instead of just 8. ebx will be at -4 from the start of the
frame, and "ecx" will be at offset -8
> 6: c7 45 fc 05 00 00 00 movl $0x5,-0x4(%ebp)
Assign 5 to "ebx"
> d: c7 45 f8 00 00 00 00 movl $0x0,-0x8(%ebp)
Assign zero to "ecx"
> 14: eb 08 jmp 1e <main+0x1e>
goto StartOfLoop
Increment counters:
> 16: 83 45 fc 01 addl $0x1,-0x4(%ebp)
> 1a: 83 45 f8 01 addl $0x1,-0x8(%ebp)
StartOfLoop:
> 1e: 83 7d f8 04 cmpl $0x4,-0x8(%ebp)
if "ecx" is smaller or equal to 4 goto IncrementCounters
> 22: 76 f2 jbe 16 <main+0x16>
return 42
> 24: b8 2a 00 00 00 mov $0x2a,%eax
Now we destroy the frame
> 29: c9 leave
return
> 2a: c3 ret
>
> Dang! I'd say this here new-fangled "C" assembler doesn't know its
> ASM from a hole in the ground. :)
>
> Nathan.
> [ a.l.a added ]
You do not know what you are talking about obviously.
You think that "magically" a variable called
"ecx" will be assigned to register "ecx"?
Ike Naar
No; the EAX register might have gone out to lunch; in that case,
a replacement register is used:
return 42;
}
main:
/* 000000 2 */ retl ! Result = %o0
/* 0x0004 */ or %g0,42,%o0
Here, %o0 is used to hold the return value.
Ike Naar
jacob navia <j...@nospam.org> wrote:
>Seebs a écrit :
>> On 2010-03-13, Nathan <nathan...@gmail.com> wrote:
>>> So we know that "return N;" is guaranteed to set the contents of EAX.
>>
>> No, we don't.
>>
>> We know that it did in a particular function compiled with a particular
>> compiler with particular settings for a particular target. We don't
>> know that it would always do the same even for this function -- it might
>> compile differently if it were compiled along with particular other
>> functions, or with different compiler flags, or...
>>
>> In short, no, it is not "guaranteed".
>
>doesn't place the return value (when there is one of course, and
>when it fits 32 bits) in the EAX register.
>
>Can you name a compiler or a combination of compiler+flags
>that would place the return value in another register?
Here's an example of a 32 bit value that is not returned in EAX:
return 42;
}
00000004 <_main>:
4: 83 ec 0c sub $0xc,%esp
7: e8 f4 ff ff ff call 0 <___gnu_compiled_c>
8: DISP32 ___main
c: d9 05 00 00 00 00 flds 0x0
e: 32 .text
12: 83 c4 0c add $0xc,%esp
15: c3 ret
Branimir Maksimovic
This is not linked I guess. Since it calls 0 and loads in fpu stack
from 0?
Greets
Harold Aptroot
news:slrnhpmr61.6ma...@guild.seebs.net...
> On 2010-03-13, Nathan <nathan...@gmail.com> wrote:
>> So we know that "return N;" is guaranteed to set the contents of EAX.
>
> No, we don't.
>
> We know that it did in a particular function compiled with a particular
> compiler with particular settings for a particular target. We don't
> know that it would always do the same even for this function -- it might
> compile differently if it were compiled along with particular other
> functions, or with different compiler flags, or...
>
> In short, no, it is not "guaranteed".
>
IIRC it would violate the ABI (no matter whether it's on windoze or linux)
if the return type is int and it didn't place the return value in eax.
So I would say it's guaranteed if N is an int, at least.
Ike Naar
Indeed, it is not linked (it was compiled with gcc -c).
Branimir Maksimovic
Nathan <nathan...@gmail.com> wrote:
> On Mar 12, 3:59 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
> > But c++ is most closest to C still, and there is no
> > other language that can successfully replace assembler
> > then C.
>
> Before we declare this "successfully replace" status, I think we
> should put it to a test.
I didn't meant to write assembler, rather C. That means if you want
to switch CPU just recompile, not rewrite. What would be the point
anyway?
By "replacing assembler" I meant in resulting code would be
lightweight as I would write it in assembler, and with
compiler extensions I can even dig into CPu registers;)
Of course for CPu specific things, you still need assembler ;)
jacob navia
As I said in another message, floating point values are returned in st(0)
Rod Pemberton
news:U5Kdnb46e_RmXwvW...@bt.com...
>
> I know this isn't a C-language related question, but before I get into C,
> have to have a compiler.
>
> upgraded to a 64-bit CPU machine, and the old DOS programs I wrote with
it,
> and DJGPP itself, won't run on it.
Bye bye DPMI calls... If you're using lots of DJGPP features, DPMI or BIOS
or DOS calls, or DJGPP's POSIX features, you'll probably need to ANSI-ize
the C first. If you run it through "gcc -Wall -ansi -pedantic" first and
clean it up, it should compile elsewhere just fine. "-ansi" will flag DPMI
code, and other non-standard stuff, but will also flag C99 C extensions that
you may wish to keep.
> For this reason, I'd like to upgrade to
> MinGW, and I'm sure there are people on this user group that could point
the
> way.
Hmm... Is there a 64-bit version of MinGW? FYI, you'd be running 32-bit
code on your 64-bit Windows OS. (Not a problem.)
PellesC (a different LCC variant) has both 32-bit and 64-bit Windows
versions.
http://www.pellesc.de/
You might also look at OpenWatcom. It should have a 64-bit target by now,
as well as 16-bit and 32-bit x86. It supports many platforms including DOS
and Windows. Linux support should be functional by now. Hopefully, they
kept the DOS support (both 16-bit and 32-bit DPMI), which may make porting
your application easier. The code will still need to be ANSI-ized or
C99-ized from DJGPP code (i.e., remove POSIX). BorlandC DOS features are
available.
http://www.openwatcom.org/index.php/Main_Page
> What I'm looking for is a really simple manual that will hold my hand till
I
> get going, and have compiled and run my first C program. After that, I
> should be OK.
First C program? You said you used DJGPP for a long time and wrote programs
for it...
> I have found a fair amount on the web about it, but it's all about other
> languages, and I want something that specifically tells me how to compile
> and run a C program. I've been trying for a long time, but I'm clearly
not
> understanding something.
If you used DJGPP for a long time, you know "specifically ... how to compile
and run a C program" for GCC. I.e., compiling should be identical for other
GCC based compilers such as GCC on Linux or for Cygwin with Windows. I
think what you're really asking about how to write a basic Windows program
in C. (Yes? No?) That would require learning how to program for Windows.
But, even for Windows, you don't need to know how to program Windows
"window-ing" code. Console (or command line) applications can be compiled.
You should be able to code a console application with regular C (K&R, ANSI,
C99 etc.) - no Windows "window-ing" code needed. I believe that's doable
with MinGW, PellesC, OpenWatcom, LCC-Win32, or Cygwin. LLVM seems to
support 64-bit targets only for Linux (uses MinGW 32-bit for Windows).
> I tried the user forum on the MinGW site, but found them none too helpful.
> It's populated by people who don't willingly tolerate newbies.
So, you posted to c.l.c... ?
Rod Pemberton
REH
> to use name mangling which made language pretty useless
> for interfacing with another languages...
How so? I've interfaced C++ with a lot of languages, including C, Ada,
assembly. It is not hard, and doesn't require any non-portable
features.
REH
Branimir Maksimovic
How did you do that? extern "C" is C linkage funciton not C++.
And on;y possible portable way to interface is through C.
Greets
REH
> How did you do that? extern "C" is C linkage funciton not C++.
> And on;y possible portable way to interface is through C.
>
What's your point? It doesn't change the language. It merely tells the
compiler to use C-compatible linkage. It doesn't preclude use of any C+
+ functionality. extern "C" doesn't force the language to change to C.
With it you can define a C interface for a C++ one. Many languages
know how to talk to C. With extern "C" you can allow them to talk to C+
+ and not even know it. So, no, interfacing to C++ is not "useless."
By the way, in case you didn't know it, the C standard also allow for
name mangling (although, in a much more limited form).
REH
Branimir Maksimovic
REH <spam...@stny.rr.com> wrote:
> On Mar 13, 10:53 am, Branimir Maksimovic <bm...@hotmail.com> wrote:
> > How did you do that? extern "C" is C linkage funciton not C++.
> > And on;y possible portable way to interface is through C.
> >
>
> What's your point? It doesn't change the language. It merely tells the
> compiler to use C-compatible linkage.
No rules for extern "C" functions and data are restricted to C.
Read carefully. You can;t overload extern "C" function nor you can
make it member of struct/class!
It doesn't preclude use of any
> C+
> + functionality.
Not true.
extern "C" doesn't force the language to change to C.
> With it you can define a C interface for a C++ one.
Exactly! This is my point.
Many languages
> know how to talk to C. With extern "C" you can allow them to talk to
> C+
> + and not even know it. So, no, interfacing to C++ is not "useless."
Greets!
Ian Collins
> On Sat, 13 Mar 2010 11:48:29 -0800 (PST)
> REH<spam...@stny.rr.com> wrote:
>
>> On Mar 13, 10:53 am, Branimir Maksimovic<bm...@hotmail.com> wrote:
>>> How did you do that? extern "C" is C linkage funciton not C++.
>>> And on;y possible portable way to interface is through C.
>>>
>>
>> What's your point? It doesn't change the language. It merely tells the
>> compiler to use C-compatible linkage.
>
> No rules for extern "C" functions and data are restricted to C.
That's true, but only for those.
> Read carefully. You can;t overload extern "C" function nor you can
> make it member of struct/class!
>
>> It doesn't preclude use of any C++ functionality.
>
> Not true.
It is almost true (and it is if you link with the C++ compiler). You
can use anything that doesn't require initialisation before main. This
does mean you have to take care and rules out a lot of C++ libraries,
but it can be done. I have written both driver and PHP extensions in
C++, exported via an extern "C" interface.
The normal recommendation when mixing C with C++ is to compile and link
with main() in a C++ file. This should work with other languages that
can interface with C.
> extern "C" doesn't force the language to change to C.
>> With it you can define a C interface for a C++ one.
>
> Exactly! This is my point.
Which was?
--
Ian Collins
Branimir Maksimovic
Ian Collins <ian-...@hotmail.com> wrote:
>
> > extern "C" doesn't force the language to change to C.
> >> With it you can define a C interface for a C++ one.
> >
> > Exactly! This is my point.
>
> Which was?
>
You can;t link portably with c++ function from other language
even from other c++ compiler!
Same is valid for c++ data.
Greets
REH
> No rules for extern "C" functions and data are restricted to C.
> Read carefully. You can;t overload extern "C" function nor you can
> make it member of struct/class!
>
I think you misunderstand me. Your INTERFACE will be limited to C. C
obviously cannot talk to something it doesn't understand. We cannot
magically make it understand classes or overloading. But the
implementation can still be C++. If, for example, I have the following
C++ class:
class foo
{
foo(int c, double y) : x(x), y(y) {}
virtual ~foo() {}
void get(int& x) {x = m_x;}
void get(double& y) {y = m_y;}
private:
int x;
double y;
};
I wish to use this class in some C code. I would simply define a C-
callable interface for it:
foo.h:
#ifndef FOO_H
#define FOO_H
#ifdef __cplusplus
extern "C" {
#endif
typedef struct foo foo;
foo* foo_create(void);
void foo_destroy(foo* f);
int foo_get_x(foo* f);
double foo_get_y(foo* f);
#ifdef __cplusplus
}
#endif
#endif /* FOO_H */
foo.cpp:
#include "foo.h"
#include "foo_class.h"
void foo_create(foo* f) {return new foo();}
void foo_destroy(foo* f) {delete f;}
int foo_get_x(foo* f) {int i; f->get(i); return i;}
double foo_get_y(foo* f) {double d; f->get(d); return d;}
Now, with the above binding, I can easily use the class foo with other
languages. Using this simple pattern, you can utilize pretty much any C
++ class with any language that can talk to C. There are other
techniques you can use if you'd prefer not to use the free store.
Obviously you have to do a little work if you are using a language
that cannot interface to C++ directly or does not have an equivalent
feature to a C++ one, but it surely is not an impossibility. Thus, the
attempt is not "useless."
REH
Ian Collins
> On Sun, 14 Mar 2010 09:47:06 +1300
> Ian Collins<ian-...@hotmail.com> wrote:
>>
>>> extern "C" doesn't force the language to change to C.
>>>> With it you can define a C interface for a C++ one.
>>>
>>> Exactly! This is my point.
>>
>> Which was?
>>
>
> You can;t link portably with c++ function from other language
> even from other c++ compiler!
> Same is valid for c++ data.
True, unless you qualify your interface with extern "C" and only share C
compatible data types.
--
Ian Collins
Branimir Maksimovic
REH <spam...@stny.rr.com> wrote:
Thus, the
> attempt is not "useless."
Agreed.
Greets
jacob navia
> Here's an example of a 32 bit value that is not returned in EAX:
>
> return 42;
> }
>
> 00000004 <_main>:
> 4: 83 ec 0c sub $0xc,%esp
> 7: e8 f4 ff ff ff call 0 <___gnu_compiled_c>
> 8: DISP32 ___main
> c: d9 05 00 00 00 00 flds 0x0
> e: 32 .text
> 12: 83 c4 0c add $0xc,%esp
> 15: c3 ret
This code doesn't correspond to the original C source code. Please
tell me what compiler you used and what code you compiled.
Note that floating point values are returned in st(0)
H. Peter Anvin
>
> I have never seen any compiler unde the Intel architecture that
> doesn't place the return value (when there is one of course, and
> when it fits 32 bits) in the EAX register.
>
> Can you name a compiler or a combination of compiler+flags
> that would place the return value in another register?
More importantly, this is the sort of thing that is guaranteed in an ABI
document -- specifically the handoff conditions that apply at
intermodule function call boundaries.
-hpa
Spiro Trikaliotis
REH wrote:
> On Mar 13, 3:17 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
>> No rules for extern "C" functions and data are restricted to C.
>> Read carefully. You can;t overload extern "C" function nor you can
>> make it member of struct/class!
>>
>
> I think you misunderstand me. Your INTERFACE will be limited to C. C
> obviously cannot talk to something it doesn't understand. We cannot
> magically make it understand classes or overloading. But the
> implementation can still be C++.
What if the function exported with `extern "C"' throws an exception?
For example, `new' comes to mind, like your foo_create():
> void foo_create(foo* f) {return new foo();}
Regards,
Spiro.
--
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/
Ian Collins
> Hello,
>
> REH wrote:
>
>> On Mar 13, 3:17 pm, Branimir Maksimovic<bm...@hotmail.com> wrote:
>>> No rules for extern "C" functions and data are restricted to C.
>>> Read carefully. You can;t overload extern "C" function nor you can
>>> make it member of struct/class!
>>>
>>
>> I think you misunderstand me. Your INTERFACE will be limited to C. C
>> obviously cannot talk to something it doesn't understand. We cannot
>> magically make it understand classes or overloading. But the
>> implementation can still be C++.
>
> What if the function exported with `extern "C"' throws an exception?
All bets are off.
--
Ian Collins
Ersek, Laszlo
I have some experience with this, from several years ago, with gcc /
glibc / Linux. I was writing a C++ wrapper for libcalc
<http://isthe.com/chongo/tech/comp/calc/index.html>. My memories are
vague, but looking at the "LIBRARY" file in the tarball I just
downloaded, it says:
----v----
MATH ERROR HANDLING
-------------------
The math_error() function is called by the math routines on an error
condition, such as malloc failures, division by zero, or some form of
an internal computation error. The routine is called in the manner of
printf, with a format string and optional arguments:
void math_error(char *fmt, ...);
Your program must handle math errors in one of three ways:
1) Print the error message and then exit
[...]
2) Use setjmp and longjmp in your program
[...]
3) Supply your own math_error function:
void math_error(char *fmt, ...);
Your math_error() function may exit or transfer control to outside
of the calc library, but it must never return or calc will crash.
----^----
I think I went with option 3 and supplied my own math_error() function.
It formatted an error message in accordance to the arguments received,
then threw an exception with that message embedded. Since libcalc is
written entirely in C, it contains no catch statements and no
destructors, so all such exceptions propagated reliably back to the C++
call sites without actually re-entering libcalc code.
I won't comment on how standards-conformant this solution was (probably
not at all), but gcc seemed (and still seems) to support this actively,
since the thing started to work once I figured out I have to pass
-fexceptions to gcc when building libcalc:
----v----
-fexceptions
Enable exception handling. Generates extra code needed to propagate
exceptions. For some targets, this implies GCC will generate frame
unwind information for all functions, which can produce significant data
size overhead, although it does not affect execution. If you do not
specify this option, GCC will enable it by default for languages like
C++ which normally require exception handling, and disable it for
languages like C that do not normally require it. However, you may need
to enable this option when compiling C code that needs to interoperate
properly with exception handlers written in C++. You may also wish to
disable this option if you are compiling older C++ programs that don't
use exception handling.
----^----
lacos
Ian Collins
> In article<804u72...@mid.individual.net>, Ian Collins<ian-...@hotmail.com> writes:
>> On 03/15/10 08:35 AM, Spiro Trikaliotis wrote:
>>>
>>> What if the function exported with `extern "C"' throws an exception?
>>
>> All bets are off.
>
<snip>
>
> 3) Supply your own math_error function:
>
> void math_error(char *fmt, ...);
>
> Your math_error() function may exit or transfer control to outside
> of the calc library, but it must never return or calc will crash.
> ----^----
>
> I think I went with option 3 and supplied my own math_error() function.
> It formatted an error message in accordance to the arguments received,
> then threw an exception with that message embedded. Since libcalc is
> written entirely in C, it contains no catch statements and no
> destructors, so all such exceptions propagated reliably back to the C++
> call sites without actually re-entering libcalc code.
That's generally what happens, the generated C code isn't (and
shouldn't) be aware of C++ exceptions, so throwing an exception from C++
through C code is pretty much (and my well be) equivalent to executing a
jongjmp to the catch statement.
The problems this causes are the same as jongjmp; there isn't any stack
unwinding or automatic clean up, so the application may end up in an
undefined state.
> I won't comment on how standards-conformant this solution was (probably
> not at all), but gcc seemed (and still seems) to support this actively,
> since the thing started to work once I figured out I have to pass
> -fexceptions to gcc when building libcalc:
It may be OK if a single compiler family is used for both C and C++, it
probably isn't if a mix of compilers is used.
> ----v----
> -fexceptions
>
> Enable exception handling. Generates extra code needed to propagate
> exceptions. For some targets, this implies GCC will generate frame
> unwind information for all functions, which can produce significant data
> size overhead, although it does not affect execution. If you do not
> specify this option, GCC will enable it by default for languages like
> C++ which normally require exception handling, and disable it for
> languages like C that do not normally require it. However, you may need
> to enable this option when compiling C code that needs to interoperate
> properly with exception handlers written in C++.
That last sentence says it all!
--
Ian Collins
REH
<usenet-200...@spiro.trikaliotis.net> wrote:
> Hello,
>
> REH wrote:
> > On Mar 13, 3:17 pm, Branimir Maksimovic <bm...@hotmail.com> wrote:
> >> No rules for extern "C" functions and data are restricted to C.
> >> Read carefully. You can;t overload extern "C" function nor you can
> >> make it member of struct/class!
>
> > I think you misunderstand me. Your INTERFACE will be limited to C. C
> > obviously cannot talk to something it doesn't understand. We cannot
> > magically make it understand classes or overloading. But the
> > implementation can still be C++.
>
> What if the function exported with `extern "C"' throws an exception?
> For example, `new' comes to mind, like your foo_create():
>
> > void foo_create(foo* f) {return new foo();}
>
It was just a simple example. In reality, I would have either trapped
the exception, used the "nothrow" version, or used malloc and
constructed the object manually.
REH
MikeC
"Rod Pemberton" <do_no...@havenone.cmm> wrote in message
news:hng42g$fap$1...@speranza.aioe.org...
> "MikeC" <my.address@end_of.post> wrote in message
> news:U5Kdnb46e_RmXwvW...@bt.com...
>>
>> I know this isn't a C-language related question, but before I get into C,
> I
>> have to have a compiler.
>>
>> In fact, I have been using DJGPP for many years, but I have recently
>> upgraded to a 64-bit CPU machine, and the old DOS programs I wrote with
> it,
>> and DJGPP itself, won't run on it.
>
> Bye bye DPMI calls... If you're using lots of DJGPP features, DPMI or
> BIOS
> or DOS calls, or DJGPP's POSIX features, you'll probably need to ANSI-ize
> the C first. If you run it through "gcc -Wall -ansi -pedantic" first and
> clean it up, it should compile elsewhere just fine. "-ansi" will flag
> DPMI
> code, and other non-standard stuff, but will also flag C99 C extensions
> that
> you may wish to keep.
>
There's not really a huge amount I want to port. I enjoy programming, and
have a couple of projects I wanted to get on with, and just wanted a free
compiler that would run on my new platform. I don't know why DJGPP won't -
but it won't. I have known others who have the same issue.
>> For this reason, I'd like to upgrade to
>> MinGW, and I'm sure there are people on this user group that could point
> the
>> way.
>
> Hmm... Is there a 64-bit version of MinGW? FYI, you'd be running 32-bit
> code on your 64-bit Windows OS. (Not a problem.)
>
It doesn't have to be 64-bit - it just has to run under Windows-7 on my
present PC, and MinGW does that. I have messed about with it a bit, but
it's going slowly and I haven't really had the time to get into it.
> PellesC (a different LCC variant) has both 32-bit and 64-bit Windows
> versions.
> http://www.pellesc.de/
>
> You might also look at OpenWatcom. It should have a 64-bit target by now,
> as well as 16-bit and 32-bit x86. It supports many platforms including
> DOS
> and Windows. Linux support should be functional by now. Hopefully, they
> kept the DOS support (both 16-bit and 32-bit DPMI), which may make porting
> your application easier. The code will still need to be ANSI-ized or
> C99-ized from DJGPP code (i.e., remove POSIX). BorlandC DOS features are
> available.
> http://www.openwatcom.org/index.php/Main_Page
>
Thanks for that - I'll look at it. I was using RHIDE with DJGPP (though
RHIDE has been broken, and limping for some time). If I could find
something that looked like it and would work on my PC, it would certainly
save me a lot of time in re-learning. I know that RHIDE was a lookalike of
something, but I'm not sure what. I think it may have been the Borland IDE.
>> What I'm looking for is a really simple manual that will hold my hand
>> till
> I
>> get going, and have compiled and run my first C program. After that, I
>> should be OK.
>
> First C program? You said you used DJGPP for a long time and wrote
> programs
> for it...
>
No - I meant my first C program with the new compiler. I just mentioned C
to distinguish it from C++, as I never made that intellectual leap.
>> I have found a fair amount on the web about it, but it's all about other
>> languages, and I want something that specifically tells me how to compile
>> and run a C program. I've been trying for a long time, but I'm clearly
> not
>> understanding something.
>
> If you used DJGPP for a long time, you know "specifically ... how to
> compile
> and run a C program" for GCC. I.e., compiling should be identical for
> other
> GCC based compilers such as GCC on Linux or for Cygwin with Windows. I
> think what you're really asking about how to write a basic Windows program
> in C. (Yes? No?) That would require learning how to program for Windows.
> But, even for Windows, you don't need to know how to program Windows
> "window-ing" code. Console (or command line) applications can be
> compiled.
> You should be able to code a console application with regular C (K&R,
> ANSI,
> C99 etc.) - no Windows "window-ing" code needed. I believe that's doable
> with MinGW, PellesC, OpenWatcom, LCC-Win32, or Cygwin. LLVM seems to
> support 64-bit targets only for Linux (uses MinGW 32-bit for Windows).
>
Yes - programs I have written previously have all been DOS-based - though
even in a Windows environment, you can still do a lot with it. One parser
that I wrote - which became very popular throughout my global company - read
a source file and produced a target file, but the users weren't conscious of
ever leaving the Windows environment to use it.
>> I tried the user forum on the MinGW site, but found them none too
>> helpful.
>> It's populated by people who don't willingly tolerate newbies.
>
> So, you posted to c.l.c... ?
>
Well ... it was a good move. I've certainly had a lot more help here than
there! ;-)
This board is a lot friendlier than that one.
MikeC