Drop-in replacement of windows dll's?

[Tom Spear]

I just remembered reading somewhere (wiki, perhaps?) that the ultimate
goal of wine (aside from documenting the windows api, etc) was to
provide open-source drop-in replacements for windows' core dll's.  If
that is the case, do we have a framework setup for building the wine
dlls as windows .dll files, so that we could test the actual status of
this?

I think it would be interesting to see how much of windows will run
with wine's dlls in their current state.  Obviously it would be bad to
test this with something like user32.dll, etc, but something like
riched32 and maybe some of the common controls dlls should be ok to
test with?

[Steven Edwards]

On 5/8/07, Tom Spear  wrote:
> I just remembered reading somewhere (wiki, perhaps?) that the ultimate
> goal of wine (aside from documenting the windows api, etc) was to
> provide open-source drop-in replacements for windows' core dll's.  If
> that is the case, do we have a framework setup for building the wine
> dlls as windows .dll files, so that we could test the actual status of
> this?

Google around for posts by me and other about build wine with mingw.
I've been meaning to document it for years but never gotten around to
it. You either need to build on windows with a mingw or have two trees
on Linux, one with the host tools and the other configured for the
cross-compiler.

Thanks
Steven

[Tom Spear]

On 5/8/07, Steven Edwards  wrote:
> On 5/8/07, Tom Spear  wrote:
> > I just remembered reading somewhere (wiki, perhaps?) that the ultimate
> > goal of wine (aside from documenting the windows api, etc) was to
> > provide open-source drop-in replacements for windows' core dll's.  If
> > that is the case, do we have a framework setup for building the wine
> > dlls as windows .dll files, so that we could test the actual status of
> > this?
>
> Google around for posts by me and other about build wine with mingw.
> I've been meaning to document it for years but never gotten around to
> it. You either need to build on windows with a mingw or have two trees
> on Linux, one with the host tools and the other configured for the
> cross-compiler.

That would be the framework.  I appreciate the response.  Is this
something that either now or in the future will be officially
supported by wine, or even a true goal of wine, or is it more of a
side project for you and some others?

[Stefan Dösinger]

> I think it would be interesting to see how much of windows will run
> with wine's dlls in their current state.  Obviously it would be bad to
> test this with something like user32.dll, etc, but something like
> riched32 and maybe some of the common controls dlls should be ok to
> test with?

There is a windows build available for wine(or used to be) where you can get 
PE builds of Wine's DLLs. I think Wine's mshtml.dll allows you to run 
Internet Explorer 6 using the gecko engine on Windows, but I never tried 
this.

[Rolf Kalbermatter]

Tom Spear [mailto:[e-mail]] wrote:
> I just remembered reading somewhere (wiki, perhaps?) that the ultimate goal

of wine
> (aside from documenting the windows api, etc) was to provide open-source

drop-in
> replacements for windows' core dll's.  If that is the case, do we have a

framework
> setup for building the wine dlls as windows .dll files, so that we could

test the
> actual status of this?
>
> I think it would be interesting to see how much of windows will run with

wine's dlls
> in their current state.  Obviously it would be bad to test this with

something like
> user32.dll, etc, but something like riched32 and maybe some of the common

controls
> dlls should be ok to test with?

There is a winapi/msvcmaker perl script in Wine which can create the Visual
C 6.0 make
files for most (probably not all anymore since the directory structure
changed a lot
in the last years) DLLs and support libraries in Wine.

Patrik Stridvall put a lot of effort into this and for most non core DLLs it
actually
did work at some point fairly well. You just had to make sure to either use
Perl tools
under Windows or configure the Unix directory that contained Wine to be
shared to the
Windows box with DOS end of line translation since the Visual C 6.0 IDE is
very picky
about those .dsp and .dsw files and simply crashes in a fatal way (leaving a
zombie
process you have to kill before you can restart it again) if those files do
not look
exactly as it expects them.

At some point I tried to adapt those tools to some changes in the Wine
directory
structure but more would have been needed including certain changes to
include file
order and such to make it work well. In general since there are not many
people using
that approach it tends to be an uphill battle to keep it working with Wine
internal
changes and new PSDK releases and I have not followed that anymore for maybe
2 years.

I believe that the use of MingW will be probably more successful since it is
both used
to create the crosstests and for Winlib applications/libraries but I haven't
done
anything with Winelib and only tried once to build the crosstests.

Rolf Kalbermatter