[Fwd: Re: msi patch submission - cond.y]
I may be wrong, but I feel it might be useful for a naive outsider to enter this discussion, even if it does mean I get burnt to a crisp. I'm neither a Wine nor a parser developer (though I do have a few years C/++ experience) and fully accept that I may be flamed to a tiny cinder for my comments, but from what I can ascertain, cond.y is a composite file, containing C and bison code. As far as I can tell (not quite brave enough to say AFAICT) the file is first read by the bison processor, which reads the bison parser rules and C code and generates compilable files for the C compiler. Having read what bison is (I think) supposed to do, the tokens declared DO look is if they might be wrong [having looked up 'tilde' and MSI on Google, it looks as though COND_I* actually relates to strings, as it seems that the tilde means 'case insensitive', but I wonder if it has been inadvertently used on integer comparisons by some installers]. It also looks as if the tests in compare_int() for COND_LE and COND_ILE may be wrong, unless there is some kind of (uncommented) logic inversion somewhere. However, uppermost in my mind is Mike McCormack's statement that 'Unfortunately cond.y has nothing to do with SQL.'. If this is indeed the case then everything I have said amounts to nought because I have assumed (very likely incorrectly) that the parser code in cond.y, being part of the MSI dll, relates to the parsing of SQL statements in MSI. If this is the case I fully expect to burn in newbie-land, and apologise for my presumption. Torch me if you want. Just trying to help, and open the discussion :) --- Begin Message --- I may be wrong, but I feel it might be useful for a naive outsider to enter this discussion, even if it does mean I get burnt to a crisp. I'm neither a Wine nor a parser developer (though I do have 14 years C/++ experience) and fully accept that I may be flamed to a tiny cinder for my comments, but from what I can ascertain, cond.y is a composite file, containing C and bison code. As far as I can tell (not quite brave enough to say AFAICT) the file is first read by the bison processor, which reads the bison parser rules and C code and generates compilable files for the C compiler. Having read what bison is (I think) supposed to do, the tokens declared DO look is if they might be wrong [having looked up 'tilde' and MSI on Google, it looks as though COND_I* actually relates to strings, as it seems that the tilde means 'case insensitive', but I wonder if it has been inadvertently used on integer comparisons by some installers]. It also looks as if the tests in compare_int() for COND_LE and COND_ILE may be wrong, unless there is some kind of (uncommented) logic inversion somewhere. However, uppermost in my mind is Mike McCormack's statement that 'Unfortunately cond.y has nothing to do with SQL.'. If this is indeed the case then everything I have said amounts to nought because I have assumed (very likely incorrectly) that the parser code in cond.y, being part of the MSI dll, relates to the parsing of SQL statements in MSI. If this is the case I fully expect to burn in newbie-land, and apologise for my presumption. Torch me if you want. Just trying to help, and open the discussion :) On Mon, 2006-06-05 at 09:02 -0500, EA Durbin wrote: > Then what are the conditional statements in cond.y used for? Though they may > not be SQL errors, if IGE and ILEmeans IS Greater than or equal to, or Is > Less than or Equal to then it's still and error, even if it doesn't pertain > to SQL. > > Do these not mean IS Greater than or equal to, or Is Less than or Equal to ? > > > > >From: Mike McCormack <[EMAIL PROTECTED]> > >To: wine-devel@winehq.org > >CC: [EMAIL PROTECTED] > >Subject: Re: msi patch submission - cond.y > >Date: Mon, 05 Jun 2006 22:43:09 +0900 > > > > > >EA Durbin wrote: > >>fixed various SQL errors in COND_GetOperator() and compare_int() > > > >Unfortunately cond.y has nothing to do with SQL. > > > >Mike > > > > > --- End Message ---
Re: msi patch submission - cond.y
I may be wrong, but I feel it might be useful for a naive outsider to enter this discussion, even if it does mean I get burnt to a crisp. I'm neither a Wine nor a parser developer (though I do have 14 years C/++ experience) and fully accept that I may be flamed to a tiny cinder for my comments, but from what I can ascertain, cond.y is a composite file, containing C and bison code. As far as I can tell (not quite brave enough to say AFAICT) the file is first read by the bison processor, which reads the bison parser rules and C code and generates compilable files for the C compiler. Having read what bison is (I think) supposed to do, the tokens declared DO look is if they might be wrong [having looked up 'tilde' and MSI on Google, it looks as though COND_I* actually relates to strings, as it seems that the tilde means 'case insensitive', but I wonder if it has been inadvertently used on integer comparisons by some installers]. It also looks as if the tests in compare_int() for COND_LE and COND_ILE may be wrong, unless there is some kind of (uncommented) logic inversion somewhere. However, uppermost in my mind is Mike McCormack's statement that 'Unfortunately cond.y has nothing to do with SQL.'. If this is indeed the case then everything I have said amounts to nought because I have assumed (very likely incorrectly) that the parser code in cond.y, being part of the MSI dll, relates to the parsing of SQL statements in MSI. If this is the case I fully expect to burn in newbie-land, and apologise for my presumption. Torch me if you want. Just trying to help, and open the discussion :) On Mon, 2006-06-05 at 09:02 -0500, EA Durbin wrote: > Then what are the conditional statements in cond.y used for? Though they may > not be SQL errors, if IGE and ILEmeans IS Greater than or equal to, or Is > Less than or Equal to then it's still and error, even if it doesn't pertain > to SQL. > > Do these not mean IS Greater than or equal to, or Is Less than or Equal to ? > > > > >From: Mike McCormack <[EMAIL PROTECTED]> > >To: wine-devel@winehq.org > >CC: [EMAIL PROTECTED] > >Subject: Re: msi patch submission - cond.y > >Date: Mon, 05 Jun 2006 22:43:09 +0900 > > > > > >EA Durbin wrote: > >>fixed various SQL errors in COND_GetOperator() and compare_int() > > > >Unfortunately cond.y has nothing to do with SQL. > > > >Mike > > > > >
Re: Why winetools is utterly useless, once and for all.
On Mon, 2006-03-27 at 21:32 -0500, Segin wrote: > There is one reason, inarguable (if you reply to this you have a IQ > of > 0) as to why WineTools is useless: Most of the WineTools 'magic' is > in > it's ~/.wine/config file, which Wine no longer uses/acknoleges, > thefore, > WineTools is utterly useless and has no point in existing AT ALL, > PERIOD. Thought it might be interesting to refer back to the email that kicked all of this off and try to look at it in detail. > There is one reason, inarguable Anything is arguable, if one has arguments that can be backed up with evidence. > (if you reply to this you have a IQ of 0) Everyone has an IQ of more than 0. If they didn't, it is unlikely they would be able to read and so would not be in a position to respond. I also believe that anyone who reads this list has demonstrated a remarkable degree of intelligence in trying to move as far away from Windows as possible. The inference of this statement seems to be 'I am right because I am. I deny you the right to disagree - if you do I have already marked you out as an imbecile and you are not worthy of any consideration' - sounds rather fascist to me. > as to why WineTools is useless. I have used Winetools when necessary, when there was no other easily available option. IE is required for me to use online banking. I have complained to my bank, and asked them to support FireFox and they have declined. Winetools helped me achieve what I needed. For my specific needs, winetools was useful. > Most of the WineTools 'magic' Implication by use of quotation marks - winetools claims to be magic. It does not, as far as I know. > is in it's ~/.wine/config file, which Wine no longer uses/acknoleges, Ignoring the poor spelling and concentrating on the details, I have used versions of winetools that supported the config file, and more recently, versions that support the newer registry configuration. Given my understanding of current wine configuration I think the statement may be misleading. If I am wrong, I am happy to be corrected, preferably in a private email. >WineTools is utterly useless and has no point in existing AT ALL, >PERIOD. I have already described at least one reason for it to exist. Shouting isn't necessary, but if it makes segin feel better, that's entirely up to him. The point of this email is not to argue as to whether winetools is good for Wine or not - I can see both sides of the argument. Neither do I believe that any form of banning is necessary. I'm opposed to censorship generally, and given that no individual attack was made such sanctions could be counterproductive, given that segin has offered to submit code to wine in the future. All I can suggest is that when individuals have an opinion they believe strongly in, perhaps it might be a good idea to read though any open message they send before hitting 'Send' to see if it is readable and stands up to rational criticism. I have the greatest of respect for the entire wine community (no exceptions) and know that with rational debate and argument wine will be a huge (maybe the biggest) factor in ending the Windows monopoly.
Re: Licensing question
Thanks for identifying the relevant part of the license, and for clarifying the situation wrt separate DLLs. Very helpful. I'll give the rest of the license a good read for future reference. Dominic On Wed, 2006-01-04 at 09:53 -0800, Daniel Remenak wrote: > Dan Kegel is correct. You can create a DLL containing LGPL code and > load it from a proprietary application, as long as the source to the > DLL is distributed. > > >From the LGPL Preamble: > > "This license, the GNU Lesser General Public License, applies to > certain designated libraries, and is quite different from the ordinary > General Public License. We use this license for certain libraries in > order to permit linking those libraries into non-free programs. > > "When a program is linked with a library, whether statically or using > a shared library, the combination of the two is legally speaking a > combined work, a derivative of the original library. The ordinary > General Public License therefore permits such linking only if the > entire combination fits its criteria of freedom. The Lesser General > Public License permits more lax criteria for linking other code with > the library." > > --Daniel Remenak > > On 1/4/06, Dominic Wise <[EMAIL PROTECTED]> wrote: > > Hmmm... I thought from Dan Kegel's earlier response that it would be OK > > to put the function into a separate library (DLL) and release this > > library under a separate license to the rest of the application. It's a > > pity if this is not permissible. > > > > Anyone else have any thoughts on this? The 'inspiration' route seems > > like cheating to me. I would much rather simply use the Wine code in a > > way that is compatible with the LGPL, if this is possible. If not, I > > probably just won't tell the developer working on this where to find the > > Wine code. > > >
Re: Licensing question
On Wed, 2006-01-04 at 17:00 +0100, Andreas Mohr wrote: > Hi, > > On Wed, Jan 04, 2006 at 03:29:22PM +, Dominic Wise wrote: > > I have a question regarding the use of portions of Wine in a commercial > > application. Sorry if this is not the right place to post but I am not > > sure who I can directly address this to. > np (I don't think wine-users would be an appropriate place for such a > specific question) > > > The application my employer develops is a financial application designed > > to work on Win 2K and Win XP, but we have a need for a Win32 function > > that is only supported in XP (TzSpecificLocalTimeToSystemTime). We could > > write an implementation of this function ourselves for Win 2K but I have > > noticed that there is a full implementation in Wine. > Are you sure this is the only Win32 API with this exact functionality? > There might be a good reason why it's been introduced at such a late date > as XP+ only... > > cd wine; find . -name "*.spec"|xargs grep -i time.*time Pretty sure it's the only one. Not sure why it was added later. Maybe there wasn't demand for it until XP came about. > > > Is it permissible to use the source for this function in our > > application? If so, what provisions do we need to make with regard to > > recognition of Wine and supply of source code to our customers ? > Err... no. (at least not directly) > > While Wine's license (LGPL) allows linking to Wine components, it still > carries the same restrictions as the GPL license when it comes to directly > integrating such code in closed-source programs. > > However I think(!) that it's legally valid to gather some "inspirations" > from such code if absolutely needed and then write your own implementation > of this function, much preferrably by first looking at the code and then, > completely isolated, writing your own quite different code. > (anybody please correct me NOW if this is fatally incorrect!) > But I'm afraid the best way to avoid license violations is to code this > function without looking at the (L)GPL'd implementation of this algorithm, > if possible. > > Another way *might* be to ask the original author of this function > (see CVS logs) whether he permits you to use his *original*, *unpatched* > version of this function. > > BTW, if you absolutely want to directly use Wine-related code in a > commercial (or, to be exact: proprietary) application, then may I direct you > to http://de.wikipedia.org/wiki/ReWind ? > This is a source tree mostly consisting of the old Wine codebase before the > MIT -> LGPL license change. > Problem is that rewind is too old to already contain an implementation of > TzSpecificLocalTimeToSystemTime(). > Hmmm... I thought from Dan Kegel's earlier response that it would be OK to put the function into a separate library (DLL) and release this library under a separate license to the rest of the application. It's a pity if this is not permissible. Anyone else have any thoughts on this? The 'inspiration' route seems like cheating to me. I would much rather simply use the Wine code in a way that is compatible with the LGPL, if this is possible. If not, I probably just won't tell the developer working on this where to find the Wine code. > > I am currently trying to demonstrate the benefits of Open Source > > technology to my employer (I have already replaced one proprietary > > third-party component in our application with a better Open Source > > implementation) and this could really help to move this process along. > Nice! (hopefully code that uses a license that's compatible with proprietary > applications, though) > They are a bit wary at the moment but the more benefits they see the easier it will become. Hope I'm OK on this one :- The program I am using (Open Object Rexx) is licensed under the CPL. The FAQ for the CPL suggests to me that it's OK to modify it and incorporate it into a proprietary application. In any case, its actually under beta testing in a development version of our application so it's not a disaster if licensing issues prevent it from making it into the a general release. > > Longer-term, I want to try and get the application running on Wine, but > > that's another story. > ...preferrably by fixing Wine bugs if there are any, instead of adding > Wine workarounds to the application. :) > Of course! > Andreas Mohr > Dominic Thanks, Dominic
re: Licensing question
On Wed, 2006-01-04 at 07:44 -0800, Dan Kegel wrote: > [EMAIL PROTECTED] wrote: > > The application my employer develops is a financial > > application designed to work on Win 2K and Win XP, but we > > have a need for a Win32 function that is only supported in > > XP (TzSpecificLocalTimeToSystemTime). We could write an > > implementation of this function ourselves for Win 2K but > > I have noticed that there is a full implementation in Wine. > > > > Is it permissible to use the source for this function in > > our application? > > That function, along with all of Wine, is LGPL'd. Thus to use > it in a proprietary app, you just have to put it in its own DLL. > > > If so, what provisions do we need to make > > with regard to recognition of Wine and supply of source > > code to our customers ? > > You need to provide the source code for the LGPL'd DLL you ship. > Have a look at the terms of the LGPL for details: > http://www.gnu.org/copyleft/lesser.txt > > Good luck with your project! > - Dan > > -- > Wine for Windows ISVs: http://kegel.com/wine/isv > Exactly what I was hoping for. Many thanks. Dominic
Licensing question
I have a question regarding the use of portions of Wine in a commercial application. Sorry if this is not the right place to post but I am not sure who I can directly address this to. The application my employer develops is a financial application designed to work on Win 2K and Win XP, but we have a need for a Win32 function that is only supported in XP (TzSpecificLocalTimeToSystemTime). We could write an implementation of this function ourselves for Win 2K but I have noticed that there is a full implementation in Wine. Is it permissible to use the source for this function in our application? If so, what provisions do we need to make with regard to recognition of Wine and supply of source code to our customers ? I am currently trying to demonstrate the benefits of Open Source technology to my employer (I have already replaced one proprietary third-party component in our application with a better Open Source implementation) and this could really help to move this process along. Longer-term, I want to try and get the application running on Wine, but that's another story. Regards, Dominic
Re: Wine IE6 and JVM
On Thu, 2005-12-15 at 17:38 +0200, Adrian Munteanu wrote: > Hi guys, > > I am trying to use wine with IE 6. > Most of the pages are displaying fine, however the problem is with pages > requesting JVM running. > So could you please help me find away, if available, to make IE use > installed JVM? > > Thanks and best regards > Adrian > > > Have you tried latest winetools? I ask because it worked for me with IE6 .It has been updated to the 0.9 wine version. Hope this helps, Dom
Re: [lostwages] Remove winetools from download page
On Thu, 2005-12-22 at 09:43 +0100, [EMAIL PROTECTED] wrote: > On Thu, 22 Dec 2005 02:59:57 +0100, Tom Wickline <[EMAIL PROTECTED]> > wrote: > > > On 12/21/05, James Hawkins <[EMAIL PROTECTED]> wrote: > >> > >> As much as I appreciate the work you, Joachim, and others have put > >> into winetools, we're getting closer to the point in time when > >> winetools needs to be phased out by a better, more functional wine. > > Getting closer, sure, but it's not for tommorow As someone coming from a Windows (professionally at least, Linux at home) background I have to say that making it harder to install programs by dropping the link to winetools, given the known, current limitations of Wine, could completely undo all of the efforts of the last 10 years. One thing to remember is that 'Windows users are stupid'. Of course, I don't mean that literally; rather, anyone considering a switch to Linux is going to want to see some hard proof that their Windows programs might work. If they just get a crash (or a 'go to irc at etc') they will give up immediately. I have seen some very sensible comments suggesting that once Wine reaches 1.0 then THAT is the time to drop references to winetools. > >> Part of this process is removing it from the official download page. > > Part of this process "will be" removing winetool link. "is" implies the > present and we are not at this stage with wine yet. > Agreed > > > > Shouldn't Wine be fixed before it's removed? Isn't it kind of backwards > > to say > > we need to have Wine run everything out of the box and to accomplish > > this were > > going to remove a link to a user friendly tool that currently helps our > > users. I agree completely > > > I agree, I think there has to be an easy start method with at least half a > chance of getting things running. > > Most new users , many probably new to linux as well will NOT even be aware > of what an IRC channel is an probably never met a maiing list either. > > It seems some of the ppl posting on this thread dont even realise that > they are living on a different plane to those actually using wine. > > If new users cant get some positive result quickly they will just conclude > that wine is unusable, and from an average user point , they would be > right. > See above > If they can be hooked by getting somethings to work they _may just_ go a > bit further with some things that dont. Hell , they may even read the doc > if they can find it. > As for argueing that bugs wont get reported. I was not aware that there > was a shortage of things to do in fixing Wine. > ing 'please look here > > If Wine scares off new users by expecting everyone to be a software > developer it will fail in it's primary role of helping users to migrate to > Linux. Could not agree more. Wine needs to 'get it right for the users ', even if that involves occasionally saying 'please look here; we like you and we want to keep you here'. Fixing bugs is the devs job, not the end user's job, yes? > > regards. > > > > >
