Now I also got some questions from your answers:
- Did I understand correctly. Wine doesn't have a built in support for DCom, to be abel to use Dcom I have to add the DCom support from Windows 98 to the Linux system?
And the problem with that is the MS License, it stops me from distribute those XXX.dll with a Linux product (hardware and software in this case.)
It doesn't stop you, basically the license says "you must have a Windows license to use this code". Because it's technically a part of Windows, see?
Yyyy! I hate license issues! I can see that for many people this wouldn't be an issue, because they probably have some old Win 98 CD/Licens somewhere (if they even care). But for a company that would like to send it as part of an embedded computer with Linux I can se a lot of problems.
However a Windows license is quite cheap relative to $3000-$4000 for the APIs so maybe this isn't a problem.
But that was per development project, not per system we want to use OPC in.
You could even buy copies of Windows 98 off ebay or something for ultra-cheap living. The license can be for any version of Windows AFAIK.
That could perhaps be an idea.... What does AFAIK stand for?
The difficulty may be that nobody has tested network DCOM servers on Wine as far as I know, even using Microsofts implementation. So you'd be doing some pioneering work :)
That is good ;-) In the industry we are a lot of people who really question the total madness of letting the OPC standard be that depended on Windows, when it is supposed to be a "free" organization.
My hope if I can get this to work is to publish a site on the net so all who want to use Linux in the industrial computing can do that quite easy... But then we have the license issues to :-(
Wines own, builtin code. This is incomplete and cannot do what you want.
Microsofts DCOM implementation
Wine *does* have support for MSRPC, and I think it's wire compatible with Windows these days and capable of making simple RPCs. However the RPC runtime (rpcrt4.dll) is just the first layer of DCOM, all the rest don't work right yet.
Ok, now I understand, and also why I got confused before.
And there is a lot of work needed to make DCom to work in Wine? Is someone working on it or is it something that not is that important in other cases?
Thanks a lot Mike for you answer!
/Rickard
What does AFAIK stand for?
As Far As I Know.
On Tue, 07 Sep 2004 01:47:15 -0500, Rickard Svensson riq@mail.com wrote:
Now I also got some questions from your answers:
- Did I understand correctly. Wine doesn't have a built in support for DCom, to be abel to use Dcom I have to add the DCom support from Windows 98 to the Linux system?
And the problem with that is the MS License, it stops me from distribute those XXX.dll with a Linux product (hardware and software in this case.)
It doesn't stop you, basically the license says "you must have a Windows license to use this code". Because it's technically a part of Windows, see?
Yyyy! I hate license issues! I can see that for many people this wouldn't be an issue, because they probably have some old Win 98 CD/Licens somewhere (if they even care). But for a company that would like to send it as part of an embedded computer with Linux I can se a lot of problems.
However a Windows license is quite cheap relative to $3000-$4000 for the APIs so maybe this isn't a problem.
But that was per development project, not per system we want to use OPC in.
You could even buy copies of Windows 98 off ebay or something for ultra-cheap living. The license can be for any version of Windows AFAIK.
That could perhaps be an idea.... What does AFAIK stand for?
The difficulty may be that nobody has tested network DCOM servers on Wine as far as I know, even using Microsofts implementation. So you'd be doing some pioneering work :)
That is good ;-) In the industry we are a lot of people who really question the total madness of letting the OPC standard be that depended on Windows, when it is supposed to be a "free" organization.
My hope if I can get this to work is to publish a site on the net so all who want to use Linux in the industrial computing can do that quite easy... But then we have the license issues to :-(
Wines own, builtin code. This is incomplete and cannot do what you want.
Microsofts DCOM implementation
Wine *does* have support for MSRPC, and I think it's wire compatible with Windows these days and capable of making simple RPCs. However the RPC runtime (rpcrt4.dll) is just the first layer of DCOM, all the rest don't work right yet.
Ok, now I understand, and also why I got confused before.
And there is a lot of work needed to make DCom to work in Wine? Is someone working on it or is it something that not is that important in other cases?
Thanks a lot Mike for you answer!
/Rickard
Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm
You could even buy copies of Windows 98 off ebay or something for ultra-cheap living. The license can be for any version of Windows AFAIK.
That could perhaps be an idea.... What does AFAIK stand for?
http://www.acronymfinder.com/af-query.asp?String=exact&Acronym=AFAIK&...
bye Fabi
Yyyy! I hate license issues! I can see that for many people this wouldn't be an issue, because they probably have some old Win 98 CD/Licens somewhere (if they even care). But for a company that would like to send it as part of an embedded computer with Linux I can se a lot of problems.
OK. I don't really know the details of licensing in embedded scenarios but I can see it would cause problems.
But that was per development project, not per system we want to use OPC in.
Ah, I see. Surely if you depend on Windows though you *already* have to pay for Windows on a per-system basis? No? Or do you get bulk deals ...
That is good ;-) In the industry we are a lot of people who really question the total madness of letting the OPC standard be that depended on Windows, when it is supposed to be a "free" organization.
My hope if I can get this to work is to publish a site on the net so all who want to use Linux in the industrial computing can do that quite easy... But then we have the license issues to :-(
Yes. Unfortunately there are (as far as I know) only 4 DCOM implementations in the world:
1) the one in Microsoft Windows 2) DCOM for UNIX, which is based on Microsofts code 3) Wines 4) Cedegas (this is similar to Wines but more advanced, at least for InstallShield support)
The only one that is under a liberal license is Wines which is incomplete. The only way to solve this problem is by having a free-as-in-speech implementation of DCOM, which means extending and improving Wine.
Ok, now I understand, and also why I got confused before.
And there is a lot of work needed to make DCom to work in Wine? Is someone working on it or is it something that not is that important in other cases?
Yes, it's a fair amount of work. Currently nobody is working on it as their primary project - Rob Shearman and I did some work on it for iTunes/InstallShield support lately and most of our code is motivated by InstallShield.
It is something that we want to do though, because we currently depend on native DCOM for a lot of stuff, like installers/office embedding/etc etc ... so there's interest there at least from CodeWeavers side. But we're certainly not committed to anything.
One possible plan is this: if it is true that there is general, widespread concern over OPC depending on Windows in the industry, perhaps you could get together with other companies and form a consortium to fund the development of an LGPLd DCOM implementation in Wine. This would allow you to write DCOM based software anywhere that Wine runs and be independent of Microsoft and licensing costs.
I think if funding was available in the right amounts Jeremy could be persuaded to have CW at least put some hours into it and I know at least one guy from ReactOS wants to work on it too. But I can't say for sure.
Anyway, it was just a thought.
thanks -mike
On Tue, Sep 07, 2004 at 10:14:50AM +0100, Mike Hearn wrote:
Yyyy! I hate license issues! I can see that for many people this wouldn't be an issue, because they probably have some old Win 98 CD/Licens somewhere (if they even care). But for a company that would like to send it as part of an embedded computer with Linux I can se a lot of problems.
OK. I don't really know the details of licensing in embedded scenarios but I can see it would cause problems.
Ditto.
But that was per development project, not per system we want to use OPC in.
Ah, I see. Surely if you depend on Windows though you *already* have to
Are they already using it? Maybe they're just looking at options right now.
pay for Windows on a per-system basis? No? Or do you get bulk deals ...
Well, even here, buying a site licence (even for 98 or ME or something) should cost much less than $3000-4000 for the native solution, (right?) and you could always say have Windows on the embedded device and disabled (or included on a useless CD packaged with the device) and then use the single dll or group of dlls to do RPC in wine on Linux on the device, right? I mean, Microsoft would still be paid for their work on the dlls, so shouldn't that be okay?
That is good ;-) In the industry we are a lot of people who really question the total madness of letting the OPC standard be that depended on Windows, when it is supposed to be a "free" organization.
And no one has come up with a low cost or open source Linux version yet? How unusual. You could always ask people in the industry to help in funding, development, setup, improvement and/or testing of such a system (low cost or open source).
My hope if I can get this to work is to publish a site on the net so all who want to use Linux in the industrial computing can do that quite easy... But then we have the license issues to :-(
What about HOWTOs or guides and info on the experience? That would be a start...
Yes. Unfortunately there are (as far as I know) only 4 DCOM implementations in the world:
- the one in Microsoft Windows
- DCOM for UNIX, which is based on Microsofts code
- Wines
- Cedegas (this is similar to Wines but more advanced, at least for
InstallShield support)
The only one that is under a liberal license is Wines which is incomplete. The only way to solve this problem is by having a free-as-in-speech implementation of DCOM, which means extending and improving Wine.
Ok, now I understand, and also why I got confused before.
And there is a lot of work needed to make DCom to work in Wine? Is someone working on it or is it something that not is that important in other cases?
Yes, it's a fair amount of work. Currently nobody is working on it as their primary project - Rob Shearman and I did some work on it for iTunes/InstallShield support lately and most of our code is motivated by InstallShield.
It is something that we want to do though, because we currently depend on native DCOM for a lot of stuff, like installers/office embedding/etc etc ... so there's interest there at least from CodeWeavers side. But we're certainly not committed to anything.
One possible plan is this: if it is true that there is general, widespread concern over OPC depending on Windows in the industry, perhaps you could get together with other companies and form a consortium to fund the development of an LGPLd DCOM implementation in Wine. This would allow you to write DCOM based software anywhere that Wine runs and be independent of Microsoft and licensing costs.
I think this sound intreaging and a good concept. Even if you start small, (i.e 2-5 companies) the concept could grow bigger over time.
I think if funding was available in the right amounts Jeremy could be persuaded to have CW at least put some hours into it and I know at least one guy from ReactOS wants to work on it too. But I can't say for sure.
Would in this case, you want to say that the funding would have the clause that code provided would have to be LGPLed, included in WineHQ/Wine, and would be owned by the writer(s)? :D
Anyway, it was just a thought.
thanks -mike
Just a few comments.
--Michael Chang
-
Fabian Cenedese -
James Hawkins -
michael＠cherryblossom.homelinux.com -
Mike Hearn -
Rickard Svensson