Thanks to a few recent commits by AJ (and several commits over the past months by others), wine now builds on Cygwin. Not everything works, of course, but still a neat exercise in recursion. I've put a screenshot of wine's notepad running on XP on bugzilla (http://bugs.winehq.org/show_bug.cgi?id=21181) see: http://bugs2.winehq.org/attachment.cgi?id=28896 -- -Austin
On 16 June 2010 20:41, Austin English <austinenglish(a)gmail.com> wrote:
Thanks to a few recent commits by AJ (and several commits over the past months by others), wine now builds on Cygwin. Not everything works, of course, but still a neat exercise in recursion.
And thus the fifth seal was broken! (Sixth is someone writing a program loader for Wine on Cygwin. Seventh is Win16 working in the Cygwin build.) I suppose we can't have this in the 1.2 press release, really ;-) - d.
I don't expect Wine itself to ever work on cygwin. Last year I asked AJ about it and there are some special file handle features which are needed. This stuff is supported in SUA but at least in the Vista version this was broken. They MIGHT have fixed it for Win7, so if Wine can work on Windows it would need Win7 but still you would need a version which supports SUA (which are Ultimate and perhaps some business version). Roderick
On Wed, Jun 16, 2010 at 4:04 PM, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote:
I don't expect Wine itself to ever work on cygwin. Last year I asked AJ about it and there are some special file handle features which are needed. This stuff is supported in SUA but at least in the Vista version this was broken. They MIGHT have fixed it for Win7, so if Wine can work on Windows it would need Win7 but still you would need a version which supports SUA (which are Ultimate and perhaps some business version).
If anyone is sufficiently interested in the sendrecv message sockets over file descriptor stuff (I know I am not anymore) there may be an archived email with a regression test I found showing the problem. Even though it was now listed as a supported operation, it kinda sorta worked in limited cases under Server 2003 and hung in others which Wine stress. I don't even recall all of the details at this point but it culminated in me presenting my findings to the SUA team developers and them saying 'that's nice, call our support to file a bug report'. Since I could not actually file the bug report myself online and calling Microsoft support is like a $200 (even if they do issue a refund or not charge your CC if it's a new real bug), I decided to waste no more time with it. -- 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
Is there any real, practical interest in Wine on Windows? I've been making some progress in this direction recently (though I think my approach would be to have a ported, NT-version of wineserver.exe which just uses native functions of the OS instead of emulating them over cygwin, which emulates those features using its own code once again; discussable anyway). WBR, Aleksey Bragin. On Jun 17, 2010, at 12:19 AM, Steven Edwards wrote:
On Wed, Jun 16, 2010 at 4:04 PM, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote:
I don't expect Wine itself to ever work on cygwin. Last year I asked AJ about it and there are some special file handle features which are needed. This stuff is supported in SUA but at least in the Vista version this was broken. They MIGHT have fixed it for Win7, so if Wine can work on Windows it would need Win7 but still you would need a version which supports SUA (which are Ultimate and perhaps some business version).
If anyone is sufficiently interested in the sendrecv message sockets over file descriptor stuff (I know I am not anymore) there may be an archived email with a regression test I found showing the problem. Even though it was now listed as a supported operation, it kinda sorta worked in limited cases under Server 2003 and hung in others which Wine stress. I don't even recall all of the details at this point but it culminated in me presenting my findings to the SUA team developers and them saying 'that's nice, call our support to file a bug report'. Since I could not actually file the bug report myself online and calling Microsoft support is like a $200 (even if they do issue a refund or not charge your CC if it's a new real bug), I decided to waste no more time with it.
-- 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 Sun, Jun 27, 2010 at 3:59 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote:
Is there any real, practical interest in Wine on Windows? I've been making some progress in this direction recently (though I think my approach would be to have a ported, NT-version of wineserver.exe which just uses native functions of the OS instead of emulating them over cygwin, which emulates those features using its own code once again; discussable anyway).
WBR, Aleksey Bragin.
DirectX 10 games on Windows XP :P Seriously though, being able to run programs that ran on Windows 9x but not NT based Windows would be a pretty good use for Wine. Granted, most of those programs are games, but meh. And then there's being able to run 16-bit Windows apps on 64-bit Windows! :P
2010/6/27 Conan Kudo (ニール・ゴンパ) <ngompa13(a)gmail.com>:
DirectX 10 games on Windows XP :P Seriously though, being able to run programs that ran on Windows 9x but not NT based Windows would be a pretty good use for Wine. Granted, most of those programs are games, but meh. And then there's being able to run 16-bit Windows apps on 64-bit Windows! :P
16-bit compilation is currently disabled in Cygwin. There's a list of ideas on http://wiki.winehq.org/WineOnWindows - * As much as possible should compile (and even work). * Check how well the .EXE and .DLL made by Wine on Cygwin work in Windows. If a MinGW-compiled DLL works in Windows, a Cygwin-compiled DLL should. * ./configure fails to pick up the presence of a lot of packages it should. * Win16 is disabled in Cygwin (severe compilation problems). Enabling that and getting it to compile would be interesting. That's as well as writing a program loader that works ;-) It is important to stress that this is *largely pointless* and mostly driven by *hack value*. - d.
On Sun, Jun 27, 2010 at 4:59 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote:
Is there any real, practical interest in Wine on Windows?
For doing a full port, other than the argument of climbing the mountain because it's there, I doubt it.
I've been making some progress in this direction recently (though I think my approach would be to have a ported, NT-version of wineserver.exe which just uses native functions of the OS instead of emulating them over cygwin, which emulates those features using its own code once again; discussable anyway).
I think as we have discussed before, taking arwinss, or at least the core parts of it and attempting to make an independent subsystem that runs under Windows has value. I believe there is a worthwhile product based upon your work with arwinss using Wine user32/gdi32/x11drv with the rest of the Windows stack to support remotely displaying Win32 applications over X11 to OS X, Solaris and Linux clients. -- 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 (6)
-
Aleksey Bragin -
Austin English -
Conan Kudo (ニール・ゴンパ) -
David Gerard -
Roderick Colenbrander -
Steven Edwards