Thanks.
So I'll stay with my current hand hacked .spec.c file.
It does work at least.
My be we should define a new keyword in spec files, let's say
"decorated" which implies stdcall and keeps the decoration on the
export/import table. I'll look into it once I finish my current doing.
Free Life
B
"Boaz Harrosh" <[EMAIL PROTECTED]> wrote:
> I have noticed that my .spec.c file is very different than your .spec.c
> file from above. I am using winebuild downloaded from source forge, as
> of 20031212.
>
> Now if I use your suggested .spec file. I am missing the FooSTD
> altogether. If I rem
Dmitry Timoshkov wrote:
Foo.spec:
@ stdcall [EMAIL PROTECTED]@8(long long) fnFooSTD
@ cdecl fnFooC (long long) fnFooC
resulted Foo.spec.c:
asm(".data\n"
"\t.align 4\n"
"__wine_spec_exports:\n"
"\t.long 0\n"
"\t.long 0\n"
"\t.long 0\n"
"\t.long __wine_spec_exp_names\n"
"
On Fri, 26 Dec 2003, Dmitry Timoshkov wrote:
> "Kevin Atkinson" <[EMAIL PROTECTED]> wrote:
>
> > If the names are not decorated in that fashion mingw has a problem linking
> > with it. When linked the linker is looking for the names with the
> > '@' decoration.
>
> ... in the object files. Th
"Kevin Atkinson" <[EMAIL PROTECTED]> wrote:
> If the names are not decorated in that fashion mingw has a problem linking
> with it. When linked the linker is looking for the names with the
> '@' decoration.
... in the object files. That's a way compilers treat __stdcall keyword
in the windows
On Fri, 26 Dec 2003, Dmitry Timoshkov wrote:
> "Kevin Atkinson" <[EMAIL PROTECTED]> wrote:
>
> > That is a heck of a lot of work to link with a DLL that is not compiled
> > with an exports table.
>
> I don't understand you. If a DLL exports something (i.e. has a not zero
> export directory in t
"Kevin Atkinson" <[EMAIL PROTECTED]> wrote:
> That is a heck of a lot of work to link with a DLL that is not compiled
> with an exports table.
I don't understand you. If a DLL exports something (i.e. has a not zero
export directory in the PE header), then it definitely has an export table.
> Fu
On Thu, 25 Dec 2003, Dmitry Timoshkov wrote:
> "Boaz Harrosh" <[EMAIL PROTECTED]> wrote:
>
> > I did, I have tried both your suggestions.
> >
> > What ever you do. any thing after the @ sign gets truncated in the
> > import process and will not
> > Reach the Import table.
> >
> > Note that in
"Boaz Harrosh" <[EMAIL PROTECTED]> wrote:
> I did, I have tried both your suggestions.
>
> What ever you do. any thing after the @ sign gets truncated in the
> import process and will not
> Reach the Import table.
>
> Note that in any way we need a split. asm(.data section) needs a
> none-deco
On December 24, 2003 11:15 am, Boaz Harrosh wrote:
> If we are at it can we get rid of the libFoo.def file all together and
> link directly with Foo.dll.spec file. It looks like a much easier system
> to maintain. I recall a discussion about it but can't remember what was
> said.
But you are dea
I did, I have tried both your suggestions.
What ever you do. any thing after the @ sign gets truncated in the
import process and will not
Reach the Import table.
Note that in any way we need a split. asm(.data section) needs a
none-decorated name and the Import table needs a Decorated one. What
"Boaz Harrosh" <[EMAIL PROTECTED]> wrote:
> I tried Dmitry's solution but it does not work.
You have to put approximately following in the .spec
file to make it work:
foo.dll.spec :
@ stdcall [EMAIL PROTECTED](long long) [EMAIL PROTECTED]
or try do add @8 twice on one/both of the sides. Tha
Kevin Atkinson wrote:
On Wed, 24 Dec 2003, Dmitry Timoshkov wrote:
"Kevin Atkinson" <[EMAIL PROTECTED]> wrote:
Well yes they are decorated. This is the way the VC made them. I guess
they are not Decorated only if you use a .DEF file. If you export them
with __declspec(dllexport) they a
"Kevin Atkinson" <[EMAIL PROTECTED]> wrote:
> How about being able to use the the .lib file like mingw does?
If you will contribute such a patch for winebuild I think it will be
accepted.
--
Dmitry.
On Wed, 24 Dec 2003, Dmitry Timoshkov wrote:
> "Kevin Atkinson" <[EMAIL PROTECTED]> wrote:
>
> > So are you saying that it is not possible to fix winbuild to deal with DLL
> > witch only use __declspec(dllexport) to export their functions?
>
> How would you imagine that fix? A .spec file is gen
"Kevin Atkinson" <[EMAIL PROTECTED]> wrote:
> So are you saying that it is not possible to fix winbuild to deal with DLL
> witch only use __declspec(dllexport) to export their functions?
How would you imagine that fix? A .spec file is generated by you and
not by winebuild. Just place the correct
On Wed, 24 Dec 2003, Dmitry Timoshkov wrote:
> "Kevin Atkinson" <[EMAIL PROTECTED]> wrote:
>
> > > Well yes they are decorated. This is the way the VC made them. I guess
> > > they are not Decorated only if you use a .DEF file. If you export them
> > > with __declspec(dllexport) they are export
"Kevin Atkinson" <[EMAIL PROTECTED]> wrote:
> > Well yes they are decorated. This is the way the VC made them. I guess
> > they are not Decorated only if you use a .DEF file. If you export them
> > with __declspec(dllexport) they are exported decorated.
>
> You are correct. If I use a .def fil
On Wed, 24 Dec 2003, Boaz Harrosh wrote:
> Well yes they are decorated. This is the way the VC made them. I guess
> they are not Decorated only if you use a .DEF file. If you export them
> with __declspec(dllexport) they are exported decorated.
You are correct. If I use a .def file WITH the @
Dmitry Timoshkov wrote:
"Boaz Harrosh" <[EMAIL PROTECTED]> wrote:
} imports = {
{
.
/* foo.dll */
"\001\000fnFooC",
"\002\000fnFooSTD",
0,
change to :
.
/* foo.dll */
"\001\000fnFooC",
"[EMAIL PROTECTED]",
0,
than compilation and runtime
"Boaz Harrosh" <[EMAIL PROTECTED]> wrote:
> } imports = {
> {
>.
> /* foo.dll */
> "\001\000fnFooC",
> "\002\000fnFooSTD",
> 0,
>
>
>
> change to :
>
>
>.
> /* foo.dll */
> "\001\000fnFooC",
> "[EMAIL PROTECTED]",
> 0,
>
>
>
Kevin is right on all accounts. I can reproduce his problems here.
If I go to the foo.spec.c file produced by winebuild for the user
application and manually change, at the big "import" structure, all the
stdcall functions than it works. An example is do.
What was produced by winebuild:
static
On Mon, 22 Dec 2003, Kevin Atkinson wrote:
> On Mon, 22 Dec 2003, Boaz Harrosh wrote:
>
> > I have stdcall working fine here.
> >
> > There is something wrong with your DLL the fact that "pexports" dumped
> > "_" before symbol names is a clue to those functions been exported as
> > cdecl. In
On Mon, 22 Dec 2003, Boaz Harrosh wrote:
> I have stdcall working fine here.
>
> There is something wrong with your DLL the fact that "pexports" dumped
> "_" before symbol names is a clue to those functions been exported as
> cdecl. In stdcall (or PASCAL) no under-scored is perpended. (and yo
I have stdcall working fine here.
There is something wrong with your DLL the fact that "pexports" dumped
"_" before symbol names is a clue to those functions been exported as
cdecl. In stdcall (or PASCAL) no under-scored is perpended. (and you
should see the @number at end of names). check to
Oops. Sorry that I left the subject off.
On Sun, 21 Dec 2003, Kevin Atkinson wrote:
>
> I am having a problem compiling a simple winelib program which relies on
> a dll which uses the stdcall calling convention. I used pexports on the
> dll avisynth_c.dll to created the spec and then edited
26 matches
Mail list logo
