June 2013 - Wine-Devel - list.winehq.org

Re: riched20: ITextDocument implementation

by Austin English

On Wed, Jun 26, 2013 at 1:32 AM, Qian Hong <fracting(a)gmail.com> wrote: > Hi, > > Welcome again :) > > On Wed, Jun 26, 2013 at 3:11 PM, Tiger Soldier <tigersoldi(a)gmail.com> wrote: > >> This is my first time to develop WINE. Any comments/suggestions? >> >> [1] http://bugs.winehq.org/show_bug.cgi?id=17042 > > Improving Rich Edit is great appreciated! Interesting, one of GSoC2013 > students Jactry Zeng is planning on implementing ITextDocument as well > [1] [2]. Maybe it is a good idea to work with Jactry together, if that > doesn't violate GSoC rules - actually I don't know, hopefully Austin > English or other GSoC mentor/manager could comment on this. There's nothing preventing someone else from working on the same area of code (we can't control what other people do). However it is still the responsibility of the student to complete their proposal. -- -Austin

June 28, 2013

Re: Need help with a rsaenh bug

by Daniel Jeliński

It is definitely valid to call CryptDecrypt multiple times with the same key. Calls with Final = FALSE change the internal state of the key, calls with Final = TRUE restore the initial state. Subsequent calls with Final = TRUE should return the same result. Your testcase fails because CryptDecrypt changes the value of dwLen, which you do not restore before calling the function again. Regards, Daniel 2013/6/27 Qian Hong <fracting(a)gmail.com> > Hello, > > I was investigating Bug 33898 [1] hardly and get a partial result, I > have a special test case demonstrate the behavior of Aliwangwang [2], > however, I failed to expand the special case to a common test case. My > attempting is shown in [3]. The hack in [3] works for Aliwangwang, but > the test case in [3] doesn't fully pass on Windows as I expected [4]. > > I'm not sure if there is an APP bug rather than Wine bug here, is it > valid to call multiple CryptDecrypt with only one CryptDeriveKey > called? If true, is it correct to assume the second CryptDecrypt call > should behavior identical as the first one? > If there is a Wine bug here, what is the right way to write a common > test case for it? > > Any hints on this bug is great appreciated! > > Thanks very much! > > [1] http://bugs.winehq.org/show_bug.cgi?id=33898 > [2] http://bugs.winehq.org/attachment.cgi?id=44996 > [3] http://bugs.winehq.org/attachment.cgi?id=44997&action=diff > [4] https://testbot.winehq.org/JobDetails.pl?Key=26138 > > -- > Regards, > Qian Hong > > - > http://www.winehq.org > > >

June 27, 2013

Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

by Alan W. Irwin

On 2013-06-26 18:14-0700 Alan W. Irwin wrote: > Note in retrospect I realized that this period leading up to the > release of Wine-1.6.0 has been a lousy time to ask wine developers > with Cygwin expertise to take on the additional distraction of getting > the debugging process for bug 24018 started with the Cygwin > developers. Because of the bad timing from the Wine developer perspective, I asked Arjen Markus, a PLplot colleague of mine with Cygwin contacts, to try and get the debugging process started with the Cygwin developers. The response <http://cygwin.com/ml/cygwin/2013-06/msg00666.html> to his post looks quite promising. It turned out the "fork bomb" test programme failed after only 500 iterations, and the Cygwin developer, Corinna Vinschen thinks she knows what the issue is with more to come. So stay tuned to that thread if you have an interest in bug 24018. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) the Time Ephemerides project (timeephem.sf.net) PLplot scientific plotting software package (plplot.sf.net) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

June 27, 2013

Need help with a rsaenh bug

by Qian Hong

Hello, I was investigating Bug 33898 [1] hardly and get a partial result, I have a special test case demonstrate the behavior of Aliwangwang [2], however, I failed to expand the special case to a common test case. My attempting is shown in [3]. The hack in [3] works for Aliwangwang, but the test case in [3] doesn't fully pass on Windows as I expected [4]. I'm not sure if there is an APP bug rather than Wine bug here, is it valid to call multiple CryptDecrypt with only one CryptDeriveKey called? If true, is it correct to assume the second CryptDecrypt call should behavior identical as the first one? If there is a Wine bug here, what is the right way to write a common test case for it? Any hints on this bug is great appreciated! Thanks very much! [1] http://bugs.winehq.org/show_bug.cgi?id=33898 [2] http://bugs.winehq.org/attachment.cgi?id=44996 [3] http://bugs.winehq.org/attachment.cgi?id=44997&action=diff [4] https://testbot.winehq.org/JobDetails.pl?Key=26138 -- Regards, Qian Hong - http://www.winehq.org

June 27, 2013

Re: widl: Do not generate C structure for empty interfaces. (try 2)

by Jacek Caban

Hi Thomas, I tested what midl does in this case and I think the solution should be different. When I tried to compile an empty interface, I got an error saying that '[object] interface must derive from another [object] interface'. That requirement is mostly enough to avoid empty vtbl. I was wondering how IUnknown is handled by midl (since it doesn't derive from any other iface). It seems like it's a simple name-based special case. When I renamed the interface to IUnknown, it compiled fine and generated vtbl the same as current widl (that is an empty struct). That said, if such interfaces are just obscure special case, I would say we shouldn't care. We may easily avoid them (I just sent a patch avoiding it in mshtml). If you want a better solution to avoid such problems in the future, I would suggest adding an error, like midl does. This will, however, require some more changes in Wine. At least MSHTML already has an interface identical to IUnknown (nsISupports), which would cause the error. This should be solvable with some tricks. Thanks, Jacek

June 27, 2013

Re: widl: Do not generate C structure for empty interfaces.

by Thomas Faber

On 2013-06-26 22:49, André Hentschel wrote: > On 26.06.2013 22:06, Thomas Faber wrote: >> On 2013-06-26 21:47, André Hentschel wrote: >>> The whitespace changes are bad, please don't do that. >> >> Ok, I can take them out no problem. >> Why's it bad though? I thought the rule was "fix it while you're >> working on it anyway". >> > > Mostly because you mess up "git blame" output. > See also http://wiki.winehq.org/SubmittingPatches On 2013-06-26 23:04, Michael Stefaniuc wrote: > Sure, fix the lines you modify and the block you're in. > Avoid having whitespace only diff chunks. Makes sense, thanks. Fixed.

June 27, 2013

Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

by Alan W. Irwin

On 2013-06-26 23:43+0100 Hin-Tak Leung wrote: > --- On Tue, 25/6/13, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote: > > <snipped> >> I currently have no experience with Cygwin and my only real >> interest >> in Cygwin on Wine is it theoretically provides an >> alternative build >> platform to my present successful work with the combination >> of MinGW, >> MSYS, and Wine as a Windows build platform. But I haven't >> even been >> able to get started with Cygwin on Wine because of this >> showstopping >> bug. Therefore, I am mentioning the situation here in the >> hope that >> some wine developer on this list with some knowledge of >> Cygwin will >> take the responsibility of making a proper bug report to the >> Cygwin >> mailing list (which according to http://cygwin.com/problems.html is >> the correct place to report Cygwin bugs) including the >> evidence that >> the issue is a Cygwin regression (assuming investigation of >> older Cygwin >> versions with Turkin's test supports that conclusion). > <snipped> > > FWIW, the fact that cygwin's setup has problems working doesn't not > stop you from *trying* cygwin - it doesn't do very much more than just > unpacking tar.tgz files, which you can do manually. And for many > command-line utilities, just have the exe and the dll around is > enough. One of the disadvantages of MinGW/MSYS as a build platform is you pretty much have to build all your own free software libraries to keep ABI/API consistent. However, it is not too bad because I am automating that process with my "build_projects" project. One of the theoretical advantages of Cygwin as a build platform is access to lots of free libraries that have been built with a consistent "Cygwin" ABI/API. But I would prefer not to implement a replacement for setup.exe that downloads and installs all of those libraries keeping track of all library dependencies. Instead, I would prefer to see bug 24018 fixed so that setup.exe can be used for this task. But that fix will likely require some rather deep knowledge of both Cygwin and Wine. > However, I found that cygwin version of a few utlities does not work > correctly uner wine (it obvious does for some under genuine windows). > While the mingw/gnuwin32 equivalent, do. echo and cat were two I had > problems with, when I accidentally let some 3rd party's installer put > cygwin's cat/echo in front of gnuwin32's cat/echo in my $PATH under > cmd. It's entirely possible that some Cygwin apps don't work correctly under Wine, but that probably depends on both Cygwin and Wine versions. Also, when confirming these issues, it would probably be best to use setup.exe for installation since I doubt any Cygwin developer would trust a Cygwin installation created by anything other than setup.exe. So the current broken setup.exe on Wine is a pretty big barrier to discovering, confirming, and fixing other Cygwin on Wine issues. > Also, I believe MSYS and Mingw do not depends on cygwin. cygwin and > msys/mingw are rather different. For building windows applications, > you really want to stick with mingw if you can. I agree there are big differences between Cygwin and MinGW/MSYS and the former has some extra baggage as a platform that some Windows developers do not like. But I do not mind extra Cygwin baggage at all assuming Cygwin provides a set of free libraries that has a coherent API/ABI. > And, I found cross-compiling works well enough that I don't bother > with having a mingw-based dev system under wine. And if I need MS VC > specifically, that works well under wine so; so there has not been any > need for running mingw or cgywin under wine for a while. I can tell > you from first hand experience that mingw gcc/g++ works well under > wine, but many times slower compared to cross-compiling. I think the > speed problem comes from fork/exec being slow in wine. For me an integral part of package building is package testing. Cross-compilation only does the building part while Wine is quite good for providing both a build and test platform. I do agree with you it is slow compared to the Linux equivalent of the same build and test due to application startup latency issues. My experience is the overall slowdowns are from a factor of two to five depending on how much the build and test timing is dominated by small tasks (i.e., whether the build consist of many compilations of small files or a few compilations of large files and whether the individual tests are short or long.) Apparently Cygwin on the Microsoft version of Windows also has similar issues with fork inefficiency. See the discussion in http://cygwin.com/cygwin-ug-net/highlights.html. So I expect these startup latency issues inevitably occur for any shell environment (such as MSYS's bash.exe) that attempts to fork tasks on Windows. That said, I am happy to accept such build and test slowdowns for MinGW/MSYS or Cygwin on Wine in order to have access to free (in both senses), realistic, and extremely convenient (no dual-booting necessary) Windows build and test platforms. If I ever get inconvenienced by the factors of two to five slowdowns I have seen for typical builds and tests I could always go out and buy a faster computer! :-) Therefore, for free software developers I view MinGW/MSYS on Wine as a pretty ideal build and test platform. I also plan to start trying Cygwin on Wine as a build and test platform as soon as the Cygwin and Wine developers get together and figure out the best way to fix bug 24018. Note in retrospect I realized that this period leading up to the release of Wine-1.6.0 has been a lousy time to ask wine developers with Cygwin expertise to take on the additional distraction of getting the debugging process for bug 24018 started with the Cygwin developers. Therefore, if I don't get any further response now, I will ping about this substantially (a few months) later when times presumably won't be so hectic for Wine developers. In any case I am confident this important bug will eventually be solved because there is obviously a lot of interest (just from the "me too's" in the bug report) in running Cygwin on top of Wine. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net) the Time Ephemerides project (timeephem.sf.net) PLplot scientific plotting software package (plplot.sf.net) the libLASi project (unifont.org/lasi) the Loads of Linux Links project (loll.sf.net) and the Linux Brochure Project (lbproject.sf.net) __________________________ Linux-powered Science __________________________

June 27, 2013

Re: oleaut32/tests: Use bool instead of int when appropriate

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=26136 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

June 27, 2013

Re: oleaut32/tests: Use bool instead of int when appropriate

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=26136 Your paranoid android. === WINEBUILD (build) === Patch failed to apply

June 27, 2013

Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine

by Hin-Tak Leung

--- On Tue, 25/6/13, Alan W. Irwin <irwin(a)beluga.phys.uvic.ca> wrote: <snipped> > I currently have no experience with Cygwin and my only real > interest > in Cygwin on Wine is it theoretically provides an > alternative build > platform to my present successful work with the combination > of MinGW, > MSYS, and Wine as a Windows build platform. But I haven't > even been > able to get started with Cygwin on Wine because of this > showstopping > bug. Therefore, I am mentioning the situation here in the > hope that > some wine developer on this list with some knowledge of > Cygwin will > take the responsibility of making a proper bug report to the > Cygwin > mailing list (which according to http://cygwin.com/problems.html is > the correct place to report Cygwin bugs) including the > evidence that > the issue is a Cygwin regression (assuming investigation of > older Cygwin > versions with Turkin's test supports that conclusion). <snipped> FWIW, the fact that cygwin's setup has problems working doesn't not stop you from *trying* cygwin - it doesn't do very much more than just unpacking tar.tgz files, which you can do manually. And for many command-line utilities, just have the exe and the dll around is enough. However, I found that cygwin version of a few utlities does not work correctly uner wine (it obvious does for some under genuine windows). While the mingw/gnuwin32 equivalent, do. echo and cat were two I had problems with, when I accidentally let some 3rd party's installer put cygwin's cat/echo in front of gnuwin32's cat/echo in my $PATH under cmd. Also, I believe MSYS and Mingw do not depends on cygwin. cygwin and msys/mingw are rather different. For building windows applications, you really want to stick with mingw if you can. And, I found cross-compiling works well enough that I don't bother with having a mingw-based dev system under wine. And if I need MS VC specifically, that works well under wine so; so there has not been any need for running mingw or cgywin under wine for a while. I can tell you from first hand experience that mingw gcc/g++ works well under wine, but many times slower compared to cross-compiling. I think the speed problem comes from fork/exec being slow in wine.

June 26, 2013