Sync (32): winbuild msvcrt

[Jon Griffiths]

Hi,

This patch addresses most of the existing issues building Wines dlls
as native win32 dlls using msvc, namely:

- We need to export forwards from the .def file.

- We need to export any implemented ordinal functions and mark them
as NONAME. 

- Functions exported by name only should not be given ordinal numbers
in the .def output, so that link.exe can fill up empy ordinal slots
and create a valid export table. Not doing this leads to an incorrect
export table without any warnings or errors during the build.

- This means that parsing the .def files has to treat ordinal numbers
as optional for named functions (just as link.exe/lib.exe do). This
concurs with the MSDN documentation for the .def file syntax.

- We need the stub functions to be present in the final dll file, or
our ordinal functions cannot be accessed. This is because link.exe
requires that all ordinals be present in order to generate a correct
ordinal export table.
This in turn requires that the .spec.c files compile correctly under
msvc, in order to get the stub functions included in the link.
However, we obviously don't need the pe header or export tables that
winebuild generates, since link.exe (and any other PE linker, for
that matter) does this work for us.

- Fixing the .spec.c file requires that we use RaiseException from
kernel32 instead of RtlRaiseException from ntdll, since no import
library is provided for ntdll by default. This can be fixed later but
requires large changes to the build environment to get dependencies
correct (we should generate our .def files from our .spec files when
building with msvc, just as we do under unix; we would then use our
own ntdll.def to link to ntdll functions).

- Several symbols are expected to be exported as private and by name
only, or they generate warnings when creating the .lib and .exp files
for the dll. This requires identifying said symbols, and correctly
generating and parsing the PRIVATE flag in .def files.

- Debug channels should be registered, this is accomplished using the
CRT static constructor data segment. This allows linking to proceed
by finding the debug channels, and (with upcoming patches) will allow
debug msgs to be printed.

- The added #ifdefs required for msvc made the output look more crufy
than it was, so I reduced the number of these with some macros at the
start of the generated output files.

Using this patch I can build a correctly functioning native
shlwapi.dll which will load and run under Windows, and as a native
dll under Wine. This includes being able to GetProcAddress() the
ordinal functions and call them.  It should now be possible to create
distributable native trace dlls that can be installed under windows,
giving us non-instrusive monitoring of the internals of calls between
applications and native dlls.

Two remaining issues are what to do with register functions and 16
bit dlls.

Please comment if there are any issues with respect to cygwin that
occur after applying this patch. I imagine the ReactOS folks might be
interested as well; does anyone know how they build their dlls at
present?

License: X11

Cheers,
Jon

ChangeLog:

  Jon Griffiths <jon_p_griffiths at yahoo.com>

  +tools/winebuild/build.h tools/winebuild/import.c
   tools/winebuild/parser.ctools/winebuild/spec16.c
   tools/winebuild/spec32.c 
   Export '@'-functions and forwards
   Support PRIVATE and optional ordinal numbers in .def files
   Allow generated files to build correct dlls under msvc
   Clean up the generated output

=====
"Don't wait for the seas to part, or messiahs to come;
 Don't you sit around and waste this chance..." - Live

jon_p_griffiths at yahoo.com

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winebuild_1.diff
Type: text/x-diff
Size: 26158 bytes
Desc: winebuild_1.diff
Url : http://www.winehq.org/pipermail/wine-patches/attachments/20030717/268448f7/winebuild_1.bin