spec file syntax and automated generation

[Martin Troester]

Hi,

apart from my desperate linking problems I mentioned in the wine-users
list, I have some questions regarding the spec file for defining and
wrapping exported symbols:

1. The winebuild manpage only mentions ptr, str, wstr, long and double
as valid Win32 function argument size information - is the amount and
kind of symbols really important, or is it just the amount of used stack
space?

1a: Assuming a function taking two boolean parameters (or anything
logically smaller than 32bit) like this:
> void func(boolean a, boolean b)

Do I specify it in the spec file as
> @ stdcall func(long,long)

or as
> @ stdcall func(long)

? I am not too familiar with assembler, but I would assume the first is
right, since two arguments are pushed on the stack, each using 32bit.

1b: What about structs? Do I have to give the size as multiples of
32bit? Assuming the following example:
> typedef struct {
>    long var1;
>    double var2;
>    bool var3;
> } test_struct;

Assuming the function to be exported looks like
> int test_func ( test_struct test );

Is the corresponding spec-file entry for 64bit stack space for function
parameters
> @ stdcall test_func(double,double)

due to the fact that I just care about the absolute amount of
stack-space used for the struct, or do I have to regard the size of
each single member, thus pushing
> @ stdcall test_func(long,double,long)

on the stack?

1c: What about classes in C++-exported functions, as well as mangled
names? I suppose I have to use the mangled name in the spec-file, but I
am not sure about that. How do I calculate stack space for classes, or
are they always put on the stack as references or pointers? If yes, I
assume both take 32bit.

2. One question regarding the spec-file: The following questions arise
since I wrote the .spec file myself. Is there any automation available
in this field? Seems to be quite some work for several DLLs, and has a
high potential to cause errors when done manually... What I did was
extracting output from dumpbin for the original Win32 dll, replacing all
decorated exported function names with stdcall, while using cdecl for
the undecorated ones. Is this assumption right?

Thanks in advance for your answers and help.

Cheers,
Martin--