wine-devel June 2006

174 participants
352 discussions

by fenix＠club-internet.fr

----Message d'origine---- >Date: Fri, 2 Jun 2006 21:27:53 +0200 >De: Lionel Ulmer <lionel.ulmer(a)free.fr> >A: Dan Kegel <dank(a)kegel.com> >Copie à: wine-devel(a)winehq.org, >Sujet: Re: Re: Wine 1.0 Tasks > >On Tue, May 30, 2006 at 05:32:26PM -0700, Dan Kegel wrote: >> On 5/30/06, Scott Ritchie <scott(a)open-vote.org> wrote: >> > > It might be, but the heavy hitters I know of who have taken a look at >> > > it in detail have concluded that an X change really is needed.] >> > >> > Is this really a problem? Another version of X is due out in about 4 >> > months (probably the earliest we could possibly see Wine 1.0), so why >> > can't we just help write an X extension to tackle the bug? >> >> Not really a problem. It'll just take some time to trickle out to the world. >> We may also have to get Nvidia and ATI on board so they can implement >> the extension in their drivers. > >And for it to be taken, I guess we would need to not only write the >extension, but a 'reference implementation' (I would guess in DRI / Mesa) >and get it approved by the FD.o people. > >But ohsix's idea to use 'real' X windows 'overlaid' over the single Wine X >window would be the easiest idea to investigate (because it would not only >fixes this issue but also the mutiple windows with multiple pixel formats >problem that the former 'extension' solution does not). > i thought the same idea. But investigation modifications in x11drv to permit wine x pixmaps access for wined3d/opengl will fix many problems (but not hthe multiple pixel formats) Anyway we must move some code of wined3d and opengl32 (GLX code, etc...) to x11drv as it permit : - to handle this problems without hacks (ie many ExtEscape) - to help macos-X to port wined3d and opengl (all specific cost must be on x11drv/qwartwdrv) > Lionel (in 'not even time to read wine-devel' mode :-) ) > Well, at least i take time for it :) (and reviewing the flood of d3d patches) Waiting for you for coding :p Regards, Raphael

17 years, 11 months

Re: How are we doing?

by Juan Lang

> Especially the code that is responded to as , I know it's a mess to > look at, but I didn't write it. Can you give us examples? Mostly Wine attempts to follow how Windows works, so MSDN provides a lot of the documentation. This is becoming increasingly true, with kernel32 being implemented on top of ntdll. There are bits that are hard to understand, certainly, and some areas could use some comments. Unfortunately sometimes the lack of comments demonstrates a lack of understanding, but the code works for someone, somewhere, so we're mostly afraid to touch it until some brave soul comes along. For example, SHFileOperation was a complete mess until James fixed it up. Another example is user32. It's impossible to document (in English) what it's supposed to be doing. For this, and many other cases, a good regression test suite is the best documentation: it tells you what's expected, so if you go mucking around you have checks against introducing regressions. I know you've been working with msi lately. The fact that you've figured out where the problem is indicates to me that it's adequately commented, even if the learning curve is still a bit steep. Patches to add API comments for the Wine API guide (http://source.winehq.org/WineAPI/ ) are always welcome. Patches to document dodgy bits of code may or may not be accepted, but regression tests to justify dodgy bits of code are happily accepted too. http://source.winehq.org/WineAPI/ --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

17 years, 11 months

Quartz driver

by Emmanuel Maillard

Hi all, Quartz driver is up to date on Darwine CVS. Winemine is playable on both PPC and x86 but it look fine only on PPC, x86 driver suffer strange rendering bugs. See wiki for building the driver : http://wiki.opendarwin.org/ index.php/Darwine:quartzdrv I will update wiki soon with issues and todo for Quartz driver. Cheers Emmanuel

17 years, 11 months

Re: Re: Wine 1.0 Tasks

by fenix＠club-internet.fr

Hi, >> (Note the #3902 should be renamed as 'DIB Engine rewrite' > >Agreed; done. http://bugs.winehq.org/show_bug.cgi?id=3902 :) >> and i don't think is mandatory for 1.0) > >Probably right. Let's create the next milestone after 1.0, say 1.1, and start >retargeting bugs we don't plan to fix for 1.0. (That's what GCC does; >some bugs they retarget early, some just before the release.) > >> But i think we must fix users most hated bugs as: >> - dsound deadlocks/craps >> - openGL problems (multi contexts, fb/visual configs) >> - lotus problems > >The OpenGL child window bug, >http://bugs.winehq.org/show_bug.cgi?id=2398 >probably won't be fixed for 1.0 because it requires >an X server change. No it must be doable without X changes (But X additions as GLX_EXT_texture_from_pixmap will help a lot). Only problem is to find time to fix it (as lionel, i have no time for now). Anyway i having a simple and downloadable application to reproduce this problem (not lightwave) must help. The only parts who really needs X change are for: - glShareList: sharing fb/visual config between exitings GLX contexts - dinput mouse management >I'm not sure lotus notes problems should block 1.0, as IBM has a native >Linux client now, but if someone wants to fix them (especially the ones >in usp10.dll netapi32.dll, that would be great. agree :) >> Note: it will be interesting to add user votes to wine-bugs (ala kde) to >> better see user needs. > >There are already user votes in bugzilla, that should suffice. >- Dan Oups i never seen it :) Regards, Raphael

17 years, 11 months

Re: Missing LeaveCriticalSection on error paths (found by Smatch).

by Michael Stefaniuc

Michael Stefaniuc wrote: > can somebody more familiar with this code confirm that on the error > paths the CriticalSection should be released? I'm not sure about it as > the function is supposed to keep the lock held when exiting without > error; there is a d3ddevice_unlock_update() function that releases the > lock. Asked Lionel Ulmer on irc and the patch is correct. But according to Stefan Dösinger that code will be replaced by his code "in the next couple of days". bye michael > --- > > dlls/ddraw/device_opengl.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > dd0b9b20d26984ae408c1a7727323a08d44e0d95 > diff --git a/dlls/ddraw/device_opengl.c b/dlls/ddraw/device_opengl.c > index d19996e..4c663a6 100644 > --- a/dlls/ddraw/device_opengl.c > +++ b/dlls/ddraw/device_opengl.c > @@ -3775,10 +3775,12 @@ static void d3ddevice_lock_update(IDirec > buffer_color = GL_BGRA; > } else { > ERR(" unsupported pixel format at device locking.\n"); > + LeaveCriticalSection(&(d3d_dev->crit)); > return; > } > } else { > ERR(" unsupported pixel format at device locking - alpha on frame buffer.\n"); > + LeaveCriticalSection(&(d3d_dev->crit)); > return; > } > > > > ------------------------------------------------------------------------ > > -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

17 years, 11 months

Re: test case for MSI problem in America's Army installer

by Dan Kegel

I think you can just compile and run it with visual C++ as a standalone app, with the right commandline options to the compiler. Let's see: try the instructions here: http://www.winehq.com/hypermail/wine-devel/2005/05/0865.html You can also build with the wine build system and then run the executable with a single commandline option giving the name of the test to run. Better ask on wine-devel, I have to run. On 6/2/06, EA Durbin <ead1234(a)hotmail.com> wrote: > How does one use the test application in the msi/tests folder? > > I know you run it with wine, but without looking through all of the code in > the application to determine this could you maybe advise me what it expects > for arguments, or how to work with it? > > Do you pass it an misdatabase, and a DB argument, or how does this utility > work? > > I don't usually hack in C, but im somewhat capable. I could write a mean > Hello World Application back in college. My day usually consists of parsing > data with PERL, but that doesn't mean I can't pick up C again. > > I'd appreciate it if you focused some energy on it, but I would also like to > know how it works so I can contribute in the future. > > > >From: "Dan Kegel" <dank(a)kegel.com> > >To: wine-devel <wine-devel(a)winehq.org> > >Subject: re: test case for MSI problem in America's Army installer > >Date: Fri, 2 Jun 2006 07:06:30 -0700 > > > >Mike M. wrote: > >>>>[America's Army install crashes, see > >>>>http://bugs.winehq.org/show_bug.cgi?id=5139 ] > >>> > >>>This is as close as I will be able to come to including a test case, as > >>>this is how I obtained my results. > >> > >>If you want me to fix the problem, please submit a regression test to > >>wine-patches with a todo_wine{} around the code that doesn't work. > > > >If that's too hard for EA (he admits he's not a C hacker), maybe > >I can focus some energy on it... > >- Dan > > > > > > > -- Wine for Windows ISVs: http://kegel.com/wine/isv

17 years, 11 months

winedbg: newbie question (sorry...)

by Molle Bestefich

Hello Carsten Niehaus (cniehaus(a)gmx.de) over on wine-users gets a page fault when he tries to print with this app: http://www.learn-line.nrw.de/angebote/gefahrstoffdb/Gefahrstoffe.zip He's posted a backtrace: > fixme:commdlg:PRINTDLG_SetUpPrinterListComboA Can't find '(null)' in printer list so trying to find default > wine: Unhandled page fault on write access to 0x0000002e at address 0x7f6a2540 (thread 0009), starting debugger... > Backtrace: > =>1 0x7f6a2540 PRINTDLG_WMCommandA+0x619 in comdlg32 (0x7f6a2540) > 2 0x7f6a2fb6 in comdlg32 (+0x32fb6) (0x7f6a2fb6) [snip!] > 0x7f6a2540 PRINTDLG_WMCommandA+0x619 in comdlg32: movw %ax,0x2e(%edx) I'm slightly cli-debugger-clueless, so could one of you guys please tell me how to convert this: PRINTDLG_WMCommandA+0x619 into a proper line number reference to the source file?

17 years, 11 months

RFC - wine-macos mailing list

by Jeremy White

Hi Folks, I'd like to pull one thread out of a previous discussion and ask for comments on it specifically; I think other issues in the thread detracted from what I think is a useful discussion. Specifically, should we create a 'wine-macos' mailing list? I think the idea would be that it would be a mailing list for Mac users and developers to worry about Mac specific issues. The benefit is that it would be more inviting to Mac users and it would allow Mac folks to hone in on Mac specific topics. The goal is still that Mac Wine developers would come join us on wine-devel and #winehackers, so it would likely end up primarily as a user forum. I guess the downside is that it could be confusing, and you can argue that we haven't created any platform specific lists prior to this. My driving concern is that I think we need to welcome the Mac community to the Wine Project and do all that we can to enable the Mac developers and users to use mainstream Wine resources. I don't think anyone wants www.winehq.org to be perceived as a 'Linux only' environment. (Although I do see that www.winehq.org doesn't list Mac OS X...hmmm). Some Mac folks have told me privately that having a Mac specific mailing list on www.winehq.org would make it more inviting to them. Perhaps that is reason alone to make the change. What do others think? Cheers, Jeremy

17 years, 11 months

Re: comctl32: Fix loading string from resources (take 2)

by Dmitry Timoshkov

"Thomas Weidenmueller" <wine-patches(a)reactsoft.com> wrote: > LoadString() cannot be used to measure the length of a string resource. > It will not return the length of the string if no buffer is provided, > instead it will return 0! This patch fixes the broken property sheet code. It would be appropriate to provide a test case showing correct LoadString behaviour and fix LoadString in Wine if it confirms the statement above since Wine clearly returns the size of the string resource if the passed buffer is NULL. -- Dmitry.

17 years, 11 months

Wine 1.0 tasks: installers

by Dan Kegel

James Hawkins and I think we should come up with a list of installers that need to run before we release Wine 1.0. Looking at http://www.winehq.org/pipermail/wine-devel/2006-March/045634.html and http://bugs.winehq.org/buglist.cgi?short_desc_type=allwordssubstr&short_des… I made a list biased towards freely downloadable apps, programming tools, things Munich wants, stuff that has been passionately discussed of late (e.g. America's Army), educational apps, and anything that smacks of long-unfinished business. Here's what I ended up with: http://bugs.winehq.org/show_bug.cgi?id=3590 ActiveState python msi (see 5237?) http://bugs.winehq.org/show_bug.cgi?id=3972 .NET framework 2.0 http://bugs.winehq.org/show_bug.cgi?id=4227 QuickTest Pro http://bugs.winehq.org/show_bug.cgi?id=4280 J2SE 1.5 http://bugs.winehq.org/show_bug.cgi?id=4492 MinGW installer stalls http://bugs.winehq.org/show_bug.cgi?id=4569 Oregon Trail 5 wants DX8 http://bugs.winehq.org/show_bug.cgi?id=4802 Oracle client library (munich) http://bugs.winehq.org/show_bug.cgi?id=4700 spss demo (munich) http://bugs.winehq.org/show_bug.cgi?id=4860 java plugin http://bugs.winehq.org/show_bug.cgi?id=5296 Kidspiration install window hidden? http://bugs.winehq.org/show_bug.cgi?id=5237 wsh (and ActiveState perl msi) http://bugs.winehq.org/show_bug.cgi?id=5275 google earth http://bugs.winehq.org/show_bug.cgi?id=5325 art2kmin.exe (munich, UK EPBD-NCM) http://bugs.winehq.org/show_bug.cgi?id=5322 VB6 / VC++6 installers fail early Some of those might already be fixed, hopefull we can just close out a couple. And a couple might be too hard for 1.0 (.net, say), it's ok to defer them to 1.1 later if we have to. Ideally we'd also have cxtest scripts for all of these installers, so Codeweavers can use them to validate new releases. How's that sound? - Dan

17 years, 11 months

Jump to page:

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 2006