On Nov 17, 2007 6:04 AM, Maarten Lankhorst <[EMAIL PROTECTED]> wrote: > The question is what dlls should we include? Something like the d3d > dll's would be useful, and a lot of other dll's (mshtml, shdocvw, etc) > probably too. Unfortunately wine won't build on mingw properly,if you > try a 'make' in mingw, it will bomb out on building in dll's. If someone > wants to maintain windows dll's, the makefiles should be adjusted so > that it will build properly, and skip the dll's wine can't emulate in > windows. Such as ntdll, kernel32, advapi, to name a few, probably all > dll's with wineserver calls and perhaps a few more.
And all of the dlls that make unix functional calls that don't exist on windows. I seem to recall us having a discussion about a certain WinMM patch... The problem is not in the makefiles, a lot of the problem is that we are not clear on which dlls would be of use for testing in windows. I had to go through hoops to get wininet buildable on Windows because it uses unix sockets on Wine rather than winsock. There was quite a performance issue when running under Wine with winsock that did not show up when using Unix sockets and I felt, and still do that hacking around the problem rather than finding where the bottleneck was, is not the right answer. That was my point in the winmm patch we discussed also, if there is a bottleneck in wineserver or somewhere, hacking around window portability for performance gain seems to just be hiding the problems. I don't have a solution that will always work mind you, I am just venting. Mingw/MSVC and friends will always be second class citzen to Wine on Unix. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo