I used to hate the term ISV (Independent Software Vendor) since it sounded so acronymy compared to 'developer', but it's very commonly used in the industry to refer to outfits which are trying to write and sell off-the-shelf software -- and as monkey-boy said, Microsoft is where it is partly because it worked hard to attract and support those guys.
So I've been thinking about how to attract more Windows ISVs to test, support, and promote their apps on Linux with Wine.
Part of the problem is a lack of high-level documentation specifically aimed at the ISV. Another is ISVs getting lost in the shuffle on wine-users or wine-devel.
I've made a start at the documentation (http://kegel.com/wine/isv), and hope to move that to winehq at some point. Now I'd like to create a discussion forum for ISVs where they will feel more comfortable; the level of discussion would be halfway between that in wine-users and wine-devel, but aimed more at Windows developers than people who are familiar with Linux. How about we create a new mailing list, wine-isv, aimed squarely at ISVs and the Wine community members who want to help them?
Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
On Tue, 2005-12-13 at 22:33 -0800, Dan Kegel wrote:
I used to hate the term ISV (Independent Software Vendor) since it sounded so acronymy compared to 'developer', but it's very commonly used in the industry to refer to outfits which are trying to write and sell off-the-shelf software -- and as monkey-boy said, Microsoft is where it is partly because it worked hard to attract and support those guys.
So I've been thinking about how to attract more Windows ISVs to test, support, and promote their apps on Linux with Wine.
DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS!
I support this idea.
-Scott Ritchie
Scott Ritchie schrieb:
On Tue, 2005-12-13 at 22:33 -0800, Dan Kegel wrote:
I used to hate the term ISV (Independent Software Vendor) since it sounded so acronymy compared to 'developer', but it's very commonly used in the industry to refer to outfits which are trying to write and sell off-the-shelf software -- and as monkey-boy said, Microsoft is where it is partly because it worked hard to attract and support those guys.
So I've been thinking about how to attract more Windows ISVs to test, support, and promote their apps on Linux with Wine.
DEVELOPERS DEVELOPERS DEVELOPERS DEVELOPERS!
IMHO all this stuff goes a bit too much into the wrong direction.
I really fear that this will end up with vendors loudly advertising linux support and proudly putting linux stickers on their products where everything you find inside are just the same windows .exe files and a readme stating that these will work fine with wine. Which at least is not what I would like to see.
The main thing the _developers_ should be pointed to(if they care about their product on other platforms then windows) are some decent docs about platform-independent programming :p
Maybe it's just me but when reading all this I got the feeling that writing windows applications(which work with wine) is just *the* way to go. Why the hell are we running linux then?
Not that I generally disagree with what you wrote. Actually it's mostly totally fine.And it's definitly a good thing when vendors care about their product running with wine or companies migrating to linux trying to get their highly-specialized-app to work with wine. But imho it _shouldn't_ be the long term solution.
Peter
I support this idea.
-Scott Ritchie
On 12/15/05, Peter Beutner p.beutner@gmx.net wrote:
it's definitly a good thing when vendors care about their product running with wine or companies migrating to linux trying to get their highly-specialized-app to work with wine. But imho it _shouldn't_ be the long term solution.
We're in violent agreement. - Dan
-- Wine for Windows ISVs: http://kegel.com/wine/isv
Peter Beutner wrote:
IMHO all this stuff goes a bit too much into the wrong direction.
I really fear that this will end up with vendors loudly advertising linux support and proudly putting linux stickers on their products where everything you find inside are just the same windows .exe files and a readme stating that these will work fine with wine. Which at least is not what I would like to see.
Why? Wine is effectively just a different toolkit, like QT or GTK (albeit much larger) that give applications a Windows, KDE and Gnome look respectively. Take Notepad for example - with some slight modifications you could even modify the File Open dialog to only show the Unix namespace. Is there any reason that this application can't be a fully fledged part of the desktop?
The main thing the _developers_ should be pointed to(if they care about their product on other platforms then windows) are some decent docs about platform-independent programming :p
Sure. While you're at it give them some docs about globalization practices and efficient CPU usage. These are all nice to have things, but you have to face it that if you're a developer at a software company with a deadline then these are the first things to be ignored. You also have to bear in mind that it is incredibly difficult to do platform idependent GUI programming, whilst still maintaining the Windows look.
Maybe it's just me but when reading all this I got the feeling that writing windows applications(which work with wine) is just *the* way to go.
It is the cheapest way for companies and it gives good results for the users. What's wrong with that?
Not that I generally disagree with what you wrote. Actually it's mostly totally fine.And it's definitly a good thing when vendors care about their product running with wine or companies migrating to linux trying to get their highly-specialized-app to work with wine. But imho it _shouldn't_ be the long term solution.
Wine is a very good way of testing the waters with a Linux market. If a significant part of the market share starts coming from Linux or other Unix operating systems then the company can start offering winelib extensions that integrate better with the environment in which they are running.
However, you have to face facts that Linux is a hostile environment for commercial companies - constantly changing APIs, lack of regression testing by distributions, lots of variations meaning lots of testing needed and different standards on different distributions. Wine is a layer on top of that, which provides a degree of stability.
Robert Shearman schrieb:
Peter Beutner wrote:
IMHO all this stuff goes a bit too much into the wrong direction.
I really fear that this will end up with vendors loudly advertising linux support and proudly putting linux stickers on their products where everything you find inside are just the same windows .exe files and a readme stating that these will work fine with wine. Which at least is not what I would like to see.
Why? Wine is effectively just a different toolkit, like QT or GTK (albeit much larger) that give applications a Windows, KDE and Gnome look respectively. Take Notepad for example - with some slight modifications you could even modify the File Open dialog to only show the Unix namespace. Is there any reason that this application can't be a fully fledged part of the desktop?
Wine is _not_ just a different toolkit. Just look at all the "nasty" stuff wine has to do to emulate the windows process environment. This is not exactly what I would prefer as an ideal environment when I had to develop an application.
The main thing the _developers_ should be pointed to(if they care about their product on other platforms then windows) are some decent docs about platform-independent programming :p
Sure. While you're at it give them some docs about globalization practices and efficient CPU usage. These are all nice to have things, but you have to face it that if you're a developer at a software company with a deadline then these are the first things to be ignored. You also have to bear in mind that it is incredibly difficult to do platform idependent GUI programming, whilst still maintaining the Windows look.
Nobody said it's easy or that it will happen over night. But it can/should be the long term goal. Besides gtk+/qt are imho quite mature to use as cross-plattform gui toolkits.
Maybe it's just me but when reading all this I got the feeling that writing windows applications(which work with wine) is just *the* way to go.
It is the cheapest way for companies and it gives good results for the users. What's wrong with that?
See above. Wine does a lot of "tricks" to emulate windows behaviour. And the more you use some complex window api the more is the chance that wine just can't implement it the way it works in windows but has to use all sorts of workarounds to get it to work under linux. Sure all that probably won't interest any manager in a company and probably won't stand against the "money" argument. But as a developer I would always vote for doing a little bit of extra thinking by going the platform independent way.
Not that I generally disagree with what you wrote. Actually it's mostly totally fine.And it's definitly a good thing when vendors care about their product running with wine or companies migrating to linux trying to get their highly-specialized-app to work with wine. But imho it _shouldn't_ be the long term solution.
Wine is a very good way of testing the waters with a Linux market. If a significant part of the market share starts coming from Linux or other Unix operating systems then the company can start offering winelib extensions that integrate better with the environment in which they are running.
I doubt that this will happen. If the windows version works with wine the company will more likely continue to work on that. See your money argument.
However, you have to face facts that Linux is a hostile environment for commercial companies - constantly changing APIs, lack of regression testing by distributions, lots of variations meaning lots of testing needed and different standards on different distributions. Wine is a layer on top of that, which provides a degree of stability.
As long as wine doesn't break. And we all have seen how easy wine gets messed up when something in underlying linux software changes. May it be the kernel or X. Besides wine doesn't do all the testing for you. You still need to do a lot of testing on different configurations.
On Friday 16 December 2005 10:49, Peter Beutner wrote:
Wine is _not_ just a different toolkit. Just look at all the "nasty" stuff wine has to do to emulate the windows process environment.
I guess in the long term a project like wine, if successfull, doesn't have to live with the restrictions put up by the environment. If I understand correctly, the reason we have to do this nasty stuff, is because the kernel is missing functionality, which the NT kernel provides. Linus has stated that he thinks the Wine project is pivotal for Linux success as a desktop operation system. The kernel guys have been pretty cooperative before and I'm sure if we tell them what we need, or even better help out implementing it, Wine could be just another toolkit, perfectly well integrated _with_ the Linux environment.
As long as wine doesn't break. And we all have seen how easy wine gets messed up when something in underlying linux software changes. May it be the kernel or X.
"Success is measured by your ability to maintain enthusiasm between failures." - Sir Winston Churchill
Bye,
Michael Jung schrieb:
On Friday 16 December 2005 10:49, Peter Beutner wrote:
Wine is _not_ just a different toolkit. Just look at all the "nasty" stuff wine has to do to emulate the windows process environment.
I guess in the long term a project like wine, if successfull, doesn't have to live with the restrictions put up by the environment. If I understand correctly, the reason we have to do this nasty stuff, is because the kernel is missing functionality, which the NT kernel provides. Linus has stated that he thinks the Wine project is pivotal for Linux success as a desktop operation system. The kernel guys have been pretty cooperative before and I'm sure if we tell them what we need, or even better help out implementing it, Wine could be just another toolkit, perfectly well integrated _with_ the Linux environment.
Let's just look at the problem with the memory layout. Wine relies on the possibility to load certain codes at fixed addresses as this is how it works under windows. Linux choose exact the opposite direction, i.e. try to ensure that libraries are loaded at random places in the memory. This is not a missing feature it is a complete different design decision. And I seriously doubt that the kernel/or glibc guys will import the security flaw from windows to always load code at fixed positions. So wine will have to live forever with it's custom preloader hack to emulate the windows process environment.
As long as wine doesn't break. And we all have seen how easy wine gets messed up when something in underlying linux software changes. May it be the kernel or X.
"Success is measured by your ability to maintain enthusiasm between failures."
- Sir Winston Churchill
But this only applies to wine, not to software companies trying to make money with their work? Is it too much to expect that enthusiasm from them? Or how should I interpret this?
Bye,
On Friday 16 December 2005 12:54, Peter Beutner wrote:
Let's just look at the problem with the memory layout. Wine relies on the possibility to load certain codes at fixed addresses as this is how it works under windows. Linux choose exact the opposite direction, i.e. try to ensure that libraries are loaded at random places in the memory. This is not a missing feature it is a complete different design decision. And I seriously doubt that the kernel/or glibc guys will import the security flaw from windows to always load code at fixed positions. So wine will have to live forever with it's custom preloader hack to emulate the windows process environment.
Well, wine is loading code at fixed positions. So we are bypassing this security mechanism, right? If I understand correctly, if the kernel/glibc guys will "fix" this, Wine will have major problems.
This means there are many people (all wine users) dependend on being able to load stuff at fixed positions. Since we are doing it anyway, and if the PE loader would be integrated with the standard ELF loader, the kernel could make an exception for PE executables. That's what I mean about the environment adapting to given usage scenarios like wine. If this is too much of a security problem for a given system, one would'nt install wine anyway.
But this only applies to wine, not to software companies trying to make money with their work? Is it too much to expect that enthusiasm from them? Or how should I interpret this?
All I meant to say is that Wine is great and very successfull at working against the odds.
Bye,
Michael Jung schrieb:
On Friday 16 December 2005 12:54, Peter Beutner wrote:
Let's just look at the problem with the memory layout. Wine relies on the possibility to load certain codes at fixed addresses as this is how it works under windows. Linux choose exact the opposite direction, i.e. try to ensure that libraries are loaded at random places in the memory. This is not a missing feature it is a complete different design decision. And I seriously doubt that the kernel/or glibc guys will import the security flaw from windows to always load code at fixed positions. So wine will have to live forever with it's custom preloader hack to emulate the windows process environment.
Well, wine is loading code at fixed positions. So we are bypassing this security mechanism, right? If I understand correctly, if the kernel/glibc guys will "fix" this, Wine will have major problems.
This means there are many people (all wine users) dependend on being able to load stuff at fixed positions. Since we are doing it anyway, and if the PE loader would be integrated with the standard ELF loader, the kernel could make an exception for PE executables. That's what I mean about the environment adapting to given usage scenarios like wine. If this is too much of a security problem for a given system, one would'nt install wine anyway.
The point is that it won't be integrated in neither kernel or glibc. At least I can't imagine that this will happen. Why should anybody integrate another binary loader/memory layout into the kernel/libc where there is already a fully working one? Just because some people don't want to spend time/money to port their code to linux? I don't think with an argument like that you get this stuff included somewhere :/ (not even mentioning the flaws in the "windows mechanism").
So no, I don't believe that the environment(e.g. kernel/libc) will be adapting to wine in this aspect.
Don't get me wrong I still think it is perfectly valid that wine is doing that sort of hack to get existing windows applications working but you really shouldn't advertise it as a solution to platform independence and encourage developers to go this way.
The point is that it won't be integrated in neither kernel or glibc. At least I can't imagine that this will happen. Why should anybody integrate another binary loader/memory layout into the kernel/libc where there is already a fully working one? Just because some people don't want to spend time/money to port their code to linux? I don't think with an argument like that you get this stuff included somewhere :/ (not even mentioning the flaws in the "windows mechanism").
So no, I don't believe that the environment(e.g. kernel/libc) will be adapting to wine in this aspect.
Don't get me wrong I still think it is perfectly valid that wine is doing that sort of hack to get existing windows applications working but you really shouldn't advertise it as a solution to platform independence and encourage developers to go this way.
Wine is doing fine already in regards to randomization (or not), mostly thanks to wine-preloader.
I see no need for action.
Ciao, Marcus
On Friday 16 December 2005 15:41, Peter Beutner wrote:
The point is that it won't be integrated in neither kernel or glibc.
Integration in the loader is just one possibility. Wine needs to load code at fixed positions. Thus, there has to be a possibility to do it. Currently we do it in a way that some people consider a hack. If this is a problem (and I'm not saying that it actually is), we would have to fix it. This means we would have to illustrate our problem to the guys doing the randomization stuff. Wine is important to many people, so I think they would give us an open ear and we could fix the issues together.
Don't get me wrong I still think it is perfectly valid that wine is doing that sort of hack to get existing windows applications working but you really shouldn't advertise it as a solution to platform independence and encourage developers to go this way.
If someone plans to do a new multi-platform project, I'm pretty sure no one in their right mind would suggest wine to do it. But there is a whole lot of legacy applications for which the only economically feasible way to port them to linux might be via wine.
Bye,
Michael Jung schrieb:
On Friday 16 December 2005 15:41, Peter Beutner wrote:
Don't get me wrong I still think it is perfectly valid that wine is doing that sort of hack to get existing windows applications working but you really shouldn't advertise it as a solution to platform independence and encourage developers to go this way.
If someone plans to do a new multi-platform project, I'm pretty sure no one in their right mind would suggest wine to do it. But there is a whole lot of legacy applications for which the only economically feasible way to port them to linux might be via wine.
Agreed. This sums up quite well what I wanted to say ;)
"Peter" == Peter Beutner p.beutner@gmx.net writes:
Peter> Michael Jung schrieb: >> On Friday 16 December 2005 15:41, Peter Beutner wrote: >>> Don't get me wrong I still think it is perfectly valid that wine is >>> doing that sort of hack to get existing windows applications working >>> but you really shouldn't advertise it as a solution to platform >>> independence and encourage developers to go this way. >> If someone plans to do a new multi-platform project, I'm pretty sure >> no one in their right mind would suggest wine to do it. But there is >> a whole lot of legacy applications for which the only economically >> feasible way to port them to linux might be via wine.
Peter> Agreed. This sums up quite well what I wanted to say ;)
Any new project with multi platform target in mind would probably be created on a more "library like" library than Wine(lib). However I guess few projects are created that way. Projects have often a long history, and for the last year Windows was the only target was windows...
So getting winelib in a more mature fashion will help all those legacy projects...
Bye
Peter Beutner wrote:
Michael Jung schrieb:
On Friday 16 December 2005 10:49, Peter Beutner wrote:
Wine is _not_ just a different toolkit. Just look at all the "nasty" stuff wine has to do to emulate the windows process environment.
I guess in the long term a project like wine, if successfull, doesn't have to live with the restrictions put up by the environment. If I understand correctly, the reason we have to do this nasty stuff, is because the kernel is missing functionality, which the NT kernel provides. Linus has stated that he thinks the Wine project is pivotal for Linux success as a desktop operation system. The kernel guys have been pretty cooperative before and I'm sure if we tell them what we need, or even better help out implementing it, Wine could be just another toolkit, perfectly well integrated _with_ the Linux environment.
Let's just look at the problem with the memory layout. Wine relies on the possibility to load certain codes at fixed addresses as this is how it works under windows. Linux choose exact the opposite direction, i.e. try to ensure that libraries are loaded at random places in the memory. This is not a missing feature it is a complete different design decision. And I seriously doubt that the kernel/or glibc guys will import the security flaw from windows to always load code at fixed positions. So wine will have to live forever with it's custom preloader hack to emulate the windows process environment.
You don't seem to realise that you can execute wine-pthread or wine-kthread directly instead of executing wine-preloader. I doubt companies using Wine will care (since the same security flaw will affect Windows and will have to be patched with urgency) and if they do then they can compile their app as a winelib app, which uses the OS's dynamic loader and whatever security benefits come with it.
Your arguments seem to centre around complaining about the baggage that Wine brings around with it, yet that we emulate the Windows environment so well is the very reason that a Wine port is so much cheaper for companies than a full port.
On Freitag 16 Dezember 2005 10:49, Peter Beutner wrote:
Robert Shearman schrieb:
Peter Beutner wrote:
Maybe it's just me but when reading all this I got the feeling that writing windows applications(which work with wine) is just *the* way to go.
It is the cheapest way for companies and it gives good results for the users. What's wrong with that?
See above. Wine does a lot of "tricks" to emulate windows behaviour. And the more you use some complex window api the more is the chance that wine just can't implement it the way it works in windows but has to use all sorts of workarounds to get it to work under linux. Sure all that probably won't interest any manager in a company and probably won't stand against the "money" argument. But as a developer I would always vote for doing a little bit of extra thinking by going the platform independent way.
That's perfectly valid from a technical point of view. However, I do think you're grossly overestimating both financial and HR capabilities of most ISVs on the market. Moreover, there's the risk factor: Why should an ISV start changing their code base to be more cross-platform while having a pretty high risk that in the forseeable future, revenue generated by this move might be very close or equal to zero?
As a technician, I absolutely see your points and find most of them perfectly valid. As a businessman, however, I think Wine is in many cases a very attractive - and in some cases, the only viable - approach for cross-platform efforts an ISV might make in a short to mid-term timeframe. Which approach they take depends on many factors, but helping them in case they decided to go the Wine way is definetly good for both them and the Wine project.
David
"Peter Beutner" p.beutner@gmx.net wrote:
Why? Wine is effectively just a different toolkit, like QT or GTK (albeit much larger) that give applications a Windows, KDE and Gnome look respectively. Take Notepad for example - with some slight modifications you could even modify the File Open dialog to only show the Unix namespace. Is there any reason that this application can't be a fully fledged part of the desktop?
Wine is _not_ just a different toolkit. Just look at all the "nasty" stuff wine has to do to emulate the windows process environment. This is not exactly what I would prefer as an ideal environment when I had to develop an application.
Since Wine is not a trivial thing written in 3 lines of code and it has huge compatibility requirements it must to do all kinds of things to make you (a developer) not to do that kind of things in your own code. Think about that. Said that, nothing makes it a different from another toolkit, no matter what Wine haters think about it.
Sure. While you're at it give them some docs about globalization practices and efficient CPU usage. These are all nice to have things, but you have to face it that if you're a developer at a software company with a deadline then these are the first things to be ignored. You also have to bear in mind that it is incredibly difficult to do platform idependent GUI programming, whilst still maintaining the Windows look.
Nobody said it's easy or that it will happen over night. But it can/should be the long term goal. Besides gtk+/qt are imho quite mature to use as cross-plattform gui toolkits.
I don't understand why you can't include Wine in that list. Is that an ignorance or a result of hate to all which goes from windows world?
It is the cheapest way for companies and it gives good results for the users. What's wrong with that?
See above. Wine does a lot of "tricks" to emulate windows behaviour. And the more you use some complex window api the more is the chance that wine just can't implement it the way it works in windows but has to use all sorts of workarounds to get it to work under linux.
Sounds like a popular Wine myth. Anyone who ever seen a working MS Office 97/2000/XP/2003 or any other not trivial application working under Wine wouldn't tell anything like that, especially if he is a knowledgeable developer and not another member ./ crowd.
Sure all that probably won't interest any manager in a company and probably won't stand against the "money" argument. But as a developer I would always vote for doing a little bit of extra thinking by going the platform independent way.
Wine is a very good way of testing the waters with a Linux market. If a significant part of the market share starts coming from Linux or other Unix operating systems then the company can start offering winelib extensions that integrate better with the environment in which they are running.
I doubt that this will happen. If the windows version works with wine the company will more likely continue to work on that. See your money argument.
Another myth about Wine.
However, you have to face facts that Linux is a hostile environment for commercial companies - constantly changing APIs, lack of regression testing by distributions, lots of variations meaning lots of testing needed and different standards on different distributions. Wine is a layer on top of that, which provides a degree of stability.
As long as wine doesn't break. And we all have seen how easy wine gets messed up when something in underlying linux software changes. May it be the kernel or X. Besides wine doesn't do all the testing for you. You still need to do a lot of testing on different configurations.
Which is the case for every other toolkit, it's not Wine specific.
Dmitry Timoshkov schrieb:
"Peter Beutner" p.beutner@gmx.net wrote:
Why? Wine is effectively just a different toolkit, like QT or GTK (albeit much larger) that give applications a Windows, KDE and Gnome look respectively. Take Notepad for example - with some slight modifications you could even modify the File Open dialog to only show the Unix namespace. Is there any reason that this application can't be a fully fledged part of the desktop?
Wine is _not_ just a different toolkit. Just look at all the "nasty" stuff wine has to do to emulate the windows process environment. This is not exactly what I would prefer as an ideal environment when I had to develop an application.
Since Wine is not a trivial thing written in 3 lines of code and it has huge compatibility requirements it must to do all kinds of things to make you (a developer) not to do that kind of things in your own code. Think about that.
hm if you somehow manage to build your project in a platform independent way so that you can build a native windows executable as well as a native linux one, then you don't need the whole compatibility code at all ;)
Said that, nothing makes it a different from another toolkit, no matter what Wine haters think about it.
hmm you don't mean this for real, don't you?
Sure. While you're at it give them some docs about globalization practices and efficient CPU usage. These are all nice to have things, but you have to face it that if you're a developer at a software company with a deadline then these are the first things to be ignored. You also have to bear in mind that it is incredibly difficult to do platform idependent GUI programming, whilst still maintaining the Windows look.
Nobody said it's easy or that it will happen over night. But it can/should be the long term goal. Besides gtk+/qt are imho quite mature to use as cross-plattform gui toolkits.
I don't understand why you can't include Wine in that list. Is that an ignorance or a result of hate to all which goes from windows world?
No, it's because I think wine is not a just a gui toolkit.
It is the cheapest way for companies and it gives good results for the users. What's wrong with that?
See above. Wine does a lot of "tricks" to emulate windows behaviour. And the more you use some complex window api the more is the chance that wine just can't implement it the way it works in windows but has to use all sorts of workarounds to get it to work under linux.
Sounds like a popular Wine myth. Anyone who ever seen a working MS Office 97/2000/XP/2003 or any other not trivial application working under Wine wouldn't tell anything like that,especially if he is a knowledgeable developer and not another member ./ crowd.
Haven't said that it doesn't work. I just said sometimes you can't easily map stuff 1:1 from the windows world to linux. Just look at the things like the memory layout, parts of the gdi stuff, the whole ntoskrnl idea, ...
Wine is a very good way of testing the waters with a Linux market. If a significant part of the market share starts coming from Linux or other Unix operating systems then the company can start offering winelib extensions that integrate better with the environment in which they are running.
I doubt that this will happen. If the windows version works with wine the company will more likely continue to work on that. See your money argument.
Another myth about Wine.
Glad to hear that. So there are already companies shipping winelib extensions for their products?
Peter Beutner wrote:
Dmitry Timoshkov schrieb:
"Peter Beutner" p.beutner@gmx.net wrote:
Wine is a very good way of testing the waters with a Linux market. If a significant part of the market share starts coming from Linux or other Unix operating systems then the company can start offering winelib extensions that integrate better with the environment in which they are running.
I doubt that this will happen. If the windows version works with wine the company will more likely continue to work on that. See your money argument.
Another myth about Wine.
Glad to hear that. So there are already companies shipping winelib extensions for their products?
I know of at least one company that was considering this for interfacing their software with a USB hardware device that the software shipped with.
I really fear that this will end up with vendors loudly advertising linux support and proudly putting linux stickers on their products where everything you find inside are just the same windows .exe files and a readme stating that these will work fine with wine. Which at least is not what I would like to see.
I agree. :)
The main thing the _developers_ should be pointed to(if they care about their product on other platforms then windows) are some decent docs about platform-independent programming :p
Yes, they should. I think developers think about abstracting their development around cross-platform toolkits like Gtk or QT But, then again, far too many developers don't now, and probably won't ever. So what then?
Maybe it's just me but when reading all this I got the feeling that writing windows applications(which work with wine) is just *the* way to go. Why the hell are we running linux then?
I agree here too. Maybe this is slightly off topic in this thread, but I still have some concerns about wine's ability to run apps. Right now, development of wine is centered around getting certain apps to work. Not to mention, I also think that Wine doesn't have a big enough developer base to really address that. Windows is a *gargantuan* piece of software. Over Wine's lifetime there have been about 800 contributors with about 40 active now. I really don't think that's enough to get Wine where it needs to go, especially if we want to market ourselves as a porting solution.
Not that I generally disagree with what you wrote. Actually it's mostly totally fine.And it's definitly a good thing when vendors care about their product running with wine or companies migrating to linux trying to get their highly-specialized-app to work with wine. But imho it _shouldn't_ be the long term solution.
Yes, the site that Dan put together is pretty good. It's got lots of good info. But put yourself in the ISV's shoes. If I had some big commercial product I wanted to port, would I want to use a known unstable platform, that may or may not work, to do it with?
Not that I mean to sound like a pessimist, but I'm really just calling it as I see it. No offense to anyone intended. :)
Not that I mean to sound like a pessimist, but I'm really just calling it as I see it. No offense to anyone intended. :)
This, in a nutshell, is Wine's greatest challenge (stepping even outside ISV boundaries for a minute).
I believe, either because I'm insane (the likely explanation), or because it's true, that Wine has progressed remarkably in the past 5 years, and can no longer be correctly dismissed as unstable or unusable.
I think the shift from Alpha to Beta status was a more dramatic signal that anyone really realizes; I think it marks the point where Wine can reliably be used for a broad range of purposes.
But, bluntly, we have to prove it. We have to start by continuing the drive to a solid 1.0; we have to continue helping a small number of ISVs really succeed.
And then of course comes the fun part; we have to hold that line and not let any regressions in :-/.
But I think we can do it; it's why I'm still here.
Someday I hope to stop apologizing for Wine (and for Linux for that matter) and start bragging; and I don't think that day is too far ahead (it better not be, my wife is really getting mad at me :-/).
Sorry, I'd type more, but these friendly men tell me they have a nice white jacket they want me to try on...
Cheers,
Jeremy
James Liggett schrieb:
I really fear that this will end up with vendors loudly advertising linux support and proudly putting linux stickers on their products where everything you find inside are just the same windows .exe files and a readme stating that these will work fine with wine. Which at least is not what I would like to see.
I agree. :)
The main thing the _developers_ should be pointed to(if they care about their product on other platforms then windows) are some decent docs about platform-independent programming :p
Yes, they should. I think developers think about abstracting their development around cross-platform toolkits like Gtk or QT But, then again, far too many developers don't now, and probably won't ever. So what then?
So tell them about it ;) If the care a bit about other platforms they will at least think about it. And if they can't rewrite their existing software because it would be too much work or the product is no longer in development you could still point them to wine and try to work together to get it run on wine.But imho it should be in this order and not the other way around.
Hi,
How about we create a new mailing list, wine-isv, aimed squarely at ISVs and the Wine community members who want to help them?
I'd say go for it!
Stefan
On Mittwoch 14 Dezember 2005 07:33, Dan Kegel wrote:
How about we create a new mailing list, wine-isv, aimed squarely at ISVs and the Wine community members who want to help them?
Sounds like a good idea to me ;)
David
You're secretly just trying to get me to finish the commercial page I promised, huh?
I'll vote against a wine-isv list. History has shown we're not responsible enough to have many mailing lists. Sure, if it takes off.. great. But more than likely we'll be having a discussion on wine-devel in 18 months about getting rid of the list because only a handful of people are subscribed. In the mean time, the 3 or 4 people who ask questions on wine-isv will get incomplete answers or referred to wine-devel. Let's have the documentation refer the users to wine-devel with questions. If things get off topic or wine-devel gets overwhelmed, then make the list.
The stuff you put together looks really nice. There's parts that could be expanded; the getting started section is easily 20 pages of written material. Anyway, I think this stuff belongs in the Winelib User's Guide in some form. Said a different way, I think the Winelib User's Guide needs to include a section about "Why It's Okay to Ship a PE Executable". Then again, we all know the Winelib guide needs to be rewritten.
-Brian
On 12/15/05, Brian Vincent brian.vincent@gmail.com wrote:
You're secretly just trying to get me to finish the commercial page I promised, huh?
:-)
I'll vote against a wine-isv list. History has shown we're not responsible enough to have many mailing lists. Sure, if it takes off.. great. But more than likely we'll be having a discussion on wine-devel in 18 months about getting rid of the list because only a handful of people are subscribed. In the mean time, the 3 or 4 people who ask questions on wine-isv will get incomplete answers or referred to wine-devel. Let's have the documentation refer the users to wine-devel with questions. If things get off topic or wine-devel gets overwhelmed, then make the list.
I would totally agree with you except for one thing: ISVs who are looking at the mailing list archives are going to be overwhelmed by the volume and technical level on wine-devel, and will be afraid to join and post. If everyone agrees that's not really a problem, then I'm fine with directing ISVs to wine-devel.
The stuff you put together looks really nice.
Thanks!
There's parts that could be expanded; the getting started section is easily 20 pages of written material. Anyway, I think this stuff belongs in the Winelib User's Guide in some form. Said a different way, I think the Winelib User's Guide needs to include a section about "Why It's Okay to Ship a PE Executable". Then again, we all know the Winelib guide needs to be rewritten.
I really don't think Winelib should be involved for the majority of ISVs. Rather than add a section to the Winelib user's guide, let's move all the ISV-oriented stuff to an ISV guide, and add a section in there called "When to use Winelib" that links to the Winelib user guide, or something like that.
As with my QA page, I'm happy to help move my ISV page into the official WineHQ doc when it's more ready, but while I'm working on it I prefer to keep using plain HTML on my site. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
Hi,
I'll vote against a wine-isv list. History has shown we're not responsible enough to have many mailing lists. Sure, if it takes off.. great. But more than likely we'll be having a discussion on wine-devel in 18 months about getting rid of the list because only a handful of people are subscribed. In the mean time, the 3 or 4 people who ask questions on wine-isv will get incomplete answers or referred to wine-devel. Let's have the documentation refer the users to wine-devel with questions. If things get off topic or wine-devel gets overwhelmed, then make the list.
That's also my experience. I would be the perfect man for such a new group, cause my partner and I are developing Windows applications (http://www.emtec.com). Seeing Wine some months ago fascinated me a lot, so since then I'm spending one or two hours a day trying to bring our applications to work under Wine, too...
But it's clear that there are not enough ressources there to help ISVs like me out of some problems. Sometimes I have contact with one of the developers after submitting a bug, or writing something into the wine-devel list, but without doing a lot of clarification before (like looking into the Wine sources, close in the problem area, and asking really specific questions to the corresponding 5 or 10 lines of code in the Wine sources) nobody really have time to help. That's clear to me, cause the project is huge and the developing stuff is relatively small, so it is as it is.
Only if the whole project would find it a main goal to support ISVs with there products, and some personal ressources are available, such a new list would be of any help.
Don't understand me wrong, I'm a total Wine fan, but at the moment it looks to me that supportings ISVs which are more interested in their own product as on Wine is not realistic...
Cheers
Markus
On 12/13/05, Dan Kegel dank@kegel.com wrote:
So I've been thinking about how to attract more Windows ISVs to test, support, and promote their apps on Linux with Wine. ... I've made a start at the documentation (http://kegel.com/wine/isv) ... How about we create a new mailing list, wine-isv, aimed squarely at ISVs and the Wine community members who want to help them?
I realized I needed a discussion forum for that web page anyway for people who wanted to provide feedback, so I went and created one at google groups and added a link at the bottom of my page to it. Anyone who's interested in testing the idea of a wine-isv mailing list is welcome to join. Thanks, Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv
-
Brian Vincent -
Dan Kegel -
Dan Kegel -
David Gümbel -
Dmitry Timoshkov -
James Liggett -
Jeremy White -
Marcus Meissner -
Markus G�mmel -
Michael Jung -
Peter Beutner -
Robert Shearman -
Scott Ritchie -
Stefan Dösinger -
Uwe Bonnes