Removing Windows and Solaris from the Downloads page
It appears that the links for the Windows and Solaris versions on the winehq downloads page are very, very old. Since they're no longer maintained, we should just remove them, yes? Thanks, Scott Ritchie
It appears that the links for the Windows and Solaris versions on the winehq downloads page are very, very old. Since they're no longer maintained, we should just remove them, yes?
Thanks, Scott Ritchie
They should get updated. In case of Solaris there are some bugs which prevent it from running I think. In case of Windows someone needs to update the package. It is very useful to use some of the wine dlls (wined3d for instance) or tests on Windows. Roderick -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail
Hi, Roderick Colenbrander schreef:
They should get updated. In case of Solaris there are some bugs which prevent it from running I think. In case of Windows someone needs to update the package. It is very useful to use some of the wine dlls (wined3d for instance) or tests on Windows.
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. Regards, Maarten.
On Saturday 17 November 2007 12:04:36 Maarten Lankhorst wrote:
Roderick Colenbrander schreef:
They should get updated. In case of Solaris there are some bugs which prevent it from running I think. In case of Windows someone needs to update the package. It is very useful to use some of the wine dlls (wined3d for instance) or tests on Windows.
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.
That sounds promising. I should be able to tweak the winetest.exe build infrastructure so it also build DLLs and executables without too much trouble. Having a target that skips attempting to build DLLs that will never work would help. Cheers, Paul.
On Sunday 18 November 2007 12:42:40 Paul Millar wrote:
That sounds promising. I should be able to tweak the winetest.exe build infrastructure so it also build DLLs and executables without too much trouble.
OK, this now seems stable. The DLLs and executables are built and packaged whenever winetest is rebuilt. They're available both from the old location: http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/ or from a new one: http://quisquiliae.physics.gla.ac.uk/cross/results/ As with winetest.exe, they're only updated if the new binaries are different. The ZIP files are signed and there's are sym-links that always point to the most recent version. For example: http://quisquiliae.physics.gla.ac.uk/cross/results/wine-exes-latest.zip Cheers, Paul.
On Nov 17, 2007 6:04 AM, Maarten Lankhorst <maarten(a)codeweavers.com> 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
Hi Steven,
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.
The problem with using winsock rather than UNIX sockets is in the I/O between a client process and the wineserver. The extra overhead it imposes is really unavoidable, AFAICT. We're doing a context switch to a separate process that a UNIX socket call (or a winsock call on Windows) does not require. While we could speed up such I/O in certain cases with hacks like the shared memory wineserver, or with a wineserver kernel module, doing so is very error prone, and we'd lose a lot of time chasing down errors that's better spent improving our implementation of Windows dlls. It may not be the "right" thing to do in a purely abstract sense, but it's clearly the right thing given our resources and our priorities. If wineserver performance is ever the thing preventing a large number of apps from working correctly, we might invest more time in it. Switching wininet to winsock might make sense then, but not before.
Mingw/MSVC and friends will always be second class citzen to Wine on Unix.
It's true, for several reasons: 1. We don't use MSVC to develop Wine (nor should we) so we don't catch errors there as quickly. 2. MinGW's headers aren't in synch with ours, so building with it is for the very patient. I'm happy someone does it, but we can't all do it without losing a lot of time. 3. We don't use MinGW in compile Wine, nor, again, should we. --Juan
Hi, On Nov 18, 2007 8:03 PM, Juan Lang <juan.lang(a)gmail.com> wrote:
The problem with using winsock rather than UNIX sockets is in the I/O between a client process and the wineserver. The extra overhead it imposes is really unavoidable, AFAICT. We're doing a context switch to a separate process that a UNIX socket call (or a winsock call on Windows) does not require. While we could speed up such I/O in certain cases with hacks like the shared memory wineserver, or with a wineserver kernel module, doing so is very error prone, and we'd lose a lot of time chasing down errors that's better spent improving our implementation of Windows dlls. It may not be the "right" thing to do in a purely abstract sense, but it's clearly the right thing given our resources and our priorities. If wineserver performance is ever the thing preventing a large number of apps from working correctly, we might invest more time in it. Switching wininet to winsock might make sense then, but not before.
I understand that, I'm just not being very pragmatic today.
Mingw/MSVC and friends will always be second class citzen to Wine on Unix.
It's true, for several reasons: 1. We don't use MSVC to develop Wine (nor should we) so we don't catch errors there as quickly. 2. MinGW's headers aren't in synch with ours, so building with it is for the very patient. I'm happy someone does it, but we can't all do it without losing a lot of time. 3. We don't use MinGW in compile Wine, nor, again, should we.
The headers are not an issue because we use the Wine headers and import libraries for the dlls. The only place there is a problem is with wine/programs and the regression tests. They use the native import libraries. I don't really understand Alexandre's reasoning on this as myself and Dmitry have both sent patches in to correct this issue and his answer has always been that we should fix mingw w32api. Wine always tends to break when cross-compiling because of this. If we always defaulted to using the Wine headers and Import libs there never would be a problem in that regards. /rant off. I understand the reasoning behind it breaking and just needed to vent about it because sometimes going back over old problems, presents new solutions. Thanks -- 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
On Monday 19 November 2007 03:55:20 Steven Edwards wrote:
The headers are not an issue because we use the Wine headers and import libraries for the dlls. The only place there is a problem is with wine/programs and the regression tests. They use the native import libraries. I don't really understand Alexandre's reasoning on this as myself and Dmitry have both sent patches in to correct this issue and his answer has always been that we should fix mingw w32api. Wine always tends to break when cross-compiling because of this. If we always defaulted to using the Wine headers and Import libs there never would be a problem in that regards.
I recall Alexandre saying that he wants the exposure to alternative headers and import libraries because it brings up bugs in Wine. He also suggested that the wininet/winsock issue could be solved by making wininet build against either Windows sockets or Unix sockets. Here's a historical thread on this issue: http://www.kernel-traffic.org/wine/wn20040416_219.html#5 -Hans
On Nov 19, 2007 5:40 AM, Hans Leidekker <hans(a)it.vu.nl> wrote:
I recall Alexandre saying that he wants the exposure to alternative headers and import libraries because it brings up bugs in Wine. He also suggested that the wininet/winsock issue could be solved by making wininet build against either Windows sockets or Unix sockets.
I did this so it should still work. I was just pointing to it as an example of how/why things break on the mingw build. -- 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
participants (7)
-
Hans Leidekker -
Juan Lang -
Maarten Lankhorst -
Paul Millar -
Roderick Colenbrander -
Scott Ritchie -
Steven Edwards