January 2007 - Wine-Devel - list.winehq.org

Re: winex11: Use GLXFBConfig for the pixel format list

by Roderick Colenbrander

-------- Original-Nachricht -------- > > TRACE(" make current for dis %p, drawable %p, ctx %p\n", > gdi_display, (void*) drawable, ctx->ctx); > > + X11DRV_expect_error(gdi_display, error_catcher, NULL); > > ret = pglXMakeCurrent(gdi_display, drawable, ctx->ctx); > > + X11DRV_expect_error(gdi_display, NULL, NULL); > > NtCurrentTeb()->glContext = ctx; > > if(ret) > > { > Can you explain this one a bit? Your error_catcher() does nothing, > except ignoring the error. Yet here you assuming that calls succeeded > and continue on, assigning the context to a thread which won't have the > context assigned. > > Vitaliy. > Please don't try to catch any error like a BadMatch which can appear there. It is easier if it really appears there to warn us instead of failing just to the windows app. Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Jan. 1, 2007

Re: Wine 32-bit address space

by Alexandre Julliard

"Nick Burns" <adger44(a)hotmail.com> writes: > The range 3GB (0xC0000000) - 4GB (0xFFFFFFFF) is considered system > memory and apps should not write here (not sure why you would want to > read from there either). > > But Wine tries to mmap this range (on Mac OSX at least) > > I was wondering why this is? > Should this range just be left as it is? -- is there a reason to mmap > this range? Yes, it's to prevent things like builtin libraries from being mapped there, since it's a range the Window apps don't expect to see. -- Alexandre Julliard julliard(a)winehq.org

Jan. 1, 2007

Wine 32-bit address space

by Nick Burns

According to http://msdn2.microsoft.com/en-gb/library/aa366912.aspx The range 3GB (0xC0000000) - 4GB (0xFFFFFFFF) is considered system memory and apps should not write here (not sure why you would want to read from there either). But Wine tries to mmap this range (on Mac OSX at least) I was wondering why this is? Should this range just be left as it is? -- is there a reason to mmap this range? Any ideas? for reference -- this mmap is spurred from libs/wine/mmap.c:356 (mmap_init) - Nick

Jan. 1, 2007

Re: winex11: Use GLXFBConfig for the pixel format list

by Vitaliy Margolen

Chris Robinson wrote: > This greatly simplifies some of the wgl code by keeping around a single > customized fbconfig array, instead of holding a static, custom-typedef array > which left many functions to query glx for the fbconfig list anyway (which in > turn caused many needless, potentially problematic allocations and > deallocations of memory). > > This doesn't change the behavior of the code, but it makes it simpler for > future enhancements (such as supporting extra fbconfigs for on-screen or > off-screen use), and easier maintanence by removing a lot of duplicate code. Please don't send compressed patches. It's not that huge to gzip it. > + WineGLFBConfigsListSize = 1; > + WineGLDisplayablePixelFormatListSize = 1; If you hard-coding the list size to 1 it's not a list anymore, but a single element. > @@ -670,7 +718,7 @@ static int ConvertAttribWGLtoGLX(const i > switch (pop) { > case WGL_TYPE_COLORINDEX_ARB: pop = GLX_COLOR_INDEX_BIT; isColor = 1; break ; > case WGL_TYPE_RGBA_ARB: pop = GLX_RGBA_BIT; break ; > - case WGL_TYPE_RGBA_FLOAT_ATI: pop = GLX_RGBA_FLOAT_ATI_BIT; break ; > + case WGL_TYPE_RGBA_FLOAT_ARB: pop = GLX_RGBA_FLOAT_BIT; break ; > default: > ERR("unexpected PixelType(%x)\n", pop); > pop = 0; This code seems like unrelated to the description. Please send it as a separate patch. > @@ -681,12 +729,7 @@ static int ConvertAttribWGLtoGLX(const i > > case WGL_SUPPORT_GDI_ARB: > pop = iWGLAttr[++cur]; > - /* We only support a limited number of formats which are all renderable by X (similar to GDI). > - * Ignore this attribute to prevent us from not finding a match due to the limited > - * amount of formats supported right now. This option could be matched to GLX_X_RENDERABLE > - * but the issue is that when a program asks for no GDI support, there's no format we can return > - * as all our supported formats are renderable by X. > - */ > + PUSH2(oGLXAttr, GLX_X_RENDERABLE, pop); > TRACE("pAttr[%d] = WGL_SUPPORT_GDI_ARB: %d\n", cur, pop); > break; > Your description said nothing about altering this behavior stated in comments. Same for the PUSH, and lots of other changes. It seems to me that you have at least 3-5 separate patches here. Please split them and send them separately. > @@ -1037,13 +987,13 @@ int X11DRV_ChoosePixelFormat(X11DRV_PDEV > /* When we pass all the checks we have found a matching format :) */ > ret = 1; > TRACE("Successfully found a matching mode, returning index: %d\n", ret); > +choose_exit: > + ; > } > > -choose_exit: > if(!ret) > TRACE("No matching mode was found returning 0\n"); > Why do you need this change? > @@ -1519,11 +1458,13 @@ BOOL X11DRV_wglMakeCurrent(X11DRV_PDEVIC > * We are certain that the drawable and context are compatible as we only allow compatible formats. > */ > TRACE(" Creating GLX Context\n"); > - ctx->ctx = pglXCreateContext(gdi_display, ctx->vis, NULL, type == OBJ_MEMDC ? False : True); > + create_glx_context(physDev, ctx, NULL); > TRACE(" created a delayed OpenGL context (%p)\n", ctx->ctx); > } > TRACE(" make current for dis %p, drawable %p, ctx %p\n", gdi_display, (void*) drawable, ctx->ctx); > + X11DRV_expect_error(gdi_display, error_catcher, NULL); > ret = pglXMakeCurrent(gdi_display, drawable, ctx->ctx); > + X11DRV_expect_error(gdi_display, NULL, NULL); > NtCurrentTeb()->glContext = ctx; > if(ret) > { Can you explain this one a bit? Your error_catcher() does nothing, except ignoring the error. Yet here you assuming that calls succeeded and continue on, assigning the context to a thread which won't have the context assigned. Vitaliy.

Jan. 1, 2007

winbench '96 (and '97)

by Dan Kegel

After trying out Winbench '99 without too much success, (http://www.winehq.org/pipermail/wine-devel/2006-December/052818.html) I managed to buy a copy of Winbench '96 on ebay for $3 or so. It seems a little closer to running -- the things that stop it appear to be more garden variety problems, not whacky COM stuff. While there aren't any more copies on ebay, I discovered that searching http://froogle.com for winbench found three books that come with a copy of the tool: "Using Windows 95 : Platinum Edition" (0789707977) comes with Winbench '96 "Optimizing Windows 95 & Windows NT 4.0" ( 0789708418) comes with Winbench '97 "Tom's Hardware Guide" (0789716860) comes with an unspecified version, maybe '99 (which is downloadable anyway, so maybe that's not so interesting). I guess I'll pick up a copy of that one that comes with Winbench '97 just for completeness... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Jan. 1, 2007

.SYS Drivers

by Andrew Neil Ramage

Is there any way to interface between the hardware and windows .SYS and .VXD device drivers ? If it is possible, I would be interested in writing the interface. -- Andrew "Oh, bother," said the Borg. "We've assimilated Pooh."

Jan. 1, 2007

rpc issues

by Matthew Edlefsen

Hi, I've been trying to get a program that uses rpc to work on wine and I've been having some problems (my understanding is that isn't surprising). The goal is to be able to run a rpc server that sits and waits for connections over tcp/ip (It's for doing distributed computing). My first problem was that I was using RpcServerUseProtseq which after looking at the code noticed will always fail with tcp/ip since it passes RpcServerUseProtseqEp NULL for the endpoint which eventually causes rpcrt4_protseq_ncacn_ip_tcp_open_endpoint to call getaddrinfo with NULL for both the ip and port which I guess isn't allowed. Anyways I altered my code to use a given endpoint instead and now it tells me: fixme:rpc:RpcMgmtWaitServerListen not waiting for server calls to finish Does this mean the function just doesn't work? Is there any way around it? I assume if it was easy to implement it would have already but just in case what exactly needs to be done to get it working? I was also confused by the differences between the online git tree and the LXR/what actually gets downloaded to my computer. To be honest I'm pretty new to wine and linux in general but it would be absolutely wonderful to get this working. Thanks in advance - Matt Edlefsen

Jan. 1, 2007