From: Jiri K. <jirikrivanek@BetaControl.cz> - 2003-01-28 10:23:36
|
Hi, does the stdcall with Mirrosoft compilers mean the same as with GCC? In case of positive answer, my calling conventions are not wrong as they were written by Microsoft itself (the headers are taken from the Microsoft SDKs and the headers do contain the stdcall - actually it is __stdcall - directive at all its functions). More, I checked that the Delphi port of the same headers uses the stdcall too. The question stays: How can I make compiler not to append those @n's to external symbols (sustaining the stdcall calling convention)? I do not know the exact reason for why the Microsofts GDIPLUS.DLL exports do not have those @n's (even if they use the stdcall convention). Will someone help? Thaks & best regards, Kk. > Hi ! > > The @n is appended to a function name when the calling convention is set to > stdcall, @4 means as that the parameters use up 4 bytes, if you get this in > your compiled code, then the calling convention is set wrong in your > function prototypes. > > Mikael > > ----- Original Message ----- > From: "Jiri Krivanek" <jirikrivanek@BetaControl.cz> > To: <Min...@li...> > Sent: Tuesday, January 28, 2003 8:54 AM > Subject: Re: [Mingw-users] DLLS > > > > > Hi Jiri, > > > > > > > > > "Jiri Krivanek" <jirikrivanek@BetaControl.cz> writes: > > > > How can I call the Mul() export of the KK.DLL? Please, do not advice > > > > me to use the LoadLibrary() and the GetProcAddress() Windows APIs. > > > > There must be some other possibility. > > > > > > The quickest solution way is just adding the DLL to your link-line. I > > > just created these files to check: > > > > > > >>>>>>>>>>>>> kkh.h > > > #ifndef KKH > > > #define KKH > > > > > > extern int Mul(int a, int b); > > > > > > #endif // KKH > > > <<<<<<<<<<<<< > > > > > > >>>>>>>>>>>>> kkh.c > > > #include "kkh.h" > > > > > > extern int __declspec(dllexport) > > > Mul(int a, int b) > > > { > > > return a*b; > > > } > > > <<<<<<<<<<<<< > > > > > > >>>>>>>>>>>>> kkh-user.c > > > #include <stdio.h> > > > #include "kkh.h" > > > > > > extern int > > > main() > > > { > > > printf( "2*2=%d\n", Mul(2,2) ); > > > return 0; > > > } > > > <<<<<<<<<<<<< > > > > > > With these files these command-lines worked: > > > > > > c:\tmp> gcc -shared -o kkh.dll kkh.c > > > c:\tmp> gcc -o kkh-user.exe kkh-user.c kkh.dll > > > c:\tmp> kkh-user > > > 2*2=4 > > > > > > > > > Another way to do it is to create import libraries for the DLLs in > > > question. The w32api sources have examples how to do that, see the SF > > > download page (get there from http://sourceforge.net/projects/mingw). > > > > > > > > > Hope this helps, benny > > > > > > > > > > Hello, > > > > thanx for your advices. I tried to and the elementary example works > > fine. But my problem is a bit different. The DLL I want to call in my > > program is not written by me, I have no sources of it and it even was > > not compiled by the gcc. > > > > When I use the above mentioned technique, I receive the following > > linker error message (please note that this is only one of many): > > ...:main.c: undefined reference to 'GdipDeletePen@4' > > > > If I understand well, this means that the LD linker is looking for a > > function named 'GdipDeletePen@4' (the @4 might mean the size of stack > > required for parameters ???) but in the given gdiplus.dll there is no > > such export. If I simply look into the binary image of the > > gdiplus.dll I will locate the string 'GdipDeletePen' instead. This > > means that I have to make the compiler not to append the @<xx> > > characters to (at least some certain) external names. Well I am going > > to scan through the compilers command line options (to avoid > > appending @<xx> globally) as well as consult the gcc manual (to avoid > > appending @<xx> for some certain externals only). > > > > Thank you all for helphing me & best regards, > > > > Kk. > > > > Ing. Jiri Krivanek > > Realtime applications programmer > > Beta Control s.r.o. > > Cerneho 58/60 > > 635 00 BRNO-Bystrc > > CZECH REPUBLIC > > tel.: +420 5 46 22 34 91 - 36 > > email 1: JiriKrivanek@BetaControl.cz > > > > > > > > ------------------------------------------------------- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > http://www.vasoftware.com > > _______________________________________________ > > MinGW-users mailing list > > Min...@li... > > > > You may change your MinGW Account Options or unsubscribe at: > > https://lists.sourceforge.net/lists/listinfo/mingw-users > |
From: Jiri K. <jirikrivanek@BetaControl.cz> - 2003-01-28 10:42:36
|
Hi, the Delphi (it has been tested and it really works) uses the calling convention stdcall (Delphi specific keyword). From the Delphi help files I learned that the stdcall means: Directive: stdcall Parameter order: Right-to-left Clean-up: Routine Passes parameters in registers?: No Could you please tell me which one corresponds to the above mentioned specs in the GCC? Thank you very much, Kk. > The __stdcall calling convention requires the @nnn, if you don't have that, > it's not __stdcall, it's something else. > > __cdecl for example does not append anything, it just prepends a '_' in > front of the name. > > Mikael > > ----- Original Message ----- > From: "Jiri Krivanek" <jirikrivanek@BetaControl.cz> > To: "Mikael Aronsson" <mik...@te...> > Sent: Tuesday, January 28, 2003 11:21 AM > Subject: Re: [Mingw-users] DLLS > > > > Hi, > > > > does the stdcall with Mirrosoft compilers mean the same as with GCC? > > In case of positive answer, my calling conventions are not wrong as > > they were written by Microsoft itself (the headers are taken from the > > Microsoft SDKs and the headers do contain the stdcall - actually it > > is __stdcall - directive at all its functions). More, I checked that > > the Delphi port of the same headers uses the stdcall too. > > > > The question stays: How can I make compiler not to append those @n's > > to external symbols (sustaining the stdcall calling convention)? > > > > I do not know the exact reason for why the Microsofts GDIPLUS.DLL > > exports do not have those @n's (even if they use the stdcall > > convention). > > > > Will someone help? > > > > Thaks & best regards, > > > > Kk. > > > > > Hi ! > > > > > > The @n is appended to a function name when the calling convention is set > to > > > stdcall, @4 means as that the parameters use up 4 bytes, if you get this > in > > > your compiled code, then the calling convention is set wrong in your > > > function prototypes. > > > > > > Mikael > > > > > > ----- Original Message ----- > > > From: "Jiri Krivanek" <jirikrivanek@BetaControl.cz> > > > To: <Min...@li...> > > > Sent: Tuesday, January 28, 2003 8:54 AM > > > Subject: Re: [Mingw-users] DLLS > > > > > > > > > > > Hi Jiri, > > > > > > > > > > > > > > > "Jiri Krivanek" <jirikrivanek@BetaControl.cz> writes: > > > > > > How can I call the Mul() export of the KK.DLL? Please, do not > advice > > > > > > me to use the LoadLibrary() and the GetProcAddress() Windows APIs. > > > > > > There must be some other possibility. > > > > > > > > > > The quickest solution way is just adding the DLL to your link-line. > I > > > > > just created these files to check: > > > > > > > > > > >>>>>>>>>>>>> kkh.h > > > > > #ifndef KKH > > > > > #define KKH > > > > > > > > > > extern int Mul(int a, int b); > > > > > > > > > > #endif // KKH > > > > > <<<<<<<<<<<<< > > > > > > > > > > >>>>>>>>>>>>> kkh.c > > > > > #include "kkh.h" > > > > > > > > > > extern int __declspec(dllexport) > > > > > Mul(int a, int b) > > > > > { > > > > > return a*b; > > > > > } > > > > > <<<<<<<<<<<<< > > > > > > > > > > >>>>>>>>>>>>> kkh-user.c > > > > > #include <stdio.h> > > > > > #include "kkh.h" > > > > > > > > > > extern int > > > > > main() > > > > > { > > > > > printf( "2*2=%d\n", Mul(2,2) ); > > > > > return 0; > > > > > } > > > > > <<<<<<<<<<<<< > > > > > > > > > > With these files these command-lines worked: > > > > > > > > > > c:\tmp> gcc -shared -o kkh.dll kkh.c > > > > > c:\tmp> gcc -o kkh-user.exe kkh-user.c kkh.dll > > > > > c:\tmp> kkh-user > > > > > 2*2=4 > > > > > > > > > > > > > > > Another way to do it is to create import libraries for the DLLs in > > > > > question. The w32api sources have examples how to do that, see the > SF > > > > > download page (get there from > http://sourceforge.net/projects/mingw). > > > > > > > > > > > > > > > Hope this helps, benny > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > thanx for your advices. I tried to and the elementary example works > > > > fine. But my problem is a bit different. The DLL I want to call in my > > > > program is not written by me, I have no sources of it and it even was > > > > not compiled by the gcc. > > > > > > > > When I use the above mentioned technique, I receive the following > > > > linker error message (please note that this is only one of many): > > > > ...:main.c: undefined reference to 'GdipDeletePen@4' > > > > > > > > If I understand well, this means that the LD linker is looking for a > > > > function named 'GdipDeletePen@4' (the @4 might mean the size of stack > > > > required for parameters ???) but in the given gdiplus.dll there is no > > > > such export. If I simply look into the binary image of the > > > > gdiplus.dll I will locate the string 'GdipDeletePen' instead. This > > > > means that I have to make the compiler not to append the @<xx> > > > > characters to (at least some certain) external names. Well I am going > > > > to scan through the compilers command line options (to avoid > > > > appending @<xx> globally) as well as consult the gcc manual (to avoid > > > > appending @<xx> for some certain externals only). > > > > > > > > Thank you all for helphing me & best regards, > > > > > > > > Kk. > > > > > > > > Ing. Jiri Krivanek > > > > Realtime applications programmer > > > > Beta Control s.r.o. > > > > Cerneho 58/60 > > > > 635 00 BRNO-Bystrc > > > > CZECH REPUBLIC > > > > tel.: +420 5 46 22 34 91 - 36 > > > > email 1: JiriKrivanek@BetaControl.cz > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > This SF.NET email is sponsored by: > > > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > > > http://www.vasoftware.com > > > > _______________________________________________ > > > > MinGW-users mailing list > > > > Min...@li... > > > > > > > > You may change your MinGW Account Options or unsubscribe at: > > > > https://lists.sourceforge.net/lists/listinfo/mingw-users > > > > > > > Ing. Jiri Krivanek > > Realtime applications programmer > > Beta Control s.r.o. > > Cerneho 58/60 > > 635 00 BRNO-Bystrc > > CZECH REPUBLIC > > tel.: +420 5 46 22 34 91 - 36 > > email 1: JiriKrivanek@BetaControl.cz > > > Ing. Jiri Krivanek Realtime applications programmer Beta Control s.r.o. Cerneho 58/60 635 00 BRNO-Bystrc CZECH REPUBLIC tel.: +420 5 46 22 34 91 - 36 email 1: JiriKrivanek@BetaControl.cz |
From: Mikael A. <mik...@te...> - 2003-01-28 11:02:26
|
Hi ! If you don't belive, goto msdn.microsoft.com Enter __stdcall in the search field and pick the first hit, if you can read html, it look's like this: C++ Language Reference __stdcall Microsoft Specific The __stdcall calling convention is used to call Win32 API functions. The callee cleans the stack, so the compiler makes vararg functions __cdecl. Functions that use this calling convention require a function prototype. return-type __stdcall function-name[(argument-list)]The following list shows the implementation of this calling convention. Element Implementation Argument-passing order Right to left. Argument-passing convention By value, unless a pointer or reference type is passed. Stack-maintenance responsibility Called function pops its own arguments from the stack. Name-decoration convention An underscore (_) is prefixed to the name. The name is followed by the at sign (@) followed by the number of bytes (in decimal) in the argument list. Therefore, the function declared as int func( int a, double b ) is decorated as follows: _func@12 Case-translation convention None The /Gz compiler option specifies __stdcall for all functions not explicitly declared with a different calling convention. Functions declared using the __stdcall modifier return values the same way as functions declared using __cdecl. Example In the following example, use of __stdcall results in all WINAPI function types being handled as a standard call: // Example of the __stdcall keyword #define WINAPI __stdcall // Example of the __stdcall keyword on function pointer typedef BOOL (__stdcall *funcname_ptr)(void * arg1, const char * arg2, DWORD flags, ...);END Microsoft Specific See Also Argument Passing and Naming Conventions | C++ Keywords ----- Original Message ----- From: "Jiri Krivanek" <jirikrivanek@BetaControl.cz> To: "Mikael Aronsson" <mik...@te...>; <Min...@li...> Sent: Tuesday, January 28, 2003 11:42 AM Subject: Re: [Mingw-users] DLLS > Hi, > > the Delphi (it has been tested and it really works) uses the calling > convention stdcall (Delphi specific keyword). From the Delphi help > files I learned that the stdcall means: > > Directive: stdcall > Parameter order: Right-to-left > Clean-up: Routine > Passes parameters in registers?: No > > Could you please tell me which one corresponds to the above mentioned > specs in the GCC? > > Thank you very much, > > Kk. > > > The __stdcall calling convention requires the @nnn, if you don't have that, > > it's not __stdcall, it's something else. > > > > __cdecl for example does not append anything, it just prepends a '_' in > > front of the name. > > > > Mikael > > > > ----- Original Message ----- > > From: "Jiri Krivanek" <jirikrivanek@BetaControl.cz> > > To: "Mikael Aronsson" <mik...@te...> > > Sent: Tuesday, January 28, 2003 11:21 AM > > Subject: Re: [Mingw-users] DLLS > > > > > > > Hi, > > > > > > does the stdcall with Mirrosoft compilers mean the same as with GCC? > > > In case of positive answer, my calling conventions are not wrong as > > > they were written by Microsoft itself (the headers are taken from the > > > Microsoft SDKs and the headers do contain the stdcall - actually it > > > is __stdcall - directive at all its functions). More, I checked that > > > the Delphi port of the same headers uses the stdcall too. > > > > > > The question stays: How can I make compiler not to append those @n's > > > to external symbols (sustaining the stdcall calling convention)? > > > > > > I do not know the exact reason for why the Microsofts GDIPLUS.DLL > > > exports do not have those @n's (even if they use the stdcall > > > convention). > > > > > > Will someone help? > > > > > > Thaks & best regards, > > > > > > Kk. > > > > > > > Hi ! > > > > > > > > The @n is appended to a function name when the calling convention is set > > to > > > > stdcall, @4 means as that the parameters use up 4 bytes, if you get this > > in > > > > your compiled code, then the calling convention is set wrong in your > > > > function prototypes. > > > > > > > > Mikael > > > > > > > > ----- Original Message ----- > > > > From: "Jiri Krivanek" <jirikrivanek@BetaControl.cz> > > > > To: <Min...@li...> > > > > Sent: Tuesday, January 28, 2003 8:54 AM > > > > Subject: Re: [Mingw-users] DLLS > > > > > > > > > > > > > > Hi Jiri, > > > > > > > > > > > > > > > > > > "Jiri Krivanek" <jirikrivanek@BetaControl.cz> writes: > > > > > > > How can I call the Mul() export of the KK.DLL? Please, do not > > advice > > > > > > > me to use the LoadLibrary() and the GetProcAddress() Windows APIs. > > > > > > > There must be some other possibility. > > > > > > > > > > > > The quickest solution way is just adding the DLL to your link-line. > > I > > > > > > just created these files to check: > > > > > > > > > > > > >>>>>>>>>>>>> kkh.h > > > > > > #ifndef KKH > > > > > > #define KKH > > > > > > > > > > > > extern int Mul(int a, int b); > > > > > > > > > > > > #endif // KKH > > > > > > <<<<<<<<<<<<< > > > > > > > > > > > > >>>>>>>>>>>>> kkh.c > > > > > > #include "kkh.h" > > > > > > > > > > > > extern int __declspec(dllexport) > > > > > > Mul(int a, int b) > > > > > > { > > > > > > return a*b; > > > > > > } > > > > > > <<<<<<<<<<<<< > > > > > > > > > > > > >>>>>>>>>>>>> kkh-user.c > > > > > > #include <stdio.h> > > > > > > #include "kkh.h" > > > > > > > > > > > > extern int > > > > > > main() > > > > > > { > > > > > > printf( "2*2=%d\n", Mul(2,2) ); > > > > > > return 0; > > > > > > } > > > > > > <<<<<<<<<<<<< > > > > > > > > > > > > With these files these command-lines worked: > > > > > > > > > > > > c:\tmp> gcc -shared -o kkh.dll kkh.c > > > > > > c:\tmp> gcc -o kkh-user.exe kkh-user.c kkh.dll > > > > > > c:\tmp> kkh-user > > > > > > 2*2=4 > > > > > > > > > > > > > > > > > > Another way to do it is to create import libraries for the DLLs in > > > > > > question. The w32api sources have examples how to do that, see the > > SF > > > > > > download page (get there from > > http://sourceforge.net/projects/mingw). > > > > > > > > > > > > > > > > > > Hope this helps, benny > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > thanx for your advices. I tried to and the elementary example works > > > > > fine. But my problem is a bit different. The DLL I want to call in my > > > > > program is not written by me, I have no sources of it and it even was > > > > > not compiled by the gcc. > > > > > > > > > > When I use the above mentioned technique, I receive the following > > > > > linker error message (please note that this is only one of many): > > > > > ...:main.c: undefined reference to 'GdipDeletePen@4' > > > > > > > > > > If I understand well, this means that the LD linker is looking for a > > > > > function named 'GdipDeletePen@4' (the @4 might mean the size of stack > > > > > required for parameters ???) but in the given gdiplus.dll there is no > > > > > such export. If I simply look into the binary image of the > > > > > gdiplus.dll I will locate the string 'GdipDeletePen' instead. This > > > > > means that I have to make the compiler not to append the @<xx> > > > > > characters to (at least some certain) external names. Well I am going > > > > > to scan through the compilers command line options (to avoid > > > > > appending @<xx> globally) as well as consult the gcc manual (to avoid > > > > > appending @<xx> for some certain externals only). > > > > > > > > > > Thank you all for helphing me & best regards, > > > > > > > > > > Kk. > > > > > > > > > > Ing. Jiri Krivanek > > > > > Realtime applications programmer > > > > > Beta Control s.r.o. > > > > > Cerneho 58/60 > > > > > 635 00 BRNO-Bystrc > > > > > CZECH REPUBLIC > > > > > tel.: +420 5 46 22 34 91 - 36 > > > > > email 1: JiriKrivanek@BetaControl.cz > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This SF.NET email is sponsored by: > > > > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > > > > > http://www.vasoftware.com > > > > > _______________________________________________ > > > > > MinGW-users mailing list > > > > > Min...@li... > > > > > > > > > > You may change your MinGW Account Options or unsubscribe at: > > > > > https://lists.sourceforge.net/lists/listinfo/mingw-users > > > > > > > > > > Ing. Jiri Krivanek > > > Realtime applications programmer > > > Beta Control s.r.o. > > > Cerneho 58/60 > > > 635 00 BRNO-Bystrc > > > CZECH REPUBLIC > > > tel.: +420 5 46 22 34 91 - 36 > > > email 1: JiriKrivanek@BetaControl.cz > > > > > > > Ing. Jiri Krivanek > Realtime applications programmer > Beta Control s.r.o. > Cerneho 58/60 > 635 00 BRNO-Bystrc > CZECH REPUBLIC > tel.: +420 5 46 22 34 91 - 36 > email 1: JiriKrivanek@BetaControl.cz > |
From: Pavel H. <pav...@st...> - 2003-01-28 10:57:50
|
Hi, __declspec(dllexport) means really the same in both MSVC and Mingw GCC. I think that you should read docs for ld, especially --kill-at option could be useful in your case (sorry, do not know *exactly* how to use it or whether it will *really* solve this problem). In any case, it would be much more useful to extend w32api package with gdiplus, but this is much more work (this means writing headers and .def files from scratch only according to docs, not cheating by looking at or even reusing (parts of) M$ headers..) Pavel jirikrivanek@BetaControl.cz wrote: > Hi, > > the Delphi (it has been tested and it really works) uses the calling > convention stdcall (Delphi specific keyword). From the Delphi help > files I learned that the stdcall means: > > Directive: stdcall > Parameter order: Right-to-left > Clean-up: Routine > Passes parameters in registers?: No > > Could you please tell me which one corresponds to the above mentioned > specs in the GCC? > > Thank you very much, > > Kk. > > >>The __stdcall calling convention requires the @nnn, if you don't have that, >>it's not __stdcall, it's something else. >> >>__cdecl for example does not append anything, it just prepends a '_' in >>front of the name. >> >>Mikael >> >>----- Original Message ----- >>From: "Jiri Krivanek" <jirikrivanek@BetaControl.cz> >>To: "Mikael Aronsson" <mik...@te...> >>Sent: Tuesday, January 28, 2003 11:21 AM >>Subject: Re: [Mingw-users] DLLS >> >> >> >>>Hi, >>> >>>does the stdcall with Mirrosoft compilers mean the same as with GCC? >>>In case of positive answer, my calling conventions are not wrong as >>>they were written by Microsoft itself (the headers are taken from the >>>Microsoft SDKs and the headers do contain the stdcall - actually it >>>is __stdcall - directive at all its functions). More, I checked that >>>the Delphi port of the same headers uses the stdcall too. >>> >>>The question stays: How can I make compiler not to append those @n's >>>to external symbols (sustaining the stdcall calling convention)? >>> >>>I do not know the exact reason for why the Microsofts GDIPLUS.DLL >>>exports do not have those @n's (even if they use the stdcall >>>convention). >>> >>>Will someone help? >>> >>>Thaks & best regards, >>> >>>Kk. >>> >>> >>>>Hi ! >>>> >>>>The @n is appended to a function name when the calling convention is set >> >>to >> >>>>stdcall, @4 means as that the parameters use up 4 bytes, if you get this >> >>in >> >>>>your compiled code, then the calling convention is set wrong in your >>>>function prototypes. >>>> >>>>Mikael >>>> >>>>----- Original Message ----- >>>>From: "Jiri Krivanek" <jirikrivanek@BetaControl.cz> >>>>To: <Min...@li...> >>>>Sent: Tuesday, January 28, 2003 8:54 AM >>>>Subject: Re: [Mingw-users] DLLS >>>> >>>> >>>> >>>>>>Hi Jiri, >>>>>> >>>>>> >>>>>>"Jiri Krivanek" <jirikrivanek@BetaControl.cz> writes: >>>>>> >>>>>>>How can I call the Mul() export of the KK.DLL? Please, do not >> >>advice >> >>>>>>>me to use the LoadLibrary() and the GetProcAddress() Windows APIs. >>>>>>>There must be some other possibility. >>>>>> >>>>>>The quickest solution way is just adding the DLL to your link-line. >> >>I >> >>>>>>just created these files to check: >>>>>> >>>>>> >>>>>>>>>>>>>>>>>>>kkh.h >>>>>> >>>>>>#ifndef KKH >>>>>>#define KKH >>>>>> >>>>>>extern int Mul(int a, int b); >>>>>> >>>>>>#endif // KKH >>>>>><<<<<<<<<<<<< >>>>>> >>>>>>>>>>>>>>>>>>>kkh.c >>>>>> >>>>>>#include "kkh.h" >>>>>> >>>>>>extern int __declspec(dllexport) >>>>>>Mul(int a, int b) >>>>>>{ >>>>>>return a*b; >>>>>>} >>>>>><<<<<<<<<<<<< >>>>>> >>>>>>>>>>>>>>>>>>>kkh-user.c >>>>>> >>>>>>#include <stdio.h> >>>>>>#include "kkh.h" >>>>>> >>>>>>extern int >>>>>>main() >>>>>>{ >>>>>>printf( "2*2=%d\n", Mul(2,2) ); >>>>>>return 0; >>>>>>} >>>>>><<<<<<<<<<<<< >>>>>> >>>>>>With these files these command-lines worked: >>>>>> >>>>>> c:\tmp> gcc -shared -o kkh.dll kkh.c >>>>>> c:\tmp> gcc -o kkh-user.exe kkh-user.c kkh.dll >>>>>> c:\tmp> kkh-user >>>>>> 2*2=4 >>>>>> >>>>>> >>>>>>Another way to do it is to create import libraries for the DLLs in >>>>>>question. The w32api sources have examples how to do that, see the >> >>SF >> >>>>>>download page (get there from >> >>http://sourceforge.net/projects/mingw). >> >>>>>> >>>>>>Hope this helps, benny >>>>>> >>>>>> >>>>> >>>>>Hello, >>>>> >>>>>thanx for your advices. I tried to and the elementary example works >>>>>fine. But my problem is a bit different. The DLL I want to call in my >>>>>program is not written by me, I have no sources of it and it even was >>>>>not compiled by the gcc. >>>>> >>>>>When I use the above mentioned technique, I receive the following >>>>>linker error message (please note that this is only one of many): >>>>>...:main.c: undefined reference to 'GdipDeletePen@4' >>>>> >>>>>If I understand well, this means that the LD linker is looking for a >>>>>function named 'GdipDeletePen@4' (the @4 might mean the size of stack >>>>>required for parameters ???) but in the given gdiplus.dll there is no >>>>>such export. If I simply look into the binary image of the >>>>>gdiplus.dll I will locate the string 'GdipDeletePen' instead. This >>>>>means that I have to make the compiler not to append the @<xx> >>>>>characters to (at least some certain) external names. Well I am going >>>>>to scan through the compilers command line options (to avoid >>>>>appending @<xx> globally) as well as consult the gcc manual (to avoid >>>>>appending @<xx> for some certain externals only). >>>>> >>>>>Thank you all for helphing me & best regards, >>>>> >>>>>Kk. >>>>> >>>>> Ing. Jiri Krivanek >>>>> Realtime applications programmer >>>>> Beta Control s.r.o. >>>>> Cerneho 58/60 >>>>> 635 00 BRNO-Bystrc >>>>> CZECH REPUBLIC >>>>> tel.: +420 5 46 22 34 91 - 36 >>>>> email 1: JiriKrivanek@BetaControl.cz >>>>> >>>>> >>>>> >>>>>------------------------------------------------------- >>>>>This SF.NET email is sponsored by: >>>>>SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! >>>>>http://www.vasoftware.com >>>>>_______________________________________________ >>>>>MinGW-users mailing list >>>>>Min...@li... >>>>> >>>>>You may change your MinGW Account Options or unsubscribe at: >>>>>https://lists.sourceforge.net/lists/listinfo/mingw-users >>>> >>> Ing. Jiri Krivanek >>> Realtime applications programmer >>> Beta Control s.r.o. >>> Cerneho 58/60 >>> 635 00 BRNO-Bystrc >>> CZECH REPUBLIC >>> tel.: +420 5 46 22 34 91 - 36 >>> email 1: JiriKrivanek@BetaControl.cz >>> >> > > Ing. Jiri Krivanek > Realtime applications programmer > Beta Control s.r.o. > Cerneho 58/60 > 635 00 BRNO-Bystrc > CZECH REPUBLIC > tel.: +420 5 46 22 34 91 - 36 > email 1: JiriKrivanek@BetaControl.cz > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users |
From: Jiri K. <jirikrivanek@BetaControl.cz> - 2003-01-28 11:32:51
|
Well, this confirms that the gdiplus.dll really uses the stdcall calling convention. Evidences: 1. Delphi port uses stdcall. 2. In Delphi, it is possible to specify the name of external function to be completely different from the internal implementation identifier name. 3. The Delphi port has been tested and works. 4. Explanation of stdcall by Delphi is the same as explanation of the stdcall by Microsoft. Actually to Microsofts one is much more detailed. But as far as I understand they both say the same. 5. Microsoft original SDKs for GDI+ do contain the stdcall directive. 6. In the GDI+ (binary) there are no prefixes (_) as well as no postfixes (@nnn) of the exported functions. 7. I am not able to change the gdiplus.dll. 8. The GCC requires the those prefixes and postfixes whenever the stdcall calling convention is used. E.g. in case of extern int __stdcall Mul(int, int);, the LD will probably look for Mul@8. My question stays: How can I link my program with gdiplus.dll? Consequently, how can I make the LD to look for the external functions using the stdcall calling convention named without those prefixes & postfixes? Consequently, how can I make the compiler to generate external symbols (in the .o files) of functions using the stdcall calling convention named without those prefixes & postfixes? Thank you for your support & best regards, Kk. P.S. I tried many command line options (including --kill-at) having no success. > Hi ! > > If you don't belive, goto msdn.microsoft.com > > Enter __stdcall in the search field and pick the first hit, if you can read > html, it look's like this: > > > C++ Language Reference > > __stdcall > Microsoft Specific > > The __stdcall calling convention is used to call Win32 API functions. The > callee cleans the stack, so the compiler makes vararg functions __cdecl. > Functions that use this calling convention require a function prototype. > > return-type __stdcall function-name[(argument-list)]The following list shows > the implementation of this calling convention. > > Element Implementation > Argument-passing order Right to left. > Argument-passing convention By value, unless a pointer or reference > type is passed. > Stack-maintenance responsibility Called function pops its own > arguments from the stack. > Name-decoration convention An underscore (_) is prefixed to the name. > The name is followed by the at sign (@) followed by the number of bytes (in > decimal) in the argument list. Therefore, the function declared as int > func( int a, double b ) is decorated as follows: _func@12 > Case-translation convention None > > The /Gz compiler option specifies __stdcall for all functions not explicitly > declared with a different calling convention. > > Functions declared using the __stdcall modifier return values the same way > as functions declared using __cdecl. > > Example > In the following example, use of __stdcall results in all WINAPI function > types being handled as a standard call: > > // Example of the __stdcall keyword > #define WINAPI __stdcall > // Example of the __stdcall keyword on function pointer > typedef BOOL (__stdcall *funcname_ptr)(void * arg1, const char * arg2, DWORD > flags, ...);END Microsoft Specific > > See Also > Argument Passing and Naming Conventions | C++ Keywords > > ----- Original Message ----- > From: "Jiri Krivanek" <jirikrivanek@BetaControl.cz> > To: "Mikael Aronsson" <mik...@te...>; > <Min...@li...> > Sent: Tuesday, January 28, 2003 11:42 AM > Subject: Re: [Mingw-users] DLLS > > > > Hi, > > > > the Delphi (it has been tested and it really works) uses the calling > > convention stdcall (Delphi specific keyword). From the Delphi help > > files I learned that the stdcall means: > > > > Directive: stdcall > > Parameter order: Right-to-left > > Clean-up: Routine > > Passes parameters in registers?: No > > > > Could you please tell me which one corresponds to the above mentioned > > specs in the GCC? > > > > Thank you very much, > > > > Kk. > > > > > The __stdcall calling convention requires the @nnn, if you don't have > that, > > > it's not __stdcall, it's something else. > > > > > > __cdecl for example does not append anything, it just prepends a '_' in > > > front of the name. > > > > > > Mikael > > > > > > ----- Original Message ----- > > > From: "Jiri Krivanek" <jirikrivanek@BetaControl.cz> > > > To: "Mikael Aronsson" <mik...@te...> > > > Sent: Tuesday, January 28, 2003 11:21 AM > > > Subject: Re: [Mingw-users] DLLS > > > > > > > > > > Hi, > > > > > > > > does the stdcall with Mirrosoft compilers mean the same as with GCC? > > > > In case of positive answer, my calling conventions are not wrong as > > > > they were written by Microsoft itself (the headers are taken from the > > > > Microsoft SDKs and the headers do contain the stdcall - actually it > > > > is __stdcall - directive at all its functions). More, I checked that > > > > the Delphi port of the same headers uses the stdcall too. > > > > > > > > The question stays: How can I make compiler not to append those @n's > > > > to external symbols (sustaining the stdcall calling convention)? > > > > > > > > I do not know the exact reason for why the Microsofts GDIPLUS.DLL > > > > exports do not have those @n's (even if they use the stdcall > > > > convention). > > > > > > > > Will someone help? > > > > > > > > Thaks & best regards, > > > > > > > > Kk. > > > > > > > > > Hi ! > > > > > > > > > > The @n is appended to a function name when the calling convention is > set > > > to > > > > > stdcall, @4 means as that the parameters use up 4 bytes, if you get > this > > > in > > > > > your compiled code, then the calling convention is set wrong in your > > > > > function prototypes. > > > > > > > > > > Mikael > > > > > > > > > > ----- Original Message ----- > > > > > From: "Jiri Krivanek" <jirikrivanek@BetaControl.cz> > > > > > To: <Min...@li...> > > > > > Sent: Tuesday, January 28, 2003 8:54 AM > > > > > Subject: Re: [Mingw-users] DLLS > > > > > > > > > > > > > > > > > Hi Jiri, > > > > > > > > > > > > > > > > > > > > > "Jiri Krivanek" <jirikrivanek@BetaControl.cz> writes: > > > > > > > > How can I call the Mul() export of the KK.DLL? Please, do not > > > advice > > > > > > > > me to use the LoadLibrary() and the GetProcAddress() Windows > APIs. > > > > > > > > There must be some other possibility. > > > > > > > > > > > > > > The quickest solution way is just adding the DLL to your > link-line. > > > I > > > > > > > just created these files to check: > > > > > > > > > > > > > > >>>>>>>>>>>>> kkh.h > > > > > > > #ifndef KKH > > > > > > > #define KKH > > > > > > > > > > > > > > extern int Mul(int a, int b); > > > > > > > > > > > > > > #endif // KKH > > > > > > > <<<<<<<<<<<<< > > > > > > > > > > > > > > >>>>>>>>>>>>> kkh.c > > > > > > > #include "kkh.h" > > > > > > > > > > > > > > extern int __declspec(dllexport) > > > > > > > Mul(int a, int b) > > > > > > > { > > > > > > > return a*b; > > > > > > > } > > > > > > > <<<<<<<<<<<<< > > > > > > > > > > > > > > >>>>>>>>>>>>> kkh-user.c > > > > > > > #include <stdio.h> > > > > > > > #include "kkh.h" > > > > > > > > > > > > > > extern int > > > > > > > main() > > > > > > > { > > > > > > > printf( "2*2=%d\n", Mul(2,2) ); > > > > > > > return 0; > > > > > > > } > > > > > > > <<<<<<<<<<<<< > > > > > > > > > > > > > > With these files these command-lines worked: > > > > > > > > > > > > > > c:\tmp> gcc -shared -o kkh.dll kkh.c > > > > > > > c:\tmp> gcc -o kkh-user.exe kkh-user.c kkh.dll > > > > > > > c:\tmp> kkh-user > > > > > > > 2*2=4 > > > > > > > > > > > > > > > > > > > > > Another way to do it is to create import libraries for the DLLs > in > > > > > > > question. The w32api sources have examples how to do that, see > the > > > SF > > > > > > > download page (get there from > > > http://sourceforge.net/projects/mingw). > > > > > > > > > > > > > > > > > > > > > Hope this helps, benny > > > > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > thanx for your advices. I tried to and the elementary example > works > > > > > > fine. But my problem is a bit different. The DLL I want to call in > my > > > > > > program is not written by me, I have no sources of it and it even > was > > > > > > not compiled by the gcc. > > > > > > > > > > > > When I use the above mentioned technique, I receive the following > > > > > > linker error message (please note that this is only one of many): > > > > > > ...:main.c: undefined reference to 'GdipDeletePen@4' > > > > > > > > > > > > If I understand well, this means that the LD linker is looking for > a > > > > > > function named 'GdipDeletePen@4' (the @4 might mean the size of > stack > > > > > > required for parameters ???) but in the given gdiplus.dll there is > no > > > > > > such export. If I simply look into the binary image of the > > > > > > gdiplus.dll I will locate the string 'GdipDeletePen' instead. This > > > > > > means that I have to make the compiler not to append the @<xx> > > > > > > characters to (at least some certain) external names. Well I am > going > > > > > > to scan through the compilers command line options (to avoid > > > > > > appending @<xx> globally) as well as consult the gcc manual (to > avoid > > > > > > appending @<xx> for some certain externals only). > > > > > > > > > > > > Thank you all for helphing me & best regards, > > > > > > > > > > > > Kk. > > > > > > > > > > > > Ing. Jiri Krivanek > > > > > > Realtime applications programmer > > > > > > Beta Control s.r.o. > > > > > > Cerneho 58/60 > > > > > > 635 00 BRNO-Bystrc > > > > > > CZECH REPUBLIC > > > > > > tel.: +420 5 46 22 34 91 - 36 > > > > > > email 1: JiriKrivanek@BetaControl.cz > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > This SF.NET email is sponsored by: > > > > > > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 > See! > > > > > > http://www.vasoftware.com > > > > > > _______________________________________________ > > > > > > MinGW-users mailing list > > > > > > Min...@li... > > > > > > > > > > > > You may change your MinGW Account Options or unsubscribe at: > > > > > > https://lists.sourceforge.net/lists/listinfo/mingw-users > > > > > > > > > > > > > Ing. Jiri Krivanek > > > > Realtime applications programmer > > > > Beta Control s.r.o. > > > > Cerneho 58/60 > > > > 635 00 BRNO-Bystrc > > > > CZECH REPUBLIC > > > > tel.: +420 5 46 22 34 91 - 36 > > > > email 1: JiriKrivanek@BetaControl.cz > > > > > > > > > > > Ing. Jiri Krivanek > > Realtime applications programmer > > Beta Control s.r.o. > > Cerneho 58/60 > > 635 00 BRNO-Bystrc > > CZECH REPUBLIC > > tel.: +420 5 46 22 34 91 - 36 > > email 1: JiriKrivanek@BetaControl.cz > > > Ing. Jiri Krivanek Realtime applications programmer Beta Control s.r.o. Cerneho 58/60 635 00 BRNO-Bystrc CZECH REPUBLIC tel.: +420 5 46 22 34 91 - 36 email 1: JiriKrivanek@BetaControl.cz |
From: Earnie B. <ear...@ya...> - 2003-01-28 11:40:32
|
Jiri Krivanek wrote: > > P.S. I tried many command line options (including --kill-at) having > no success. > What exactly is the many command line you use. This is beginning sound as if you have command line ordering issues. Command line order matters, the library references must be toward the end of the command line. Earnie. |
From: Jiri K. <jirikrivanek@BetaControl.cz> - 2003-01-28 11:55:47
|
Hi, My makefile contains: ------------------------------ MODULES = main.o FLAGS = -ggdb test.exe: clear-screen $(MODULES) g++ -mwindows -mconsole -otest.exe $(MODULES) gdiplus.dll main.o: main.c gdiplus.h makefile g++ $(FLAGS) -c main.c clean: del *.o del *.exe release: test.exe strip --strip-all test.exe gdiplus.h: GdiplusMem.h GdiplusBase.h GdiplusEnums.h GdiplusTypes.h GdiplusInit.h GdiplusPixelFormats.h GdiplusColor.h GdiplusMetaHeader.h GdiplusImaging.h GdiplusColorMatrix.h GdiplusGpStubs.h GdiplusHeaders.h GdiplusFlat.h GdiplusImageAttributes.h GdiplusMatrix.h GdiplusBrush.h GdiplusPen.h GdiplusStringFormat.h GdiplusPath.h GdiplusLineCaps.h GdiplusMetafile.h GdiplusGraphics.h GdiplusCachedBitmap.h GdiplusRegion.h GdiplusFontCollection.h GdiplusFontFamily.h GdiplusFont.h GdiplusBitmap.h GdiplusImageCodec.h clear-screen: cls ------------------------------ If I specify the stdcall (note that it is driven globally by the WINGDIPAPI macro) to the GDI+ flat API externals the link fails. Please note that the ts stdcall WAS originally specified in the headers by Microsoft. If I do not specify (leave the WINGDIPAPI macro empty) the link succeeds but the code does not work (using gdb I discovered that it crashes when trying to enter to (or return from ??? do not know) the GDI+ DLL. Under Delphi it works fine. But Delphi uses stdcall. By my understanding the problem is in the calling conventions. Thanks, Jiri. > Jiri Krivanek wrote: > > > > P.S. I tried many command line options (including --kill-at) having > > no success. > > > > What exactly is the many command line you use. This is beginning sound > as if you have command line ordering issues. Command line order > matters, the library references must be toward the end of the command line. > > Earnie. > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Ing. Jiri Krivanek Realtime applications programmer Beta Control s.r.o. Cerneho 58/60 635 00 BRNO-Bystrc CZECH REPUBLIC tel.: +420 5 46 22 34 91 - 36 email 1: JiriKrivanek@BetaControl.cz |
From: Earnie B. <ear...@ya...> - 2003-01-28 14:18:01
|
Jiri Krivanek wrote: > Hi, > > My makefile contains: > > ------------------------------ > > MODULES = main.o > FLAGS = -ggdb > > test.exe: clear-screen $(MODULES) > g++ -mwindows -mconsole -otest.exe $(MODULES) gdiplus.dll > You need to make up your mind, is it a windows program or a console program? One or the other not both. > main.o: main.c gdiplus.h makefile > g++ $(FLAGS) -c main.c > Hmm, your file is named main.c yet you say it is C++ so you use g++ yet a file with an extension of .c references a C program. So what's the contents of main.c? BTW, as has been said, C++ runtimes between compilers don't mingle well. You should be able to use LoadLibrary and GetProcAddress for actually using the functions within gdiplus.dll. Earnie. |
From: Luke D. <cod...@ho...> - 2003-01-29 01:17:57
|
----- Original Message ----- From: "Earnie Boyd" <ear...@ya...> To: "Jiri Krivanek" <jirikrivanek@BetaControl.cz> Cc: "MinGW Users" <min...@li...> Sent: Tuesday, January 28, 2003 10:16 PM Subject: Re: [Mingw-users] DLLS > Jiri Krivanek wrote: > > Hi, > > > > My makefile contains: > > > > ------------------------------ > > > > MODULES = main.o > > FLAGS = -ggdb > > > > test.exe: clear-screen $(MODULES) > > g++ -mwindows -mconsole -otest.exe $(MODULES) gdiplus.dll > > > > You need to make up your mind, is it a windows program or a console > program? One or the other not both. Based on the specs file I think using "-mwindows -mconsole" is the same as "-mconsole ... -lgdi32 -lcomdlg32", but I'm not certain. I'm sure Jiri read about this on the MinGW documentation page: "The -mwindows switch is needed to create Windows executables instead of console applications. It assures the appropriate Windows libraries are linked in for you. To get a console screen along with a standard windows application, add the -mconsole flag as well as -mwindows." > > > main.o: main.c gdiplus.h makefile > > g++ $(FLAGS) -c main.c > > > > Hmm, your file is named main.c yet you say it is C++ so you use g++ yet > a file with an extension of .c references a C program. So what's the > contents of main.c? > > BTW, as has been said, C++ runtimes between compilers don't mingle well. > You should be able to use LoadLibrary and GetProcAddress for actually > using the functions within gdiplus.dll. > > > Earnie. Luke |
From: Oscar F. <of...@wa...> - 2003-01-28 19:21:41
|
"Jiri Krivanek" <jirikrivanek@BetaControl.cz> writes: > Hi, > > My makefile contains: > > ------------------------------ > > MODULES = main.o > FLAGS = -ggdb > > test.exe: clear-screen $(MODULES) > g++ -mwindows -mconsole -otest.exe $(MODULES) gdiplus.dll Shouldn't this be g++ -mwindows -mconsole -otest.exe $(MODULES) -lgdiplus [Jiri and others: it is not necessasary to quote an entire thread to respond to a message. Please trim your quotes on the future. Thanks.] -- Oscar |
From: Jiri K. <jirikrivanek@BetaControl.cz> - 2003-01-29 07:09:25
|
> "Jiri Krivanek" <jirikrivanek@BetaControl.cz> writes: > > > Hi, > > > > My makefile contains: > > > > ------------------------------ > > > > MODULES = main.o > > FLAGS = -ggdb > > > > test.exe: clear-screen $(MODULES) > > g++ -mwindows -mconsole -otest.exe $(MODULES) gdiplus.dll > > Shouldn't this be > > g++ -mwindows -mconsole -otest.exe $(MODULES) -lgdiplus > > [Jiri and others: it is not necessasary to quote an entire thread to > respond to a message. Please trim your quotes on the future. Thanks.] Sorry, I do not know what you mean at all. Sorry for my pure english ... thread is an execution of some soce upon dedicated stack which resides inside of process ... quote is this: " ... I am really missing the point ... > > -- > Oscar > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Ing. Jiri Krivanek Realtime applications programmer Beta Control s.r.o. Cerneho 58/60 635 00 BRNO-Bystrc CZECH REPUBLIC tel.: +420 5 46 22 34 91 - 36 email 1: JiriKrivanek@BetaControl.cz |
From: Oscar F. <of...@wa...> - 2003-01-29 20:29:58
|
"Jiri Krivanek" <jirikrivanek@BetaControl.cz> writes: > > [Jiri and others: it is not necessasary to quote an entire thread to > > respond to a message. Please trim your quotes on the future. Thanks.] > > Sorry, I do not know what you mean at all. Sorry for my pure english > ... thread is an execution of some soce upon dedicated stack which > resides inside of process ... quote is this: " ... I am really > missing the point ... On a mailing list or newsgroup, a "thread" is a series of related messagess: replies, replies to replies, etc. A "quote" is a part of a previous message you include on your reply with the purpose of giving a context to what you say. This implies that quoted text is there to be read by those who doesn't know what was said on the message you are replying. If you quote unnecessary text you are wasting other people's time. If you quote signatures, advertisements, etc you are forcing the reader to scroll down the window and look hard for the part where you write your reply. Just think about what would happen if nobody trims the quoted text on his replies: each message would contain the original post, the reply to the original post, the reply to the reply to the original post... Very soon you end with several thousands lines of text on each message. -- Oscar |
From: Jiri K. <jirikrivanek@BetaControl.cz> - 2003-01-28 14:28:50
|
Hi, > Jiri Krivanek wrote: > > Hi, > > > > My makefile contains: > > > > ------------------------------ > > > > MODULES = main.o > > FLAGS = -ggdb > > > > test.exe: clear-screen $(MODULES) > > g++ -mwindows -mconsole -otest.exe $(MODULES) gdiplus.dll > > Somewhere I read that this is posible. I am using the console for getting the debug messages. It is simple and very efficient. > > You need to make up your mind, is it a windows program or a console > program? One or the other not both. > > > main.o: main.c gdiplus.h makefile > > g++ $(FLAGS) -c main.c > > > > Hmm, your file is named main.c yet you say it is C++ so you use g++ yet > a file with an extension of .c references a C program. So what's the > contents of main.c? Yes, this is a bit ambiguous. The reason is that this only is a simple test project, I have not thought too much about the file names. Actually it contains the C++ code and thus it is compiled with g++. I believe that there is no real problem here. > > BTW, as has been said, C++ runtimes between compilers don't mingle well. > You should be able to use LoadLibrary and GetProcAddress for actually > using the functions within gdiplus.dll. Well, this is what I know from the beginning. Please note that there is more than 600 (SIX HUNDRED !!!) functions exported with the gdiplus.dll. I am not going to completely rewrite the SDKs as I am not a student having lots of spare time any more :-)( - UNFORTUNATELY!!! > > > > Earnie. > It is very strange that this problem cannot be conveniently solved using such a powerfull tool like GCC is. I think that we only missed something important. Thank you & regards, Kk. Ing. Jiri Krivanek Realtime applications programmer Beta Control s.r.o. Cerneho 58/60 635 00 BRNO-Bystrc CZECH REPUBLIC tel.: +420 5 46 22 34 91 - 36 email 1: JiriKrivanek@BetaControl.cz |
From: Earnie B. <ear...@ya...> - 2003-01-28 14:41:12
|
Jiri Krivanek wrote: >> >>Hmm, your file is named main.c yet you say it is C++ so you use g++ yet >>a file with an extension of .c references a C program. So what's the >>contents of main.c? > > > Yes, this is a bit ambiguous. The reason is that this only is a > simple test project, I have not thought too much about the file > names. Actually it contains the C++ code and thus it is compiled with > g++. I believe that there is no real problem here. > Asking again, what are the contents of main.c? Earnie. |
From: Jiri K. <jirikrivanek@BetaControl.cz> - 2003-01-28 14:44:54
|
Sorry I misunderstood that you want the listing. Here we go: --------------------------------- #include <stdio.h> #include <windows.h> #include "gdiplus.h" using namespace Gdiplus; static void OnPaint( HDC ADC ) { FontFamily BFontFamily(L"Arial"); StringFormat BStringFormat; GraphicsPath BPath; BPath.AddString( L"Kakáèek", -1, &BFontFamily, FontStyleBold, 40.0, PointF( 20.0, 20.0 ), NULL ); Pen BPen( Color( 0, 0, 0 ), 2.7 ); SolidBrush BBrush( Color( 255, 255, 255 ) ); Graphics BGraphics( ADC ); BGraphics.SetSmoothingMode( SmoothingModeAntiAlias ); BGraphics.Clear( Color( 40, 40, 128 ) ); BGraphics.FillPath( &BBrush, &BPath ); BGraphics.DrawPath( &BPen, &BPath ); } static LRESULT WINAPI WndProc( HWND AWindow, UINT AMessage, WPARAM AWParam, LPARAM ALParam ) { HDC BHDC; PAINTSTRUCT BPs; switch( AMessage ) { case WM_PAINT: BHDC = BeginPaint( AWindow, &BPs ); OnPaint( BHDC ); EndPaint( AWindow, &BPs ); return 0; case WM_ERASEBKGND: return 0; case WM_DESTROY: PostQuitMessage( 0 ); return 0; default: return DefWindowProc(AWindow, AMessage, AWParam, ALParam); } } int WINAPI WinMain( HINSTANCE AHInstance, HINSTANCE AHPrevInstance, PSTR ACmdLine, int ACmdShow ) { try { ULONG_PTR BGdiPlusToken; GdiplusStartupInput BGdiPlusInput; GdiplusStartup( &BGdiPlusToken, &BGdiPlusInput, NULL ); /*{ printf( "Enumerating installed fonts:\n" ); InstalledFontCollection BIF; int BIFC = BIF.GetFamilyCount(), BIFFC; printf( " - number of fonts = %d\n", BIFC ); FontFamily *BFFA = new FontFamily[BIFC]; BIF.GetFamilies( BIFC, BFFA, &BIFFC ); printf( " - number of fonts obtained = %d\n", BIFFC ); for( int BI = 0; BI < BIFC; ++BI ) { WCHAR BFNN[2048]; BFFA[BI].GetFamilyName( BFNN ); char BFNNS[2048]; for( int BJ = 0; BJ < 2048; ++BJ ) BFNNS[BJ] = (char)BFNN[BJ]; BFNNS[2047] = 0; //printf( "Font %03d: %s\n", BI, BFNNS ); } delete[] BFFA; }*/ HWND BWnd; WNDCLASS BClass; BClass.style = CS_HREDRAW | CS_VREDRAW; BClass.lpfnWndProc = &WndProc; BClass.cbClsExtra = 0; BClass.cbWndExtra = 0; BClass.hInstance = AHInstance; BClass.hIcon = LoadIcon(0, IDI_APPLICATION); BClass.hCursor = LoadCursor(0, IDC_ARROW); BClass.hbrBackground = HBRUSH(GetStockObject(WHITE_BRUSH)); BClass.lpszMenuName = NULL; BClass.lpszClassName = "KK GDIPLUS 1"; if( RegisterClass( &BClass ) == 0 ) throw "Error registering window class"; BWnd = CreateWindow( BClass.lpszClassName, // window class name "Kk GDI+: 1", // window caption WS_OVERLAPPEDWINDOW, // window style CW_USEDEFAULT, // initial x position CW_USEDEFAULT, // initial y position CW_USEDEFAULT, // initial x size CW_USEDEFAULT, // initial y size 0, // parent window handle 0, // window menu handle AHInstance, // program instance handle NULL // creation parameters ); if( BWnd == NULL ) throw "Error creating window"; ShowWindow( BWnd, SW_SHOW ); UpdateWindow( BWnd ); MSG BMsg; while( GetMessage( &BMsg, 0, 0, 0 ) ) { TranslateMessage( &BMsg ); DispatchMessage( &BMsg ); } GdiplusShutdown( BGdiPlusToken ); printf( "OK\n\n" ); return 0; } catch( const char *t ) { printf( "Error: %s\n\n", t ); return 1; } catch(...) { printf( "Error: Unknown exception\n\n" ); return 1; } } --------------------------------- Kk. > Jiri Krivanek wrote: > >> > >>Hmm, your file is named main.c yet you say it is C++ so you use g++ yet > >>a file with an extension of .c references a C program. So what's the > >>contents of main.c? > > > > > > Yes, this is a bit ambiguous. The reason is that this only is a > > simple test project, I have not thought too much about the file > > names. Actually it contains the C++ code and thus it is compiled with > > g++. I believe that there is no real problem here. > > > > Asking again, what are the contents of main.c? > > Earnie. > Ing. Jiri Krivanek Realtime applications programmer Beta Control s.r.o. Cerneho 58/60 635 00 BRNO-Bystrc CZECH REPUBLIC tel.: +420 5 46 22 34 91 - 36 email 1: JiriKrivanek@BetaControl.cz |
From: Jerry v. D. <jv...@at...> - 2003-01-29 01:37:29
|
> So the process is: Create a function list for the GDI+ DLLs (use a > script based on objdump), add the right suffixes (4 * > number-of-parameters) and create an import library. And they lived > happily ever after ;-). Yes, or if you have an MS import library use my old lib2def utility: lib2def gdiplus.lib > gdiplus.def dlltool -D gdiplus.dll -d gdiplus.def -l libgdiplus.a the (Ada) source to lib2def is on my homepage. -- Jerry van Dijk | email: jd...@ac... -- Leiden, Holland | web: users.ncrvnet.nl/gmvdijk |
From: Earnie B. <ear...@ya...> - 2003-01-28 11:34:11
|
Jiri Krivanek wrote: > Hi, > > does the stdcall with Mirrosoft compilers mean the same as with GCC? > In case of positive answer, my calling conventions are not wrong as > they were written by Microsoft itself (the headers are taken from the > Microsoft SDKs and the headers do contain the stdcall - actually it > is __stdcall - directive at all its functions). More, I checked that > the Delphi port of the same headers uses the stdcall too. > > The question stays: How can I make compiler not to append those @n's > to external symbols (sustaining the stdcall calling convention)? > > I do not know the exact reason for why the Microsofts GDIPLUS.DLL > exports do not have those @n's (even if they use the stdcall > convention). > > Will someone help? > Have you tried ``gcc -o myfoo.exe myfoo.o somebar.dll''? Since you have the header for the dll, you can use a utility named pexports from http://prdownloads.sf.net/mingw/mingw-utils-0.2.tar.gz to create an export definition file so that you can use dlltool to create an import library. Earnie. |