Troy
Thanks for your comments. The issue with using a 'script' file versus a true 'executable' is really a matter of marketing.
Our Windows product does run under 'wine' however we have clients that don't consider that acceptable. We are looking at having a "True" X-Windows / Unix / Linux implementation.
While my background is technical, I understand that much of a products acceptability is based on market perception. 'Wine' unfortunately is perceived as a emulation, and while that is far from the truth, it still means people will shy away from it as a solution.
That being said, if we can find a way to launch a 'winelib' developed version of our system we feel we can prove that 'wine' is the way to go. Using dynamic (.so) libraries is a good concept -- I am just trying to find a way to make a 'wine' version of our product viable for our clients.
Sad isn't it ... we may have to look at alternatives only to satsify the marketplace.
From what I have seen so far 'wine' is a great product, I just need to convince others
that it's the solution to their requirements.
Regards, Mike King
----- Original Message ----- From: "Troy Rollo" wine@troy.rollo.name To: wine-devel@winehq.org Cc: "Michael King" mike.king@pvxplus.com Sent: Monday, February 20, 2006 8:30 PM Subject: Re: Winelib
On Tuesday 21 February 2006 06:33, Michael King wrote:
Thanks for all the help.
Seems to me that wine and winelib may not be the way for us to go.
We have a functioning application development language that runs on Windows plus virtually all flavours of Unix/Linux but the only GUI implementation is Windows. We were looking for an easy way to port the environment to 'X' windows without having to recode all the GUI interfaces.
Why should it matter that the program builds to a ".so" file and has to be launched via a script? Even if it only involved libraries, nobody links to static libraries anymore so you would still need external libraries. -- Troy Rollo - wine@troy.rollo.name