Sync (32): winbuild msvcrt

[Steven Edwards]

--- Jon Griffiths <jon_p_griffiths at yahoo.com> wrote:
> 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?


This is great. I have not had a chance to test this patch as the ReactOS build system differs from
the standard WINE + Mingw and MSYS build. I am currently having a problem with using WINE dlls we
build with ReactOS due to the fact the ReactOS build system is stupid and cannot properly use gcc
or binutils to generate a dll with the .def file winebuild already creates. Using MSYS+Mingw I
have been able to use shlwapi and others from WINE already but dllwrap takes care of some of the
short commings in our autogenerated def's. I will attempt to test tonight with the current Winehq
CVS and Msys.

Thanks
Steven


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com