C-DLL-VBA connections strings
Francogrex
excel through the VBA). It works well for returning integer and double
values (see simple example below), but I can't seem to get it to
return strings (Note that the dll I am making I tested and it works
well elsewhere because when I link it to an exe it is actually
returing a string as expected). I am using MinGW gcc (so basically
only C) to construct my dll, so I don't have access to BSTR and other
cpp like objects/functions... Is there a way to make the C dll return
strings to excel? Thanks
DLL.c
#ifdef BUILD_DLL
#define EXPORT __declspec(dllexport)
#else
#define EXPORT __declspec(dllimport)
#endif
EXPORT int __stdcall add2(int num){
return num + 2;
}
COMPILE mydll.dll
c:\> gcc -c -DBUILD_DLL dll.c
c:\> gcc -shared -o mydll.dll dll.o -Wl,--add-stdcall-alias
IN VBA:
Private Declare Function add2 Lib "c:/mydll" _
(ByVal num As Long) As Long
Ben Bacarisse
> Hello, I'm trying to connect excel to a C dll library (call C dll from
> excel through the VBA). It works well for returning integer and double
> values (see simple example below), but I can't seem to get it to
> return strings (Note that the dll I am making I tested and it works
> well elsewhere because when I link it to an exe it is actually
> returing a string as expected).
This is not really a C question. It is all about how VB represents
strings. I confirmed this is a search where I found:
http://support.microsoft.com/kb/118643/EN-US/
despite the page name there is an example of returning a string also.
--
Ben.
Francogrex
> This is not really a C question. It is all about how VB represents
> strings. I confirmed this is a search where I found:
>
> http://support.microsoft.com/kb/118643/EN-US/
>
> despite the page name there is an example of returning a string also.
Thanks for the effort but I think I did mention that i'm using MinGW's
gcc. None of those programs compile with gcc even with the right
libraries "vbapi.h". __far __pascal?? what the hell is that?
jacob navia
Use another compiler...
mongw doesn't work well under windows, unless you write
very simple console programs...
Keith Thompson
My understanding is that mingw can be used to develop native Windows
applications not just console programs. I can't comment on how good
it is because I don't use it. (jacob's statement might be correct;
I'm just providing a bit more information.)
--
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"
BartC
"Keith Thompson" <ks...@mib.org> wrote in message
news:lny6rhp...@nuthaus.mib.org...
> jacob navia <ja...@jacob.remcomp.fr> writes:
>> Francogrex wrote:
>>> On Jun 24, 5:57 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>>>> This is not really a C question. It is all about how VB represents
>>>> strings. I confirmed this is a search where I found:
>>>>
>>>> http://support.microsoft.com/kb/118643/EN-US/
>>>>
>>>> despite the page name there is an example of returning a string also.
>>>
>>> Thanks for the effort but I think I did mention that i'm using MinGW's
>>> gcc. None of those programs compile with gcc even with the right
>>> libraries "vbapi.h". __far __pascal?? what the hell is that?
>>
>> Use another compiler...
>>
>> mongw doesn't work well under windows, unless you write
>> very simple console programs...
>
> My understanding is that mingw can be used to develop native Windows
> applications not just console programs. I can't comment on how good
> it is because I don't use it. (jacob's statement might be correct;
> I'm just providing a bit more information.)
I've just compiled and run Petzold's 'Hello World' for Windows with mingw
(gcc 3.4.5) and it seems to work OK.
--
Bart
jacob navia
Hello world yes. But the problem are the windows header files...
They are kind of old, and not up to date...
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Mark McIntyre
> Hello, I'm trying to connect excel to a C dll library (call C dll from
> excel through the VBA). It works well for returning integer and double
> values (see simple example below), but I can't seem to get it to
> return strings (Note that the dll I am making I tested and it works
> well elsewhere because when I link it to an exe it is actually
> returing a string as expected).
This indicates the issue is with how Excel is expecting to receive strings.
>I am using MinGW gcc (so basically
> only C) to construct my dll, so I don't have access to BSTR and other
> cpp like objects/functions... Is there a way to make the C dll return
> strings to excel?
That's kinda like saying "all I have is apples, is this ok for making an
omlette?" :-)
If the API expects BSTRs (and it does) then you need to use them. For
what its worth, they're easy enough to construct by hand. Look 'em up in
the microsoft documentation.
Old Wolf
> I am using MinGW gcc so I don't have access to BSTR
BSTR is a typedef for "unsigned short *", so you certainly
do have access to it. BSTRs can be created and manipulated
using basic Windows API functions. This is kind of
off-topic for c.l.c though, one of the Windows programming
newsgroups would be the best place to write.
Ben Bacarisse
It specifies things to do with the calling convention. It may not be
required but if it is then you will need to find MinGW's equivalent
(if it has one). You will certainly need to know how to build a VB
string in C so the header file, or at least some of the definitions in
it, will be required (it sounds as if you have that part sorted).
Anyway, this is not really a C question. A VB group is likely to able
to tell you if this can be done with MinGW better than we can.
--
Ben.
Nick Keighley
> jacob navia <ja...@jacob.remcomp.fr> writes:
> > Francogrex wrote:
> >> On Jun 24, 5:57 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >>> This is not really a C question. It is all about how VB represents
> >>> strings. I confirmed this is a search where I found:
>
> >>>http://support.microsoft.com/kb/118643/EN-US/
>
> >>> despite the page name there is an example of returning a string also.
>
> >> Thanks for the effort but I think I did mention that i'm using MinGW's
> >> gcc. None of those programs compile with gcc even with the right
> >> libraries "vbapi.h". __far __pascal?? what the hell is that?
>
> > Use another compiler...
>
> > mongw doesn't work well under windows, unless you write
> > very simple console programs...
>
> My understanding is that mingw can be used to develop native Windows
> applications not just console programs. I can't comment on how good
> it is because I don't use it. (jacob's statement might be correct;
> I'm just providing a bit more information.)
I've done. It isn't particularly hard
Richard Bos
> jacob navia <ja...@jacob.remcomp.fr> writes:
> > Use another compiler...
Not very subtle, jacob.
> > mongw doesn't work well under windows, unless you write
> > very simple console programs...
>
> My understanding is that mingw can be used to develop native Windows
> applications not just console programs. I can't comment on how good
> it is because I don't use it. (jacob's statement might be correct;
> I'm just providing a bit more information.)
I _have_ used it. In fact, it is my most frequently used compiler. I can
say with all confidence that jacob is expostulating out of his
fundamental orifice.
What you probably _can't_ easily do is link mingw with VB. But then, you
can't easily link TinyC with Turbo Pascal, either, as far as I know. It
really doesn't mean anything about the quality of the systems involved.
What it _does_ mean is that, if you want easy interoperability of
different compilers, get them from the same vendor.
Richard
jacob navia
> Keith Thompson <ks...@mib.org> wrote:
>
>> jacob navia <ja...@jacob.remcomp.fr> writes:
>>> Use another compiler...
>
> Not very subtle, jacob.
>
>>> mongw doesn't work well under windows, unless you write
>>> very simple console programs...
>> My understanding is that mingw can be used to develop native Windows
>> applications not just console programs. I can't comment on how good
>> it is because I don't use it. (jacob's statement might be correct;
>> I'm just providing a bit more information.)
>
> I _have_ used it. In fact, it is my most frequently used compiler. I can
> say with all confidence that jacob is expostulating out of his
> fundamental orifice.
>
The fact that
printf("%Lg\n",(long double)a);
doesn't work is OK with you of course.
The fact that most windows headers are missing is OK with you too.
> I can
> say with all confidence that jacob is expostulating out of his
> fundamental orifice.
>
This is obviously a good regular.
Insults, polemic, and no brains
[snip crap]
Kenny McCormack
Note to all (not specifically to Jacob): Jacob has a tendency to
exagerate, and the regs never miss a chance to pounce on him for it.
But he is basically right here - the underlying concept being that
trying to develop for Windows using a Unixy compiler is (as I've also
noted in a parallel thread) asking for pain. I've used both Cygwin and
Mingw on several occasions to compile Unix specific code (Cygwin) and/or
what Jacob snidely calls "simple console apps" and both tools do indeed
work well. Both tools are also able to create Windows GUI apps and
nobody seriously thinks otherwise. In fact, I think that the Windows
GVIM (VI like editor) is/can be compiled with Mingw, but the point still
remains that if you are developing specifically for Windows, you should
use a Windows oriented compiler/IDE (such as lcc-win32...).
>This is obviously a good regular.
>Insults, polemic, and no brains
Well, you've been around for a while - you know what to expect.
You could try at least a little not to give them such easy opportunities.
Nick Keighley
> In article <h20o5j$ip...@news.eternal-september.org>,
> jacob navia <ja...@jacob.remcomp.fr> wrote:
> >Richard Bos wrote:
> >> Keith Thompson <ks...@mib.org> wrote:
> >>> jacob navia <ja...@jacob.remcomp.fr> writes:
> >>>> Use another compiler...
>
> >> Not very subtle, jacob.
>
> >>>> mongw doesn't work well under windows, unless you write
> >>>> very simple console programs...
>
> >>> My understanding is that mingw can be used to develop native Windows
> >>> applications not just console programs. I can't comment on how good
> >>> it is because I don't use it. (jacob's statement might be correct;
> >>> I'm just providing a bit more information.)
>
> >> I _have_ used it. In fact, it is my most frequently used compiler. I can
> >> say with all confidence that jacob is expostulating out of his
> >> fundamental orifice.
>
> >The fact that
> >printf("%Lg\n",(long double)a);
>
> >doesn't work is OK with you of course.
doesn't seem a major problem
> >The fact that most windows headers are missing is OK with you too.
which ones?
> > > I can
> > > say with all confidence that jacob is expostulating out of his
> > > fundamental orifice.
>
> Note to all (not specifically to Jacob): Jacob has a tendency to
> exagerate, and the regs never miss a chance to pounce on him for it.
>
> But he is basically right here
no he isn't
> - the underlying concept being that
> trying to develop for Windows using a Unixy compiler is (as I've also
> noted in a parallel thread) asking for pain.
not really. I'm not sure why MingW is a "unix compiler"
>I've used both Cygwin and
> Mingw on several occasions to compile Unix specific code (Cygwin) and/or
> what Jacob snidely calls "simple console apps" and both tools do indeed
> work well. Both tools are also able to create Windows GUI apps and
> nobody seriously thinks otherwise. In fact, I think that the Windows
> GVIM (VI like editor) is/can be compiled with Mingw, but the point still
> remains that if you are developing specifically for Windows, you should
> use a Windows oriented compiler/IDE (such as lcc-win32...).
why?
Oh, and if you do want to use a "windows compiler" also consider
Microsoft's Visual C++ Express. It *is* (or can be made to be)
a C compiler and it's free.
> >This is obviously a good regular.
> >Insults, polemic, and no brains
>
> Well, you've been around for a while - you know what to expect.
> You could try at least a little not to give them such easy opportunities.
:-)
jacob navia
> On 25 June, 22:28, gaze...@shell.xmission.com (Kenny McCormack) wrote:
>> In article <h20o5j$ip...@news.eternal-september.org>,
>> jacob navia <ja...@jacob.remcomp.fr> wrote:
>>> Richard Bos wrote:
>>>> Keith Thompson <ks...@mib.org> wrote:
>>>>> jacob navia <ja...@jacob.remcomp.fr> writes:
>
>
>>>>>> Use another compiler...
>>>> Not very subtle, jacob.
>>>>>> mongw doesn't work well under windows, unless you write
>>>>>> very simple console programs...
>>>>> My understanding is that mingw can be used to develop native Windows
>>>>> applications not just console programs. I can't comment on how good
>>>>> it is because I don't use it. (jacob's statement might be correct;
>>>>> I'm just providing a bit more information.)
>>>> I _have_ used it. In fact, it is my most frequently used compiler. I can
>>>> say with all confidence that jacob is expostulating out of his
>>>> fundamental orifice.
>>> The fact that
>>> printf("%Lg\n",(long double)a);
>>> doesn't work is OK with you of course.
>
> doesn't seem a major problem
>
Obvious. It is gcc
When my compiler doesn't emit an error when it sees // comments
using the undocumented ansic89 flag a posting will be done
by the regs indicating a "serious bug".
When gcc doesn't print long doubles that's not very important.
Keith Thompson
[...]
> When my compiler doesn't emit an error when it sees // comments
> using the undocumented ansic89 flag a posting will be done
> by the regs indicating a "serious bug".
jacob, do you actually *read* this newsgroup?
A single troll calling himself "Tea Pot" has repeatedly complained
about this. The "regs" consistently reply that, since the ansic89
flag is not documented, and since there's no claim that lcc-win
supports C89/C90, it's not a bug, and that even if it were this is
not the place to complain about it.
On this particular point, we have consistently defended you. I,
for one, would appreciate it if you'd pay a bit more attention
and refrain from making unfounded accusations.
lawrenc...@siemens.com
>
> When my compiler doesn't emit an error when it sees // comments
> using the undocumented ansic89 flag a posting will be done
> by the regs indicating a "serious bug".
Please pay attention, Jacob. There's one (non-"reg") rabble rouser who
periodically posts that nonsense. When he/she does, the "regs" defend
your right to have an undocumented flag do whatever you want it to,
despite the somewhat misleading name. None of us/them have *ever*
called it a bug, let alone a serious one, as long as you don't claim C89
conformance, which you most adamantly do not.
--
Larry Jones
Why is it you always rip your pants on the day everyone has to
demonstrate a math problem at the chalkboard? -- Calvin
Kenny McCormack
<lawrenc...@siemens.com> wrote:
>jacob navia <ja...@jacob.remcomp.fr> wrote:
>>
>> When my compiler doesn't emit an error when it sees // comments
>> using the undocumented ansic89 flag a posting will be done
>> by the regs indicating a "serious bug".
>
>Please pay attention, Jacob. There's one (non-"reg") rabble rouser who
>periodically posts that nonsense. When he/she does, the "regs" defend
>your right to have an undocumented flag do whatever you want it to,
>despite the somewhat misleading name. None of us/them have *ever*
>called it a bug, let alone a serious one, as long as you don't claim C89
>conformance, which you most adamantly do not.
It is pretty clear that the so-called "rabble rouser" is a Heathfield sock.
Once you realize this, everything you've written above takes on a
different tone.
Keith Thompson
> jacob navia <ja...@jacob.remcomp.fr> writes:
> [...]
>> When my compiler doesn't emit an error when it sees // comments
>> using the undocumented ansic89 flag a posting will be done
>> by the regs indicating a "serious bug".
> [...]
>
> jacob, do you actually *read* this newsgroup?
>
> A single troll calling himself "Tea Pot" has repeatedly complained
> about this. The "regs" consistently reply that, since the ansic89
> flag is not documented, and since there's no claim that lcc-win
> supports C89/C90, it's not a bug, and that even if it were this is
> not the place to complain about it.
>
> On this particular point, we have consistently defended you. I,
> for one, would appreciate it if you'd pay a bit more attention
> and refrain from making unfounded accusations.
jacob, somehow I'm not surprised that you chose to ignore this.
Disappointed, but not surprised.
Nick Keighley
> Nick Keighley wrote:
> > On 25 June, 22:28, gaze...@shell.xmission.com (Kenny McCormack) wrote:
> >> In article <h20o5j$ip...@news.eternal-september.org>,
> >> jacob navia <ja...@jacob.remcomp.fr> wrote:
> >>> Richard Bos wrote:
> >>>> Keith Thompson <ks...@mib.org> wrote:
> >>>>> jacob navia <ja...@jacob.remcomp.fr> writes:
> >>>>>> Use another compiler...
>
> >>>> Not very subtle, jacob.
>
> >>>>>> mongw doesn't work well under windows, unless you write
> >>>>>> very simple console programs...
>
> >>>>> My understanding is that mingw can be used to develop native Windows
> >>>>> applications not just console programs. I can't comment on how good
> >>>>> it is because I don't use it. (jacob's statement might be correct;
> >>>>> I'm just providing a bit more information.)
>
> >>>> I _have_ used it. In fact, it is my most frequently used compiler. I can
> >>>> say with all confidence that jacob is expostulating out of his
> >>>> fundamental orifice.
>
> >>> The fact that
> >>> printf("%Lg\n",(long double)a);
> >>> doesn't work is OK with you of course.
>
> > doesn't seem a major problem
I'm sorry, the context was that you claimed it was difficult to write
windows application with MingW. At least two people have said it isn't
as they've done it (including me). What the <expletive> does this have
to do with how long doubles are handled? I don't think I have *ever*
used long doubles they are not essential to windows programming.
You also claimed "The fact that most windows headers are missing is OK
with you too. ". I asked you which ones and you failed to respond. So
which headers are missing?
And I have yet to have it explained to me what "unix compiler is".
If it runs under windows and generates windows binaries and provides
acces to the most common windows libraries then it's a windows'
compiler.
good grief.
jacob navia
> Keith Thompson <ks...@mib.org> writes:
>> jacob navia <ja...@jacob.remcomp.fr> writes:
>> [...]
>>> When my compiler doesn't emit an error when it sees // comments
>>> using the undocumented ansic89 flag a posting will be done
>>> by the regs indicating a "serious bug".
>> [...]
>>
>> jacob, do you actually *read* this newsgroup?
>>
>> A single troll calling himself "Tea Pot" has repeatedly complained
>> about this. The "regs" consistently reply that, since the ansic89
>> flag is not documented, and since there's no claim that lcc-win
>> supports C89/C90, it's not a bug, and that even if it were this is
>> not the place to complain about it.
>>
>> On this particular point, we have consistently defended you. I,
>> for one, would appreciate it if you'd pay a bit more attention
>> and refrain from making unfounded accusations.
>
> jacob, somehow I'm not surprised that you chose to ignore this.
> Disappointed, but not surprised.
>
I did not want to write this since I do not want to start
denigrating gcc. But you ASKED FOR IT
Sample code:
-------------------------------------------------------
#ifndef __CREATETYPELIB_H_
#define __CREATETYPELIB_H_
#include <oaidl.h>
#define MAX_IDENTIFIERNAME 128
#define MAX_PARAMS 32
typedef int TypeInfoID;
typedef struct CreateTypeInfo
{
ICreateTypeInfo *c;
int nfuncs;
GUID guid;
TYPEKIND kind;
} CreateTypeInfo;
#endif
----------------------------------------------------------
When compiling with -c neither MSVC nor lcc give any output
Output of mingw: (message continues afterwards)
In file included from
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/ole2.h:11,
from
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/windows.h:114,
from
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oaidl.h:8,
from vv.c:4:
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:172:
error: syntax error before "DISPID"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:174:
error: syntax error before "cc"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:178:
error: syntax error before '}' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:180:
error: syntax error before "METHODDATA"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:182:
error: syntax error before '}' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:213:
error: syntax error before "SAFEARRAY"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:214:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:215:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:215:
error: syntax error before "SAFEARRAYBOUND"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:216:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:217:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:218:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:219:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:220:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:221:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:222:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:223:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:224:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:225:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:226:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:227:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:228:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:229:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:230:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:231:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:232:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:233:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:234:
error: syntax error before "SAFEARRAY"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:235:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:236:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:237:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:238:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:239:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:240:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:241:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:242:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:243:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:244:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:245:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:253:
error: syntax error before "LCID"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:262:
error: syntax error before "LCID"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:271:
error: syntax error before "LCID"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:280:
error: syntax error before "LCID"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:289:
error: syntax error before "LCID"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:299:
error: syntax error before "LCID"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:308:
error: syntax error before "LCID"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:317:
error: syntax error before "LCID"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:327:
error: syntax error before "LCID"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:329:
error: syntax error before "LCID"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:330:
error: syntax error before "LCID"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:331:
error: syntax error before "LPTYPELIB"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:332:
error: syntax error before "LPTYPELIB"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:333:
error: syntax error before "LPTYPELIB"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:335:
error: syntax error before "OLECHAR"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:336:
error: syntax error before "SYSKIND"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:337:
error: syntax error before "const"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:338:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:339:
error: syntax error before "OLECHAR"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:340:
error: syntax error before "LPTYPEINFO"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:341:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:342:
error: syntax error before "LPTYPEINFO"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:346:
error: syntax error before "LPERRORINFO"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:347:
error: syntax error before "LPERRORINFO"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:348:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:350:
error: syntax error before "SAFEARRAY"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:351:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:353:
error: syntax error before "VARIANT"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:354:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:355:
error: syntax error before "IRecordInfo"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:376:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:392:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:408:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:425:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:441:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:457:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:473:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:490:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:506:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:522:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:538:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:554:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:570:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:587:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:603:
error: syntax error before '*' token
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:649:
error: syntax error before "int"
f:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/oleauto.h:650:
error: syntax error before "LCID"
vv.c:13: error: syntax error before "ICreateTypeInfo"
vv.c:13: warning: no semicolon at end of struct or union
vv.c:17: error: syntax error before '}' token
vv.c:17: warning: data definition has no type or storage class
Satisfied?
It chockes at its own includes!
Most examples in MSDN will not compile
Satisfied now?
jacob navia
P.S. if you insert the line at the top
#include <windows.h>
the output from mingw reduces to:
vv.c:13: error: syntax error before "ICreateTypeInfo"
vv.c:13: warning: no semicolon at end of struct or union
vv.c:17: error: syntax error before '}' token
vv.c:17: warning: data definition has no type or storage class
ICreateTypeInfo is defined in oaidl.h
After 15 minutes I could not find what is wrong
jacob navia
>
> I'm sorry, the context was that you claimed it was difficult to write
> windows application with MingW. At least two people have said it isn't
> as they've done it (including me). What the <expletive> does this have
> to do with how long doubles are handled? I don't think I have *ever*
> used long doubles they are not essential to windows programming.
>
> You also claimed "The fact that most windows headers are missing is OK
> with you too. ". I asked you which ones and you failed to respond. So
> which headers are missing?
>
> And I have yet to have it explained to me what "unix compiler is".
> If it runs under windows and generates windows binaries and provides
> acces to the most common windows libraries then it's a windows'
> compiler.
>
> good grief.
Yes, good grief
Try to compile this then (and this is just one example from thousands)
#ifndef __CREATETYPELIB_H_
#define __CREATETYPELIB_H_
#include <oaidl.h>
#define MAX_IDENTIFIERNAME 128
#define MAX_PARAMS 32
typedef int TypeInfoID;
typedef struct CreateTypeInfo
{
ICreateTypeInfo *c;
int nfuncs;
GUID guid;
TYPEKIND kind;
} CreateTypeInfo;
#endif
This compiles cleanly under lcc and MSVC
Keith Thompson
> Keith Thompson wrote:
>> Keith Thompson <ks...@mib.org> writes:
>>> jacob navia <ja...@jacob.remcomp.fr> writes:
>>> [...]
>>>> When my compiler doesn't emit an error when it sees // comments
>>>> using the undocumented ansic89 flag a posting will be done
>>>> by the regs indicating a "serious bug".
>>> [...]
>>>
>>> jacob, do you actually *read* this newsgroup?
>>>
>>> A single troll calling himself "Tea Pot" has repeatedly complained
>>> about this. The "regs" consistently reply that, since the ansic89
>>> flag is not documented, and since there's no claim that lcc-win
>>> supports C89/C90, it's not a bug, and that even if it were this is
>>> not the place to complain about it.
>>>
>>> On this particular point, we have consistently defended you. I,
>>> for one, would appreciate it if you'd pay a bit more attention
>>> and refrain from making unfounded accusations.
>>
>> jacob, somehow I'm not surprised that you chose to ignore this.
>> Disappointed, but not surprised.
>
> I did not want to write this since I do not want to start
> denigrating gcc. But you ASKED FOR IT
I most certainly did not. Please try to pay attention.
> Sample code:
> -------------------------------------------------------
[snip]
> ----------------------------------------------------------
> When compiling with -c neither MSVC nor lcc give any output
> Output of mingw: (message continues afterwards)
>
[snip 183 lines of error messages]
>
> Satisfied?
> It chockes at its own includes!
>
> Most examples in MSDN will not compile
> Satisfied now?
No.
Please re-read this thread. There's enough context quoted in
this article for you understand what I'm actually talking about,
but feel free to revisit the previous articles.
You claimed (among other things) that the "regs" have complained
about a mythical "serious bug" in lcc-win's behavior with the
ansic89 flag. In fact, the "regs" have done no such thing; instead,
we have consistently defended you on this point. The only claim
that this is a "serious bug" have come from a single troll who has
been universally flamed or ignored by everyone else here.
That is the only point I was trying to address. I was not talking
about mingw. (I may have discussed mingw in other contexts, but
not in this one.)
I did not respond to any other points you may have raised in
the same article simply because I had nothing to say about them.
This does not imply either agreement or disagreement with anything
else you might have said, nor does it imply that your other points
were unimportant. I simply did not comment on them.
This is not about a comparison between lcc-win and mingw or any
other compilers.
One more time: lcc-win's behavior of accepting "//" comments with
the ansic89 option is not a bug. A compiler whose documentation
does not claim support for C89/C90 needn't diagnose "//" comments as
a syntax error, and you are under no obligation to support C89/C90
unless you choose to do so. You are defending yourself against an
attack that never occurred, and accusing me and others of something
we did not do.
One more time: your statement, quoted above, that:
>>>> When my compiler doesn't emit an error when it sees // comments
>>>> using the undocumented ansic89 flag a posting will be done
>>>> by the regs indicating a "serious bug".
is untrue. That's all I was saying.
Please pay attention.
Richard Bos
> Richard Bos wrote:
> > Keith Thompson <ks...@mib.org> wrote:
> >> jacob navia <ja...@jacob.remcomp.fr> writes:
> >>> mongw doesn't work well under windows, unless you write
> >>> very simple console programs...
> >> My understanding is that mingw can be used to develop native Windows
> >> applications not just console programs. I can't comment on how good
> >> it is because I don't use it. (jacob's statement might be correct;
> >> I'm just providing a bit more information.)
> >
> > I _have_ used it. In fact, it is my most frequently used compiler. I can
> > say with all confidence that jacob is expostulating out of his
> > fundamental orifice.
>
> The fact that
> printf("%Lg\n",(long double)a);
>
> doesn't work is OK with you of course.
Since we were talking specifically about _Windows_ programming, not
about simple console output, yes, that is perfectly fine with me _for
Windows programming_. It would be undesirable for console programming,
which _you_, not I, claimed is the only thing Mingw is good for. Aren't
you contradicting yourself?
> The fact that most windows headers are missing is OK with you too.
I have yet to find one missing that I needed, so I think your contention
that "most" Windows headers are missing is misleading at the very least.
Richard
Mark McIntyre
> Keith Thompson wrote:
>>> for one, would appreciate it if you'd pay a bit more attention
>>> and refrain from making unfounded accusations.
>>
>> jacob, somehow I'm not surprised that you chose to ignore this.
>> Disappointed, but not surprised.
>>
>
> I did not want to write this since I do not want to start
> denigrating gcc. But you ASKED FOR IT
No, he asked for you acknowledge that on a specific point, the regulars
have consistently defended a false claim made about /your/ compiler,
despite your own claim to the contrary. I am not surprised you chose to
ignore it again. Disappointed, as Keith said, but not surprised.