December 2007 - Wine-devel - list.winehq.org

[Fwd: Re: About the WWN]
by kubrick＠fgv6.net 19 Dec '07

19 Dec '07

Hello. As indicated by Zachary, I post the suggestion I made him on the wine-devel list. The suggestion was : "what do you think about writing in the WWN an article about what did the last changes of the last release brought? I mean, knowing that there is "a ton of rpcrt4 fixes" or "New Bidi text implementation that doesn't depend on libicu" is really great, but from a user point of view it doesn't mean anything. It would be great if you'd explain us the problems it solves and which opportunities it gives." What he replies is that he need your help ! Thanks. François. ------------------------------------------------------- Original Message ------------------------------------------------------- Subject: Re: About the WWN From: "Zachary Goldberg" <zgold(a)bluesata.com> Date: Tue, December 18, 2007 19:50 To: François Guerraz <kubrick(a)fgv6.net> -------------------------------------------------------------------------------------------------------------------------------- Francois, If you could do me a favor of suggesting your second point on the wine-devel mailing list then we could start a discussion for it. I think it would be a good idea; however It would require perhaps a bit more detail being made in the commit comments to WINE so that I can go through them and put together the real changes. --Zach On Dec 18, 2007 1:47 PM, François Guerraz <kubrick(a)fgv6.net> wrote: > Hello. > > First of all : thank you so much for being the new author of the WWN. I am a > fervent reader and I was really upset that it was almost never written. I > hope you'll find this task interesting and that you won't be fed up with it > too quick :) > Second I have a suggestion to make : what do you think about writing in the > WWN an article about what did the last changes of the last release brought? > I mean, knowing that there is "a ton of rpcrt4 fixes" or "New Bidi text > implementation that doesn't depend on libicu" is really great, but from a > user point of view it doesn't mean anything. It would be great if you'd > explain us the problems it solves and which opportunities it gives. > > Thank you for your time and implication. > > Regards, > > > François Guerraz > kubrick(a)fgv6.net > > > > -- Zachary Goldberg Computer Science & Engineering Electrical Captain of Penn Electric Race Team School of Engineering at the University of Pennsylvania

1 0

Interview with Alexandre on Lug Radio
by Dan Kegel 18 Dec '07

18 Dec '07

http://www.lugradio.org/episodes/90 "Alexandre Juillard from the Wine Project talks about where Wine is, why it isn't finished, and what's coming next (2.02)" In which we learn that Wine now has a release manager, and that the plan is to release 1.0 for the 15th anniversary of the project. - Dan

1 0

Re: ntoskrnl: Implement or add stubs for several functions.
by Dmitry Timoshkov 18 Dec '07

18 Dec '07

"Chris Wulff" <crwulff(a)rochester.rr.com> wrote: > NOTE: This is required for the "hal: Stubs for ExAcquireFastMutex and > ExReleaseFastMutex" patch to build. (it contains the fast mutex > typedefs.) I apologize for submitting them out of order. You need to send every API implementation as a separate self contained patch, and avoid not necessary white space changes. -- Dmitry.

1 0

Re: WineX11.drv: Add an X11 window for the client area [attempt2]
by Chris Robinson 18 Dec '07

18 Dec '07

On Tuesday 18 December 2007 01:52:11 am Roderick Colenbrander wrote: > > This is an updated version of the previous patch. It contains the > > following changes: > > - the client window is set to the whole window in case of the desktop I think you also need to set the desktop hwnd's client_window_prop too, so GetDC and friends will get the right window when not using the DCX_WINDOW flag. > > - the client window is destroyed in SetParent together with the other X11 > > windows In the case of data->whole_window == data->client_window, you should probably make sure the client_window (and it's prop) are both set back to 0, too.

1 0

DTrace instrumentation
by Damian Wojsław 18 Dec '07

18 Dec '07

Hi I have an idea that I can put some time into. Since Leopard, FreeBSD and, of course, Solaris, now all have DTrace, I thought of implementing some simple probes. Function entry/return for starters. However, I'd firstly need to know two things: - would anyone be interested in it? - would it be legal (it wold link with dtrace library, which on Solaris is CDDL). Regards -- Damian Wojsław OpenSolaris Core Contributor SCA No. OS00073

2 1

Re: gdi32: Add a GdiConvertToDevmodeW test, make it pass under Wine
by Robert Shearman 18 Dec '07

18 Dec '07

Dmitry Timoshkov wrote: > DEVMODEW *dmW; > WORD dmW_size; > > - dmW_size = dmA->dmSize + CCHDEVICENAME; > - if (dmA->dmSize >= (const char *)dmA->dmFormName - (const char *)dmA + CCHFORMNAME) > + dmW_size = dmA->dmSize; > + if (dmW_size > sizeof(DEVMODEA)) > + dmW_size = sizeof(DEVMODEA); > Shouldn't this be sizeof(DEVMODEW)? > + > + dmW_size += CCHDEVICENAME; > Shouldn't this be CCDEVICENAME * sizeof(WCHAR)? > + if (dmA->dmSize >= FIELD_OFFSET(DEVMODEA, dmFormName) + CCHFORMNAME) > dmW_size += CCHFORMNAME; > Shouldn't this be CCHFORMNAME * sizeof(WCHAR)? -- Rob Shearman

2 1

Re: [10/10] WineD3D: Implement blits from the active render target to swapchains
by Stefan Dösinger 18 Dec '07

18 Dec '07

Am Montag, 17. Dezember 2007 21:04:46 schrieb Stefan Dösinger: Do not apply this patch yet, it has some problems

2 1

Re: WineX11.drv: Add an X11 window for the client area [attempt2]
by Roderick Colenbrander 18 Dec '07

18 Dec '07

By accident I discovered that with this patch the wine desktop window doesn't work properly if there are multiple windows around (you notice redrawing issues). I haven't seen those before, so there is something wrong in this patch but I don't know where to look (I guess it is the client_window = whole_window code). Roderick > The previous patch accidently undid one of Stefan's changes and prevented > it from compiling. This patch should be fine. > > Roderick > > > > Hi, > > > > This is an updated version of the previous patch. It contains the > > following changes: > > - the client window is set to the whole window in case of the desktop > > - NortWestGravity is used when creating the client window > > - the client window is destroyed in SetParent together with the other > X11 > > windows > > > > The patch was tested using the user32 tests and various opengl / d3d > test > > apps. All worked correctly. > > > > Regards, > > Roderick Colenbrander > > > > -- > > GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. > > Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail > > -- > GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. > Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

1 0

Re: wined3d: Bind device framebuffer in ActivateContext
by Stefan Dösinger 18 Dec '07

18 Dec '07

Am Sonntag, 25. November 2007 00:07:15 schrieb Allan Tong: > Fixes failures in visual tests for ddraw and d3d8 when using FBO > offscreen rendering mode. > > - Allan This doesn't look right to me. It will most likely break overall FBO support. There is indeed a problem with the fbo and ActivateContext integration, but fixing this is more involved than just setting the framebuffer to 0.

4 9

Vector NTI on Mac, WinHelp improvements
by Misha Koshelev 17 Dec '07

17 Dec '07

Hi guys, It's been a bit since I wrote to the list (or contributed anything... been somewhat busy I guess with lab/school/life). Anyhow I just wanted to acknowledge the new WinHelp fixes (Kirill thanks in particular). Although there is still no Contents or Search, which would make the Vector NTI help more usable, the bug where it would complain about not being able to open help when it was requested even though help would open just fine has now been fixed. Thanks! Also, I've been starting to play some with Wine on Mac and may in time end up contributing some patches for this goal, provided I will have to acquaint myself with some more Mac specific coding ideas first. Specifically though, I'd like to point out that I think the Mac is a hugely important platform for Wine I believe in terms of end-user adoption, and although I understand the rationale for not having binary packages available because Apple's X11 is buggy (which it clearly is), I think it would still be nice to have the Mac at least be an important focus. And yes my thought initially was "well there's usually a Mac version of the Windows program." But alas unfortunately this seems to not quite be the case a lot of times. For example, even Vector NTI, which has both "mac and windows" versions, actually has a Mac version that does not work on MacOS 10.4 and higher (the company reports they are working on a code rewrite for Mac versions, but meanwhile there are tons of people out there on Google looking for ways around this/alternatives as Vector NTI is very common in molecular biology and Macs are traditionally the platform of choice in the field)... Wine would find a very nice niche here with a bunch of people that otherwise prob would not end up using it. Another program we use a lot, Kodak Molecular Imaging, also actually has problems with MacOS 10.4+ on Intel (not PowerPC) Macs, although this has to do with the dongle drivers (USB dongle = Sentinel SuperPro), so likely Wine would need a little more improvement to be of use here. Anyway, just wanted to point out my observations about the Mac and that although others might be thinking along the same lines I was... "well most programs available for Windows are available for Mac", in two examples I've discovered that upon careful examination this actually turns out to be quite opposite of the actual case. Thanks for you time Misha

1 0