wine-devel June 2015

wine-devel@winehq.org

73 participants
265 discussions

Re: [2/3] ntdll: Alter security cookie on WIN64 (try 2)
by Alexandre Julliard 17 Jun '15

17 Jun '15

André Hentschel <nerv(a)dawncrow.de> writes: > This time ARM64-only > I had trouble with that patch for x86_64 when testing EmEditor... > Still it is the only way to get an app on arm64 to start... There shouldn't be any reason to make this platform-specific, or 64-bit specific for that matter. And a hardcoded cookie is not exactly secure... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/3] riched20/tests: Some more EM_SETSEL tests
by Marvin 17 Jun '15

17 Jun '15

2 1

Re: [1/2] Add stub dll d3dcompiler_46
by Matteo Bruni 17 Jun '15

17 Jun '15

2015-06-16 11:14 GMT+02:00 Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com>: > Hi, > > > Changelog: > Add stub dll d3dcompiler_46 > > > Best Regards > Alistair Leslie-Hughes These two patches look fine to me except for the LPJUNK + hungarian notation in DllMain(). BTW where did you find that version number for d3dcompiler_46? Windows 8 SDK? Just curious, I found two different version of d3dcompiler_46.dll bundled with various stuff which have different version numbers (even between them).

2 1

Re: [PATCH 1/4] msvcr120: Add ___lc_locale_name_func implementation
by Marvin 16 Jun '15

16 Jun '15

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 https://testbot.winehq.org/JobDetails.pl?Key=14355 Your paranoid android. === w2008s64 (32 bit msvcr120) === msvcr120.c:209: Test failed: 0 - lc_names[1] = L"en-US" msvcr120.c:206: Test failed: 2 - lc_names[1] = L"zh-CN" msvcr120.c:209: Test failed: 3 - lc_names[1] = L"nl-NL" msvcr120.c:209: Test failed: 4 - lc_names[1] = L"en-US" msvcr120.c:209: Test failed: 5 - lc_names[1] = L"fr-FR" msvcr120.c:209: Test failed: 6 - lc_names[1] = L"de-DE" msvcr120.c:209: Test failed: 7 - lc_names[1] = L"hu-HU" msvcr120.c:209: Test failed: 8 - lc_names[1] = L"is-IS" msvcr120.c:209: Test failed: 9 - lc_names[1] = L"ja-JP" msvcr120.c:209: Test failed: 10 - lc_names[1] = L"ko-KR" msvcr120.c:209: Test failed: 11 - lc_names[1] = L"es-MX" === w2008s64 (64 bit msvcr120) === msvcr120.c:209: Test failed: 0 - lc_names[1] = L"en-US" msvcr120.c:206: Test failed: 2 - lc_names[1] = L"zh-CN" msvcr120.c:209: Test failed: 3 - lc_names[1] = L"nl-NL" msvcr120.c:209: Test failed: 4 - lc_names[1] = L"en-US" msvcr120.c:209: Test failed: 5 - lc_names[1] = L"fr-FR" msvcr120.c:209: Test failed: 6 - lc_names[1] = L"de-DE" msvcr120.c:209: Test failed: 7 - lc_names[1] = L"hu-HU" msvcr120.c:209: Test failed: 8 - lc_names[1] = L"is-IS" msvcr120.c:209: Test failed: 9 - lc_names[1] = L"ja-JP" msvcr120.c:209: Test failed: 10 - lc_names[1] = L"ko-KR" msvcr120.c:209: Test failed: 11 - lc_names[1] = L"es-MX"

1 0

Re: Wine developer frustration (was Re: ntdll: Improve stub of NtQueryEaFile.)
by Jeremy White 16 Jun '15

16 Jun '15

Hi all, On 06/15/2015 02:32 PM, Michael Müller wrote: > Hi Jeremy, > > I actually intended to send the following response to wine-devel, but > the other Wine Staging developers feared that this might continue the > flamewar. Nevertheless, I think the ideas should still reach you, just > treat them as my personal opinion. In case you are comfortable with the > content, feel free to forward or respond to it on wine-devel. I thought these were all interesting points, and wanted to respond publicly. > > I think it is too easy to blame Alexandre for all Wine problems. He is > involved in some of them, but there are also other ways to improve Wine > which are completely unrelated to him. I think even CodeWeavers could > make Wine more community-friendly simply by being more transparent. > > Here are two examples of what I mean: > > 1. CodeWeavers adds a lot of hacks to Crossover to get applications to > work, in case a proper fix would be too much work. From what I have > heard those hacks are only added after the problem has been analyzed and > documented in your bug tracker. I don't understand though why no one in > the Wine community access to this analysis (i.e. why are these bugs not > documented in the public bug tracker)? It seems to be a waste of energy > if the Wine community needs to debug the problem a second time. I think that breaks down into two issues. First, yes, we do have hacks in CrossOver, but I think 'a lot' is unfair. We really try to avoid those hacks, and we work hard to eliminate them. For example, I reviewed our tracker that lists our hacks. We have about 100 outstanding; in the last 6 months, we removed 4 with upstream fixes, and added 1 new one. Further, we have long felt that our diff with winehq was tragically large. But nicely, I can now compare it to wine-staging, and claim that it is relatively modest <grin>. We touch 28K lines in 228 files versus 100K lines in 509 files for wine-staging [1]. Second, for bugs, yes, we do have our own bug tracker, and it is (mostly) private. That's appropriate for CrossOver only bugs, and we do have a lot of customers with whom we have confidentiality agreements, so it's necessary in that case. We do have an official company policy that any Wine related bug in our tracker is supposed to have a related WineHQ bug, and we are supposed to bias our troubleshooting and work in favor of WineHQ. That is true for all bugs, including ones that are hacks. In doing a spot check of that, it looks like we don't do that great a job of adhering to that policy; maybe 30% of the time (although we do have a number of staff members who are particularly good at mostly using WineHQ). I have to agree that this is arguably less than ideal, and I will exhort our staff to do better. But my gut sense is that the perception may be that we have this magical treasure trove of extra information, and the reality is fairly far from that. > > 2. CodeWeavers seems to act like a black box from my point of view. It > is not really clear what you guys are working on and therefore a lot of > Wine developers (who are not part of CW) try to avoid touching the same > areas of Wine. As far as I know CW is currently working on Office 2013 > for example, but there is not a single bug in the WineHQ bug tracker > about this. On the other hand I talked with some CW developers on the > IRC and I had the impression that they wouldn't mind help from the > community to fix certain issues. We all profit from having those bugs > fixed faster. Ouch. I'm not sure how to respond to that. I think we've been accused of being a bit opaque in the past, and I think I've promised to try to do better. Looks like I failed. We do tend to get a lot of NDAs and things that make us careful with information, but we also just have a lot of the strong silent types on staff. But the very last thing I want to do is suppress any work on Wine. My thinking, though, has long been the opposite of yours. That if we advertise an area of work, we risk a 'chilling' effect. There are far more bugs with 'Office' than we could ever handle by ourselves; I would never want someone to stay away from a bug that looked interesting or fun, just because we tend to do a lot of the work on Office. I always thought the perk of being a non CW Wine hacker is that you get to pick and choose the fun parts. I get to make the CW hackers do the yucky, nasty, stuff... <evil grin>. Further, we really do just about all of our work on wine-devel; you can tell what we're working on just by seeing the patches there. For the record, we are working on Office 2013, which is right now mired in a lot of work on dwrite, I believe. If you look at Henri and Nikolay's recent patches, you'll see the work on it. We have lovely purple blobs in Excel instead of readable text (although I'm told I can have those blobs in any color I like). Beyond that, our work is all over the map. I guess the action item here remains the same - for us to do a better job of communicating, so we no longer seem mysterious or opaque. I'll work on that. > > Alexandre needs to find a way how to improve the patch acceptance > process in a way he feels comfortable with, but before everyone starts > blaming him for all problems, there are also other areas which can be > improved. Don't get me wrong, I don't want to say that CW is root of all > evil (I think its very great that you guys keep Wine alive), I just > thought you might be interested in these ideas, especially because these > are things where you have influence on. Yes, thank you - this is very helpful. I think there is clearly a problem, a problem that has gotten worse lately, and it would be great if we can find a way to improve matters. Again, there is far more than enough work to do; to lose any energy to misunderstanding or inter personal friction is just stupid and inefficient. One issue you didn't raise that I want to elevate as a straw man, and then knock down, is the perception that an @codeweavers.com email address is some sort of guarantee of patch acceptance. Trust me, I am painfully aware that it doesn't help :-/. It is true that I tend to hire people that Alexandre trusts (which makes sense, if you think about it), but that's a different way of coloring the situation. And I can tell you that Alexandre is a man of deep integrity, and he is both personally committed to keeping his work on Wine separate from his work for CodeWeavers, and CodeWeavers is contractually bound to allow that. > > Not directly related to the previous mail, but I think its not > sufficient to hope that WineConf will automatically solve all problems. > The WineConf might be a good place to discuss individual ideas, but we > may want to start collecting them in advance. Agreed; hence my desire to make sure to get this down in the email archives as well, and my hope that we can articulate the concerns and possible improvements now as well. But there is something really powerful about meeting face to face that is very nice. It's particularly nice when you can go to the bar to curse Alexandre over beers later <grin>. Cheers, Jeremy [1] This was my methodology, which may be flawed: wine-staging git, removing outsized fonts-Missing_Fonts patch: [~/xfer/wine-staging/patches] grep -h '^diff' */00*.patch | sort | uniq | wc -l 509 [~/xfer/wine-staging/patches] cat */00*.patch | wc -l 107666 CrossOver stats: [~/w/crossover/wine] git diff wine-1.7.45 | grep -h '^diff' | wc -l 228 [~/w/crossover/wine] git diff wine-1.7.45 | wc -l 28388

1 0

Re: ntdll: Improve stub of NtQueryEaFile.
by Alexandre Julliard 16 Jun '15

16 Jun '15

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Based on a patch by Qian Hong. I don't remember seeing any such patch. Qian is around, so I expect he should be able to submit his own work himself. Then you can submit your part as your own separate patch. It's not a big deal for a small patch like this, but I don't want you to get into the habit of submitting patches containing bits and pieces of other people's work. I expect developers to stand behind their work, and take responsibility for getting their patches committed. Helping them is good, but taking over their work isn't. -- Alexandre Julliard julliard(a)winehq.org

15 26

Re: scrrun: Implement ITextStream Close
by Marvin 16 Jun '15

16 Jun '15

1 0

Re: [1/2] ntdll: Set platform register x18 to TEB on ARM64 (resend)
by Alexandre Julliard 16 Jun '15

16 Jun '15

André Hentschel <nerv(a)dawncrow.de> writes: > @@ -788,6 +788,17 @@ void signal_free_thread( TEB *teb ) > > > /********************************************************************** > + * set_x18 > + * > + * Win64/ARM applications expect the TEB pointer to be in the x18 platform register. > + */ > +extern void set_x18( TEB *teb ); > +__ASM_GLOBAL_FUNC( set_x18, > + "mov x18, x0\n\t" /* TEB -> platform register */ > + "ret" ) You don't really need a global function for this. -- Alexandre Julliard julliard(a)winehq.org

1 0

odbccp32: Implement SQLGetPrivateProfileString (try 5)
by Hugh McMaster 16 Jun '15

16 Jun '15

On Sun, 14 Jun 2015 14:58:36 +1000, Alistair Leslie-Hughes wrote: > >+ ret = SQLGetPrivateProfileStringW(sect, entry, string, retval, cbRetBuffer, file); >+ if(ret) >+ { >+ WideCharToMultiByte(CP_ACP, 0, retval, -1, RetBuffer, cbRetBuffer, NULL, NULL); >+ RetBuffer[ret] = 0; >+ } If retval is null terminated, you do not need RetBuffer[ret] = 0;. The -1 in WideCharToMultiByte means the function calculates the length of the input string, including any null terminating character. If the input string is null terminated, the output string is also null terminated. So, if this is the case, you are actually null-terminating twice and, depending on the size of cbRetBuffer, the second null termination may be out of bounds. If retval isn't null terminated, you should use the return value of WideCharToMultiByte (the number of bytes written to RetBuffer) instead of 'ret'.

1 0

Re: scrrun: Implement ITextStream Close
by Nikolay Sivov 16 Jun '15

16 Jun '15

> struct textstream *This = impl_from_ITextStream(iface); > - FIXME("(%p): stub\n", This); > - return E_NOTIMPL; > + HRESULT hr = S_OK; > + > + TRACE("(%p)\n", This); > + > + if(!CloseHandle(This->file)) > + hr = S_FALSE; > + > + This->file = NULL; > + > + return hr; This could be right way to do it, but it would be interesting to see what happens to other methods behavior when called on closed stream, like Read() for example.

2 1

← Newer
1
...
11
12
13
14
15
16
17
...
27
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel June 2015