Seperating winelibs from main wine ( was "Winelib support" )
Mmmm.. Doesn't sound like a basic windows app. I do not know any windows program that uses putty and there are plenty linux/unix alternatives. but it might be usefull to some people. ( i don't know anyone ) perhaps it is time to seperate all the winelib progs from the main wine package and create a winelib package. just how knows what people in the future might write. paint / control panel / media player / calculator / etc... comments please Mark Hannessen On Thursday 21 November 2002 10:50, wine-devel-request(a)winehq.com wrote:
Hi folks,
I'm one of the Wine (http://www.winehq.org) developers, and I just managed to build Putty under Winelib. That is, Putty now runs as a native Linux application.
The interesting part is that I've managed to do so with virtually no changes to the source code, just a few changes to the makefile.cyg file.
Now, my question to you: are you interested in supporting Putty under Wine, as a Winelib app? If so, I can clean up my changes, and send you a patch for the build system to incorporate in your tree.
I think what Dimi was talking about was sending the PuTTY team patches so they could offer a Linux version on their download site, rather than actually supplying it with Wine. A couple of questions - if a program uses Winelib, is it all statically linked or do you still need a wine installation for it to work. Also, if they ship a Winelib version of the app, do they still use the Wine button on their site or is that just for apps that work under the PE loader? On Thu, 2002-11-21 at 12:14, Mark Hannessen wrote:
Mmmm..
Doesn't sound like a basic windows app. I do not know any windows program that uses putty and there are plenty linux/unix alternatives.
but it might be usefull to some people. ( i don't know anyone )
perhaps it is time to seperate all the winelib progs from the main wine package and create a winelib package.
just how knows what people in the future might write. paint / control panel / media player / calculator / etc...
comments please
Mark Hannessen
On Thursday 21 November 2002 10:50, wine-devel-request(a)winehq.com wrote:
Hi folks,
I'm one of the Wine (http://www.winehq.org) developers, and I just managed to build Putty under Winelib. That is, Putty now runs as a native Linux application.
The interesting part is that I've managed to do so with virtually no changes to the source code, just a few changes to the makefile.cyg file.
Now, my question to you: are you interested in supporting Putty under Wine, as a Winelib app? If so, I can clean up my changes, and send you a patch for the build system to incorporate in your tree.
-- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ
On Thursday 21 November 2002 12:28, you wrote:
I think what Dimi was talking about was sending the PuTTY team patches so they could offer a Linux version on their download site, rather than actually supplying it with Wine. than it might still be a usefull thing to keep all the winelibs in "one place", ( <-- read "package" ) so that everyone knows where to find them.
we might also dedicate a part of the wine site to winelibs not shipped with wine.
A couple of questions - if a program uses Winelib, is it all statically linked or do you still need a wine installation for it to work. winelib apps need wine dll functions and are not static compiled. so wine is needed to run wine apps
Mark Hannessen
Mark Hannessen wrote:
A couple of questions - if a program uses Winelib, is it all statically linked or do you still need a wine installation for it to work.
winelib apps need wine dll functions and are not static compiled. so wine is needed to run wine apps
I started writing this mail, and during writing realized that I'm not sure what I was about to suggest made any sense. This is a question to the forum, then. Does it make sense to ask packagers to package Winelib seperately from wine (obviously, wine needs winelib to run, but that is a piece of cake for any decent packaging system I know, with the sole exception of the various windows installers, hint hint)? Does such a request have any meaning at all? I realize that you COULD say that the sourcedir/dlls directory's output should go into winelib, the header into winelib-devel, and the wine executable, and sourcedir/programs output into the wine package, but I'm not at all sure that would leave you with a usable winelib package. Comments, anyone? Shachar
A couple of questions - if a program uses Winelib, is it all statically linked or do you still need a wine installation for it to work.
winelib apps need wine dll functions and are not static compiled. so wine is needed to run wine apps
I started writing this mail, and during writing realized that I'm not sure what I was about to suggest made any sense. This is a question to the forum, then.
The problem we have with people making and shipping winelib apps at this point is that with every release of WINE untill 1.x we will have breakages. If you want to help people that produce OSS windows applications support WINElib then for now, at least untill 1.0 we can only support building winelib apps and not binary winelib applications. Thanks Steven __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus � Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Steven Edwards wrote:
The problem we have with people making and shipping winelib apps at this point is that with every release of WINE untill 1.x we will have breakages.
If winelib contains what I think it contains, I don't see why that should happen. Are you sure about that point? After all, a winelib app is a linux/unix app that is dynamically linked (by name, I'm sure) with winelib dlls that are, today, part of wine. Both the functions linked and their parameters are defined by MS and MSDN, and will not change, ever. Bugs may be solved, but as the application was originally designed to work with MS's implemnetation, and as a bug is defined to be "incompatible with MS's implementation", I don't think it possible for a winelib app to rely on a wine bug for functionality. I therefor don't see how a breakage can happen unless we have regression in wine. As such, breakegaes should be very rare, not often. 1.0 or not. Am I missing something here?
If you want to help people that produce OSS windows applications support WINElib then for now, at least untill 1.0 we can only support building winelib apps and not binary winelib applications.
That point is 100% understood assuming I accept your previous statement (which I don't). Reply only if you think this statement holds true even if your previous one doesn't.
Thanks Steven
Am I missing something here?
Not sure. I was under the impression that Winelib apps used wineserver, the protocol for which won't be frozen until 1.0 - this might be what he meant. On Thu, 2002-11-21 at 14:51, Shachar Shemesh wrote:
Steven Edwards wrote:
The problem we have with people making and shipping winelib apps at this point is that with every release of WINE untill 1.x we will have breakages.
If winelib contains what I think it contains, I don't see why that should happen. Are you sure about that point?
After all, a winelib app is a linux/unix app that is dynamically linked (by name, I'm sure) with winelib dlls that are, today, part of wine. Both the functions linked and their parameters are defined by MS and MSDN, and will not change, ever. Bugs may be solved, but as the application was originally designed to work with MS's implemnetation, and as a bug is defined to be "incompatible with MS's implementation", I don't think it possible for a winelib app to rely on a wine bug for functionality. I therefor don't see how a breakage can happen unless we have regression in wine. As such, breakegaes should be very rare, not often. 1.0 or not.
Am I missing something here?
If you want to help people that produce OSS windows applications support WINElib then for now, at least untill 1.0 we can only support building winelib apps and not binary winelib applications.
That point is 100% understood assuming I accept your previous statement (which I don't). Reply only if you think this statement holds true even if your previous one doesn't.
Thanks Steven
-- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ
Mike Hearn wrote:
Am I missing something here?
Not sure. I was under the impression that Winelib apps used wineserver, the protocol for which won't be frozen until 1.0 - this might be what he meant.
I will have to confess utter ignorance here. However, this does not seem a wise choice to me. Performing the communications with the wineserver from the app itself (rather than from dlls the app is dynamically linked with) seem to me like asking for trouble, if only because it deviates significantly from the way Windows apps are built. Can anyone who actually knows the answer (unlike me, that is `-) please comment here? Shachar
On November 21, 2002 11:25 am, Shachar Shemesh wrote:
Performing the communications with the wineserver from the app itself (rather than from dlls the app is dynamically linked with) seem to me like asking for trouble, if only because it deviates significantly from the way Windows apps are built.
Winelib apps have no direct dealings with the wineserver. However, our DLL interface is not that stable yet, that's why we're pushing to finish the DLL separation (Phase 1). Check out the 0.9 TODO! :) -- Dimi.
Winelib apps have no direct dealings with the wineserver. However, our DLL interface is not that stable yet, that's why we're pushing to finish the DLL separation (Phase 1). Check out the 0.9 TODO! :)
This was what I was talking about. It MAY be possible for current winelib binarys to work with later WINE versions but it shouldnt be supported untill a 1.x branch is taged.
On November 21, 2002 01:42 pm, Steven Edwards wrote:
Winelib apps have no direct dealings with the wineserver. However, our DLL interface is not that stable yet, that's why we're pushing to finish the DLL separation (Phase 1). Check out the 0.9 TODO! :)
This was what I was talking about. It MAY be possible for current winelib binarys to work with later WINE versions but it shouldnt be supported untill a 1.x branch is taged.
Perhaps this is a naive suggestion, but why don't you simply put versioning (and checking) in the wineserver protocol? IIUC, the issue is about handling (and failing gracefully if necessary) the situation where winelib applications talk to incompatible versions of wineserver, so this would seem to be the obvious "fix"? Cheers, Geoff -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/
Geoff Thorpe a écrit:
On November 21, 2002 01:42 pm, Steven Edwards wrote:
Winelib apps have no direct dealings with the wineserver. However, our DLL interface is not that stable yet, that's why we're pushing to finish the DLL separation (Phase 1). Check out the 0.9 TODO! :)
This was what I was talking about. It MAY be possible for current winelib binarys to work with later WINE versions but it shouldnt be supported untill a 1.x branch is taged.
Perhaps this is a naive suggestion, but why don't you simply put versioning (and checking) in the wineserver protocol? IIUC, the issue is about handling (and failing gracefully if necessary) the situation where winelib applications talk to incompatible versions of wineserver, so this would seem to be the obvious "fix"?
There already is a versioning in the wineserver protocol; I believe the present version is 68 or 69. The problem lies in using an app compiled for another version than the installed wine libraries/server, and/or surviving upgrades in the installed wine libraries/server without recompiling the winelib app. Vincent
On November 21, 2002 03:27 pm, Vincent Béron wrote:
There already is a versioning in the wineserver protocol; I believe the present version is 68 or 69. The problem lies in using an app compiled for another version than the installed wine libraries/server, and/or surviving upgrades in the installed wine libraries/server without recompiling the winelib app.
Ah, ok - yes well that's another problem altogether, but at least it'll be a *sane* problem at the packaging/sys-admin level, even if potentially frustrating. But if anyone cares enough about releasing a linux application in winelib form and protecting against lib/wineserver version hassles, they should probably also be releasing a bundled local installation of anything important from wine? Though I guess that assumes it's possible to configure/bundle the wine stuff (server, configs, etc) so that it works "locally" to an application installation rather than using global paths and what-not ... Cheers, Geoff -- Geoff Thorpe geoff(a)geoffthorpe.net http://www.geoffthorpe.net/
On November 21, 2002 06:28 am, Mike Hearn wrote:
I think what Dimi was talking about was sending the PuTTY team patches so they could offer a Linux version on their download site, rather than actually supplying it with Wine.
Indeed. Sorry, my mistake, I was not clear. I realized that my email might be misinterpreted easily this way, when I received it back from wine-devel. Us supplying all winelib apps is not scalable. We have to get them to support Wine as another Windows version in their build system. And we can keep track of who does that, and grab the app from time to time, compile it, and make sure everything works as expected. -- Dimi.
participants (7)
-
Dimitrie O. Paun -
Geoff Thorpe -
Mark Hannessen -
Mike Hearn -
Shachar Shemesh -
Steven Edwards -
Vincent Béron