wine-devel May 2006

wine-devel@winehq.org

151 participants
288 discussions

SoC idea: write OLE32 and OLEAUT32 conformance tests
by Dan Kegel 07 May '06

07 May '06

Yes, SoC is usually about coding new stuff rather than writing conformance tests, but here's a situation where we badly need more conformance tests *and* the tests are a real challenge to write. Rob Sherman, who is one of the OLE code maintainers, remarked recently that we could really use more test cases for part of COM/OLE: http://www.winehq.org/pipermail/wine-devel/2006-May/047401.html Many apps have OLE problems; the query http://bugs.winehq.org/buglist.cgi?long_desc_type=substring&long_desc=err:o… finds 109 hits. Maybe a third of these are really OLE problems that could be repeated by conformance tests. (I think http://bugs.winehq.org/show_bug.cgi?id=4073 http://bugs.winehq.org/show_bug.cgi?id=4776 are good examples.) Writing COM or OLE Automation tests in C is hard - the documentation you need is in old books that are hard to find. But it's doable given a couple weeks. There are a few links to writing COM in C at: http://www.winehq.org/pipermail/wine-devel/2006-April/046191.html http://www.sellsbrothers.com/links/ http://members.tripod.com/IUnknwn/ And there are several old books (a few of which I have copies of) which are also useful references. This is probably a great project for someone who's really comfortable with pointers and low level stuff. Once the tests you write pass on Windows and find bugs in Wine, the guys who write COM for Wine will fix the bugs, I think. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

wine opengl bug & Google SoC
by gamemaker＠tlen.pl 06 May '06

06 May '06

Hi! I would like to participate in Google summer of code. I'm going to fix popular opengl problem in wine - overdrawing of child windows (http://bugs.winehq.org/show_bug.cgi?id=2398). What do you think about it? Have this project any chance to get apply? Isn't it to small?

1 0

Two more days to submit a Wine SoC proposal...
by Dan Kegel 06 May '06

06 May '06

There have been very few junk SoC applications for Wine so far, so our plan of scaring away unqualified applicants by making http://wiki.winehq.org/SummerOfCode explicit about the requirements for success seems to be working. At the moment, we have some good applications, but we can handle more. So if you've been holding off proposing a Summer of Code project because you think there will be too many competing proposals, think again, and go submit a proposal for that project you've been hoping to do. (But be specific; a one-line proposal "Get game XYZ working in Wine" is less likely to win than one that also gives more details about how you'll do that.) - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

forked wineboot (IE6)
by Saulius Krasuckas 06 May '06

06 May '06

Such topic may belong to wine-users, but I am not sure. When installing IE6 (from my own script) I see wineboot is being forked and gets running right after the "./wine IE6SETUP.EXE /q" statement returns me a control. I would like to wait untill "wineboot" finishes. How it can be achieved in my bash script? Maybe wineboot can be set to not fork? (though I don't know if "fork" is right term to use here)

2 2

Re: [WINED3D 1/8] Place number of textures/addresses and temps used inside the baseShader struct to prepare for merging of GenerateShader routine.
by Jason Green 06 May '06

06 May '06

On 5/5/06, Ivan Gyurdiev <ivg2(a)cornell.edu> wrote: > Merging things between pixel and vertex shaders is the right idea, but > we need to think about supporting multiple output targets as well - > arbfp/arbvp vs glsl. Any shader_addline() being called is output target > specific. Yes, you are correct, and I'm already working on a patch to address this. However, I think this patch should still be applied as-is, since it doesn't break anything currently and is organized so as to make this separation easy in the [very near] future.

1 0

Re: [WINED3D 8/8] Add TRACE output of full shader strings for both pixel and vertex shaders
by Jason Green 06 May '06

06 May '06

On 5/5/06, Ivan Gyurdiev <ivg2(a)cornell.edu> wrote: > > I think we should do the opposite, and get rid of the one that's already > there. > > The shader output is already produced once by the addline traces, and > they're better because (1) they have proper trace prefix, and (2) they > show you the line number and byte offset. You can use sed and grep to > get only those lines, or better, remove any useless tracing such as > printing out individual tokens as they're parsed [ then the > shader_addlines would come nicely in a sequence ]. After discussion, I agree. Please discard this patch.

1 0

OT: just a greeting
by Joris Huizer 05 May '06

05 May '06

Hey, seeing you emailing again Alexandre Julliard, welcome back, hope you enjoyed your vacation :-) regards, Joris

1 0

Re: Fix cross compiling 2/2 [take #2]
by Alexandre Julliard 05 May '06

05 May '06

Paul Millar <paul(a)astro.gla.ac.uk> writes: > The current behaviour is broken as, when cross-compiling, make traverses in= > to > the tools directory and tries to build the various programs. This is wrong > because the tools in in the --with-wine-tools directory are used, not those > tools that are cross-compiled, so there is no dependency. That's a feature, otherwise the tools don't get built, and we don't spot problems. The tools are supposed to build fine on Windows, and if they don't, this needs to be fixed. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: advpack [6/17]: NULL-terminate the field string if an option is provided
by Alexandre Julliard 05 May '06

05 May '06

"James Hawkins" <truiken(a)gmail.com> writes: > diff --git a/dlls/advpack/install.c b/dlls/advpack/install.c > index 6432406..93d8012 100644 > --- a/dlls/advpack/install.c > +++ b/dlls/advpack/install.c > @@ -101,9 +101,17 @@ static HRESULT run_post_setup_commands_c > ADVInfo *info = (ADVInfo *)arg; > INFCONTEXT context; > HRESULT hr = S_OK; > + LPWSTR ptr; > DWORD size; > + BOOL ok; > > - BOOL ok = SetupFindFirstLineW(hinf, field, NULL, &context); > + if ((ptr = strchrW(field, ':'))) > + { > + FIXME("Options ignored!\n"); > + *ptr = '\0'; > + } field is a constant string, you shouldn't write to it (or if it's really supposed to be writable you need to fix the prototype). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: server: Retrieve the groups for a token from the server
by Alexandre Julliard 05 May '06

05 May '06

Robert Shearman <rob(a)codeweavers.com> writes: > +tryagain: > + SERVER_START_REQ( get_token_groups ) > { > - TOKEN_GROUPS *tgroups = tokeninfo; > - SID_IDENTIFIER_AUTHORITY sid = {SECURITY_NT_AUTHORITY}; > + TOKEN_GROUPS *groups = tokeninfo; > > - /* we need to show admin privileges ! */ > - tgroups->GroupCount = 1; > - tgroups->Groups->Attributes = SE_GROUP_ENABLED; > - RtlAllocateAndInitializeSid( &sid, > - 2, > - SECURITY_BUILTIN_DOMAIN_RID, > - DOMAIN_ALIAS_RID_ADMINS, > - 0, 0, 0, 0, 0, 0, > - &(tgroups->Groups->Sid)); > + req->handle = token; > + wine_server_set_reply( req, buffer, server_buf_len ); > + status = wine_server_call( req ); > + if (status == STATUS_BUFFER_TOO_SMALL) > + { > + if (buffer == stack_buffer) > + buffer = RtlAllocateHeap(GetProcessHeap(), 0, reply->user_len); > + else > + buffer = RtlReAllocateHeap(GetProcessHeap(), 0, buffer, reply->user_len); > + if (!buffer) return STATUS_NO_MEMORY; > + > + server_buf_len = reply->user_len; > + goto tryagain; You shouldn't return or goto out of a SERVER_START_REQ block. SERVER_END_REQ currently doesn't do much, but that could change. -- Alexandre Julliard julliard(a)winehq.org

1 0

← Newer
1
...
21
22
23
24
25
26
27
28
29
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 May 2006