- Wine-Devel - list.winehq.org

Re: Wine and industrial communication like OPC
by Rickard Svensson Sept. 14, 2004

Sept. 14, 2004

Hallo, sorry I didet awnser in a wile. Some discussion about the company at work on end license per system and so on. License issues isn't fun but ok I can tell you some more. Perhaps someone who knows more about license issues can contribute with something. Our company makes an embedded computer for general use, the first OS that it supported was Linux (an embedded minimum Debian about 10 mb + our app), which we have a customer that uses now. Now a colleague is working on a XP embedded version (is about 70 mb) Our company mostly works with Windows because most of our customers only use Windows. We don't sell any computers with Windows (we don't get bulk deals). We are mostly a software development company. The general industrial application we have made is good, most of our customers doesn't know that it is running Linux, and those who know likes it. But then the demand for OPC increased... In our case the cost of buying a OPC API for Linux perhaps could be economically reasonably, it depends on the amount of Linux computers with OPC we would sell. * 3000-4000$ / numbers of system * A fixed price for Windows licenses to be able to use the Win 98 DCom update. Win License prize * numbers of systems I am now doing some programming task and looking at our options. How does the API we can by from vendors to get OPC on Linux work and cost now. I found the DCom update for Win 98 (Se: http://www.microsoft.com/com/dcom/dcom98/download.asp?SD=GN&LN=SV&gssnb=1) The licens is bad: (Se: http://www.microsoft.com/com/dcom/dcom98/eula.asp) --- --- --- --- 1. GRANT OF LICENSE. This EULA grants you the following rights: * Software License. Microsoft grants you the right to make and use as many copies of the SOFTWARE PRODUCT as you have validly licensed copies of Microsoft® Windows® 98. You may also make copies of the SOFTWARE PRODUCT for backup and archival purposes. * Distribution. You may not redistribute DCOM98. --- --- --- --- The solution that companies like ours that have an interest in OPC collaborates to make a DCom part for Linux through Wine like Mike Hearn and Michael Chang suggested is the one I would go for! But I have to convince my boss... How meny ours do you think it wood take to get DCom to work in Wine? 50 h / 100h / 500h / 1000h ? I'm the one who is mostly for Linux here, as I mentioned XP version is on the way, we have used QT to make or application. So it is easy to migrate and there is a definite risk that all will go towards a XP embedded variant :( From: Mike Hearn <m.hearn(a)signal.QinetiQ.com> Date: Tue, 07 Sep 2004 10:14:50 +0100 To: Rickard Svensson <riq(a)mail.com> Subject: Re: Wine and industrial communication like OPC > > 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 -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

2 1

Re: resend: patch: shell32.dll - SHELL_ArgifyW expands env-vars
by Alexandre Julliard Sept. 14, 2004

Sept. 14, 2004

"Jens Collin" <jens.collin(a)lakhei.com> writes: > + { > + TRACE("The env. var can't be found or is bigger than MAX_PATH => useless."); > + res += sprintfW(res, L"%s%%", tmpBuffer); You cannot use Unicode strings constants in Wine, they don't have the right size. -- Alexandre Julliard julliard(a)winehq.org

5 6

Re: Rename keyword variable
by Alexandre Julliard Sept. 14, 2004

Sept. 14, 2004

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > Hi, > > "template" is a keyword on c++, so better rename it to menu_template. We've been through this before; there's absolutely no reason to do that. -- Alexandre Julliard julliard(a)winehq.org

2 1

Why is our OutputDebugString a server request?
by Shachar Shemesh Sept. 14, 2004

Sept. 14, 2004

Hi all, It seems that OutputDebugString is defined in the Win32 API as a set of client side operations. In wine, however, it is a server request. I have not traced it into the server to see whether they carry out the same operations or not. However, even if they do, I am wondering why we need them? Wouldn't it be better to not do server side things that can be done client side? (http://www.unixwiz.net/techtips/outputdebugstring.html) Shachar P.S. I perfectly understand that obtaining mutexes and waiting on events is a server side operation. However, it was my impression that such things are best carried out by mimicking the Win32 structure as much as possible. Isn't that the case? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

2 1

Re: Re: Why is our OutputDebugString a server request?
by Pouech Eric DMI AEI CAEN Sept. 14, 2004

Sept. 14, 2004

> I get the feeling that I misunderstood what you just said. What is the > debug event? where do we do anything with it? debug events are part of the Win32 debug API. A debugger (ie a process using the client side of this API) will get "debug events" (basically the type of the event and some additional information). Such events are process created/terminated, thread created/terminated, thread stopped and so on. One of these "debug events" is the sending of a debug string (by the program being debugged). This means that running a "decent" debugger (decent meaning implementing the support for this debug event) will print all the OutputDebugString calls from the debuggee. A+

1 0

Re: Why is our OutputDebugString a server request?
by Pouech Eric DMI AEI CAEN Sept. 14, 2004

Sept. 14, 2004

so that debuggers can intercept it (especially ones with GUI) and do what they want with it. A+ > Message du 13/09/04 17:50 > De : "Shachar Shemesh" > A : "Wine Development" > Copie à : > Objet : Why is our OutputDebugString a server request? >

3 3

extern variable question
by Robert Reif Sept. 14, 2004

Sept. 14, 2004

I'm trying to write a Direct Input regression test and I ran into a problem I can't resolve (and the linker too). dinput.h defines an extern variable: extern const DIDATAFORMAT c_dfDIJoystick; I can't find this variable in dinput.dll but it is in dinput.lib on windows. It looks like I need to generate a dinput.a. How can I generate both a dinput.dll.so and a dinput.a from the same source?

1 0

RE: iostream and msvcrt?
by Scott Snell Sept. 14, 2004

Sept. 14, 2004

Hi Dimi, Thanks for the offer but I have had the project pulled. Unfortunately I couldnt get a working model in time and the hardware has been recycled to another project ;-(. Basically I needed to compile STLport so I could use iostreams in a project I was converting to wine. I'm going to keep my eye on this list as I hope to have a new round of funding approved late in the year. I may also get an old PC at home working and have another go! thanks, scott. > -----Original Message----- > From: Dimitrie O. Paun [SMTP:dpaun(a)rogers.com] > Sent: Wednesday, 8 September 2004 0:06 > To: Scott Snell > Cc: Dimitrie O. Paun; Boaz Harrosh; Wine-Devel (E-mail) > Subject: Re: iostream and msvcrt? > > Just got back from vacation. Why is it including a cstdlib? > Anyway, can you send me exactly what you did, so I can try > to reproduce it on my box? > > -- > Dimi.

1 0

Re: Proper finalization in StartServiceW
by Alexandre Julliard Sept. 13, 2004

Sept. 13, 2004

"Alexander Yaworsky" <yaworsky(a)migusoft.ru> writes: > + if( WAIT_FAILED == r ) > + { > + last_error = GetLastError(); > + CloseHandle( procinfo.hProcess ); > + goto done; > + } > > - ReleaseSemaphore(data, 1, NULL); > - > - if( r == WAIT_FAILED) > - return FALSE; > + /* allright */ > + CloseHandle( procinfo.hProcess ); > + last_error = 0; > + ret = TRUE; > > - return TRUE; > +done: > + CloseHandle( wait ); > + ReleaseSemaphore(data, 1, NULL); > + CloseHandle( data ); > + SetLastError( last_error ); > + return ret; You should never need to do that sort of thing. CloseHandle and ReleaseSemaphore won't change last error if they are called for valid handles, and if they are not you are just hiding a bug. Also, you very probably don't want to set last error to 0 on success, unless you have clear evidence that Windows does it in this case too. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Correct ConvertSidToStringSidW with test
by Alexandre Julliard Sept. 13, 2004

Sept. 13, 2004

Juan Lang <juan_lang(a)yahoo.com> writes: > @@ -2230,13 +2232,23 @@ > > sz = 14 + pisid->SubAuthorityCount * 11; > str = LocalAlloc( 0, sz*sizeof(WCHAR) ); > - sprintfW( str, fmt, pisid->Revision, > - pisid->IdentifierAuthority.Value[2], > - pisid->IdentifierAuthority.Value[3], > - pisid->IdentifierAuthority.Value[0]&0x0f, > - pisid->IdentifierAuthority.Value[4]&0x0f, > - pisid->IdentifierAuthority.Value[1]&0x0f, > - pisid->IdentifierAuthority.Value[5]&0x0f); > + sprintfW( str, fmt, pisid->Revision ); > + for( i=2; i<=3; i++ ) > + { > + if( pisid->IdentifierAuthority.Value[i] ) > + printingIdent = TRUE; > + if( printingIdent ) > + sprintfW( str + lstrlenW( str ), identAuthFmt, > + pisid->IdentifierAuthority.Value[i] ); > + } That doesn't look right, you'd need something like %02x for the second value if the first was printed. It seems it would be a lot easier to simply build an int from the various values and then format it with a single %x. -- Alexandre Julliard julliard(a)winehq.org

1 0