--- Jon Griffiths <[EMAIL PROTECTED]> 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
