September 2007 - Wine-Devel

Fwd: Phoronix Forums: AMD Linux Announcement
by Dan Kegel Sept. 5, 2007

Sept. 5, 2007

Say, maybe these new drivers won't crash with Wine a la http://wiki.winehq.org/fglrx Wouldn't that be sweet? ---------- Forwarded message ---------- From: phoronix-forums(a)phoronix.com <phoronix-forums(a)phoronix.com> Date: Sep 4, 2007 9:15 PM Subject: Phoronix Forums: AMD Linux Announcement ... We also wanted to let you know that Advanced Micro Devices has officially announced their new Linux driver this morning, which is a overhaul of their existing Linux graphics driver. The AMD fglrx 8.41 (Catalyst 7.9) driver introduces Radeon HD 2000 "R600" support as well as massive performance improvements for all supported generations of ATI graphics processors. This new driver is not available today, but it will be made available within the next week. Though at Phoronix we have been using and testing this new driver now for a number of weeks. Below are the articles we have just published today about this new ATI/AMD Linux driver. AMD 8.41 Display Driver Preview -- Our first article on this new driver are simply the technical details such as noting this driver has been actually in development for over a year, the AIGLX support that is coming next month, and other relevant information. Read More: http://www.phoronix.com/vr.php?view=10955 ATI R300/400 Linux Performance -- We re-tested the Radeon X300 and X800XL with this new driver and it offers some HUGE performance improvements! The Mobility Radeon X300 was as much as 54 times faster compared to the previous ATI Linux driver. The improvements in these older ATI GPUs are simply astonishing. Read More: http://www.phoronix.com/vr.php?view=10964 ATI R500 Linux Performance -- With an X1300PRO, X1800XL, X1800XT, and X1950PRO in hand we compared the ATI 8.40 and 8.41 display drivers. The performance improvements for the Radeon X1000 series range from 50% to 90% faster. Read More: http://www.phoronix.com/vr.php?view=10970 ATI Radeon HD 2900XT Linux Performance -- Four months after the Radeon HD 2900XT was introduced there is finally proper Linux support! Not only is there support, but it offers a pretty darn good level of performance. In fact, the ATI Radeon HD 2900XT offers the best bang for the buck when it comes to high-end graphics cards. There is also more on the R600 support in general inside this article. Read More: http://www.phoronix.com/vr.php?view=10973 AMD: Accelerating Open-Source Drivers? -- Not today, but in the near future AMD will be making an announcement about accelerating efforts within the open-source community. What does this mean? Open-Source ATI Drivers? We will tell you in due time. Read More: http://www.phoronix.com/vr.php?view=10977 At Phoronix we also have a number of other articles we will be publishing in the near future pertaining to this new driver and the Radeon HD 2000 series support. Be sure to check out the latest articles and join in on the discussions in the Phoronix Forums! Best, The Phoronix Staff

2 1

osalt.com top-requested commercial app stats
by Dan Kegel Sept. 5, 2007

Sept. 5, 2007

http://www.osalt.com/ has a list of most-requested commercial windows apps, currently: 1. Visio 2. Norton Ghost 3. Photoshop 4. Nero Burning Rom 5. Dreamweaver 6. AutoCAD 7. Illustrator 8. Access 9. Premiere Pro 10. ACDSee No idea how they generated that list, but it seems somewhat reasonable. cc'ing them in case they feel like commenting on where that list comes from and what it means. (And no, I don't think Ghost will ever run on Wine :-) - Dan

7 7

Re: comctl32: TCM_SETCURSEL also updates the focus item
by Reece Dunn Sept. 5, 2007

Sept. 5, 2007

On 04/09/07, Aric Stewart <aric(a)codeweavers.com> wrote: > --- > dlls/comctl32/tab.c | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) Do you have a test for this? - Reece

2 1

Re: RFC: winealsa.drv: fix memory leak (found by Smatch)
by Michael Stefaniuc Sept. 4, 2007

Sept. 4, 2007

Hello Lionel, the patch has different problems: - lpNewData is used only in "case MOD_MIDIPORT" so moving the HeapAlloc call there makes more sense. - Please keep the indentation level of the surrounding code; here it is 4. - Tabs are 8 spaces. Lionel_Debroux wrote: > modLongData leaks some heap memory in three error paths. Found in > Michael Stefaniuc's list of Wine potential bugs detected by Smatch. > > While looking at the function, I noticed > if (lpNewData) > HeapFree(GetProcessHeap(), 0, lpData); > at lines 1015-1016. > I think "lpData" should be "lpNewData", because this function allocates > "lpNewData", not "lpData" which is passed to the function through a > LPMIDIHDR structure. > So I added a FIXME, and I am asking for comments/corrections :-) lpNewData is allocated only if lpData has a wrong start/end byte in the header. It is passed on in that case instead of lpData. If the functions to which it is passed on process the data asynchronous then the current code is correct: the caller cannot free the data (lpNewData) as the callee might still need to process it whereas lpData is unused and can be freed. The "event" name suggests an asynchronous processing of the data but that's only a guess as i don't know the code. bye michael > > 2007-08-31 Lionel Debroux <lionel_debroux(a)yahoo.fr> > * dlls/winealsa.drv/midi.c: > winealsa.drv: fix memory leak (found by Smatch) > > > ------------------------------------------------------------------------ > >>From e148279419c180bd3db1b8b1a61f737bd92c73be Mon Sep 17 00:00:00 2001 > From: Lionel Debroux <lionel_debroux(a)yahoo.fr> > Date: Fri, 31 Aug 2007 14:33:40 +0200 > Subject: winealsa.drv: fix memory leak (found by Smatch). > > --- > dlls/winealsa.drv/midi.c | 12 +++++++++--- > 1 files changed, 9 insertions(+), 3 deletions(-) > > diff --git a/dlls/winealsa.drv/midi.c b/dlls/winealsa.drv/midi.c > index f5e98ed..2cf9287 100644 > --- a/dlls/winealsa.drv/midi.c > +++ b/dlls/winealsa.drv/midi.c > @@ -1013,20 +1013,26 @@ static DWORD modLongData(WORD wDevID, LPMIDIHDR lpMidiHdr, DWORD dwSize) > snd_seq_ev_set_sysex(&event, lpMidiHdr->dwBufferLength + len_add, lpNewData ? lpNewData : lpData); > snd_seq_event_output_direct(midiSeq, &event); > if (lpNewData) > - HeapFree(GetProcessHeap(), 0, lpData); > + HeapFree(GetProcessHeap(), 0, lpData); /* FIXME: lpNewData instead of lpData ? */ > break; > default: > WARN("Technology not supported (yet) %d !\n", > MidiOutDev[wDevID].caps.wTechnology); > - return MMSYSERR_NOTENABLED; > + if (lpNewData) > + HeapFree(GetProcessHeap(), 0, lpNewData); > + return MMSYSERR_NOTENABLED; > } > > lpMidiHdr->dwFlags &= ~MHDR_INQUEUE; > lpMidiHdr->dwFlags |= MHDR_DONE; > if (MIDI_NotifyClient(wDevID, MOM_DONE, (DWORD)lpMidiHdr, 0L) != MMSYSERR_NOERROR) { > WARN("can't notify client !\n"); > - return MMSYSERR_INVALPARAM; > + if (lpNewData) > + HeapFree(GetProcessHeap(), 0, lpNewData); > + return MMSYSERR_INVALPARAM; > } > + if (lpNewData) > + HeapFree(GetProcessHeap(), 0, lpNewData); > return MMSYSERR_NOERROR; > } > > > > ------------------------------------------------------------------------ > > -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 -------------------------------------------------------------------- Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart Handelsregister: Amtsgericht Stuttgart HRB 153243 Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham, Werner Knoblich

1 0

Re: dinput: Add evdev mouse driver.
by Stefan Dösinger Sept. 4, 2007

Sept. 4, 2007

Hi, > This is the first fully working implementation of dinput mouse using evdev > generic input driver. I have enabled this driver by default. If people do > not have functioning HAL or that for some reasons it can't find the mouse > device, it will fall-back to current mouse driver. > > Use explorer to enumerate all mice devices. Unfortunately msdn says there > can only be one system pointer device. I was curious if that patch fixes Empire Earth, so I tried it, but it fails to create a new evdev mouse and falls back to the x11 based mouse. It seems that HKEY_LOCAL_MACHINE\HARDWARE\DeviceMap\PointerClass does not exist. I've run wineprefixcreate and made sure I have full access to /dev/input/*, do I need anything else?

2 2

Re: winhelp, Vector NTI, molecular biologists
by Misha Koshelev Sept. 4, 2007

Sept. 4, 2007

On 9/3/07, Stefan Dosinger wrote: > Am Montag, 3. September 2007 13:30:57 schrieb Damjan Jovanovic: > > Somebody needs to make a do-nothing-useful app, intended for Windows, > > that also installs on wine and supplies each and every DLL that > > Windows applications need but we don't have in wine (like MFC42.DLL, > > the D3DX9_xx.DLL's, new MSVCRT's, etc.). That way we can legally use > > those DLLs without a Windows licence. > This is not necessarily true. I don't know about MFC42.dll or the msvcrts, but > the directx eula does not allow that; It requires the application to run only > on the Microsoft Windows operating system, targetting both Windows and > Linux+Wine violates the contract. These are the conditions for distributing > the directx dlls. I've not found anything against installing them on Wine, > you just must not distribute the DLLs with an app that targets both Windows > and Wine. Thus I think it's legal to write a script that downloads them from > the original location @microsoft.com and installs them, as long as that > script isn't bundled with the dlls. However, IANAL. > > What remains unanswered though is how this affects game vendors whose games > run on Wine without intention from the game vendor and ship the dlls, e.g. > Eve Online. Actually you all bring up rather interesting points with regards to Vector NTI as: (a) It pretty much ships with almost every Microsoft redistributable needed (e.g., MDAC, Windows Script, MFC71, etc.) and installs them on its installation _except_ MFC42 (not sure why this oversight and if this would break it on some native system, although I _believe_ it installed correctly on my plain vanilla Win98 VMWare installation, but I would have to double check for sure). (b) If the licenses for those DLLs/redistributables are the same as you suggest for DirectX, this would mean they couldn't ever say they support Wine (but I'm not sure whether or not the licenses are). Anyway, seeing it work "gold" on Wine still wouldn't be a bad thing in either case and certainly Vector NTI is not the only program that needs good winhelp support. Misha

3 3

Monster and Me in wine
by Nguyễn Thành Trung Sept. 4, 2007

Sept. 4, 2007

Hi ! I'm playing Monster and Me (www.monsterandme.com) in wine. In wine 0.9.7, there's a small bug when login, but every else work fine. In other newer versions of wine, login screen works fine, the game's performance is better - nearly like in windows. But there's a bug when talking with NPC make me can't play this game. Can any 1 find and fix this plz? Thanks !

2 1

re: Would like to contribute to wine
by Dan Kegel Sept. 4, 2007

Sept. 4, 2007

Maciej wrote: > I'm looking for subject for my Master's thesis. It might be interesting to > do something useful for Wine. A few things you could help finish: 1) widl, Wine's IDL compiler. Dan Hipschman has been improving widl for some time, but his internship is up in a couple months, and I'm sure he'd love some help. 2) crypt32 / wintrust. Lots of apps need these. Juan Lang has been working on these this summer, but his internship is up at the end of the month, and I'll bet he has a big todo list. 3) gdiplus. Evan Stade did a great job getting this going, and several apps that need it now run, but there's lots left to do. 4) msvcrt. Believe it or not, our bugzilla lists 21 or so bugs against the C runtime library. You'd think we'd have that finished by now, but no. 5) wintab, i.e. the library and service that lets Tablet PC apps run. John Klehm got started on that this summer, but wasn't able to get the event sink demo app running. All of the above would probably be fun, and all have the property that you could make useful progress in a month or two. I'm sure there are lots of other ideas... - Dan

2 1

Re: shlwapi: Duplicate shell32.ShellMessageBoxW implementation in shlwapi.ShellMessageBoxWrapW
by Reece Dunn Sept. 4, 2007

Sept. 4, 2007

On 04/09/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > Hello, > > as Alexandre pointed out we can't really forward shlwapi.ShellMessageBoxWrapW > to shell32.ShellMessageBoxW, we need to duplicate its implementation. Is it possible to add a function to libwine that contains this code and then forward both these API to that one? Then you don't have the code duplication. - Reece

2 1

re: winhelp, Vector NTI, molecular biologists
by Dan Kegel Sept. 4, 2007

Sept. 4, 2007

Damjan wrote: > Somebody needs to make a do-nothing-useful app, intended for Windows, > that also installs on wine and supplies each and every DLL that > Windows applications need but we don't have in wine (like MFC42.DLL, > the D3DX9_xx.DLL's, new MSVCRT's, etc.). That way we can legally use > those DLLs without a Windows licence. Ah, but look at the EULA. For instance, the Visual C++ 6 EULA http://kegel.com/wine/isv/visual-studio-6-EULA.html says in section 4.1 that any app that redistributes its redistributables has to add "significant and primary functionality". Thus a do-nothing app would probably not satisfy the EULA, but a fun game might. So, rather than creating such an app yourself, it might be better to go look for existing freely distributed apps (preferably from Microsoft!) which already do this. For instance, Word Viewer 97 from MS has a very liberal EULA that allows free redistribution, and providesl DOCOBJ.DLL (required for Dragon Naturally Speaking) and tahoma font. There are probably several similar apps from Microsoft with unlimited redistribution that happen to bundle mfc40 and mfc42. No reason we couldn't put those apps up on winehq.org, and add an easy way in Wine to download the Popular Application Pack or something like that. - Dan

1 0

winhelp, Vector NTI, molecular biologists
by Misha Koshelev Sept. 3, 2007

Sept. 3, 2007

Hi everybody, So as you all know I've been working on various bug fixes throughout wine, with my most significant contributions to date being MSI OLE automation support and implementation of http protocol support in urlmon. This involvement was driven by my initial experiences of getting a key program used by molecular biologists, Invitrogen's Vector NTI, to install on wine with a fairly convoluted shell script and submitting my first patch to fix a crash with this program; Dan Kegel helped me iron out this first patch a lot and furthermore his comments about how it'd be nice if such a complicated shell script was not necessary with wine got me started with my other patches and the rest, as they say, is history. So why, you may ask, am I sending all this in an email to wine-devel? The short answer is that this is a shameless email to see if I might motivate someone to work on our winhelp implementation a bit, as it is currently completely useless with Vector NTI. This seems like a fairly significant task, and my obligations at school/work have recently kicked up quite a bit, making it unlikely I will be able to take it on anytime soon. However, I hope to motivate someone with these reasons: (i) I feel like I've certainly been doing (and will continue to do) my part in helping out wine, and if this in any case motivates someone looking for a development direction I would certainly not object; and (ii) My ultimate vision/goal has been to have Vector NTI run so well that I could approach Invitrogen and see if they might at the very least say something to that effect on their Web site ("add wine + linux as a supported platform"), if not package Vector NTI a la Google Picassa, which would be great publicity for wine. Also, as you can see from the comments on my ubuntuforums howto http://ubuntuforums.org/showthread.php?t=347095 for a lot of molecular biologists, Vector NTI is the only reason they have to dual-boot/use VMWare at all (full-disclaimer: this is not 100% true for myself). So you could help perhaps a fairly small but non-insignificant group of people by doing some work on winhelp. Although Vector NTI is a rather large set of programs, currently I believe the only things keeping it from installing/working to a "gold" level according to winehq definitions are (i) winhelp and (ii) either MFC42 implementation (required for WSH to install properly; I suppose only a few functions prob are really required, but I'm not sure how good an idea having a very small stub MFC42 would be) or JScript support in wine. Either item in (ii) seems like a very significant undertaking, but (i) seems doable and prob. necessary for a lot of apps. So anyhow just my attempt to influence someone to start working on winhelp. Sorry for cluttering your inboxes. Misha

4 4

Re: dsound: Runtime link to advapi32 RegDeleteTree
by Reece Dunn Sept. 3, 2007

Sept. 3, 2007

Correct me if I am wrong on this, but I have a few questions. And I apologise if I ask some stupid questions, as I don't understand how the Wine loader works. On 01/09/07, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > Makes the dsound dll work in windows xp and older versions of windows > again. By this, do you mean running the Wine dsound.dll on _native_ Windows? > It is the least of all evils as far as I could see. It's either > this or adding RegDeleteTree to libwine, unless someone has a third option. If the intent is to get this working on native, adding RegDeleteTree to libwine will not help. Unless you mean running Wine in Windows XP or earlier compatibility mode? If so, I was under the assumption that all the API were available to Wine, it was just the reported OS version that differed. I say this, because none of the Windows headers vary on OS version like the Windows SDK does. Even so, since the RegDeleteTree API are queried for by GetProcAddress, this means that they will not be found on WinXP and earlier, so DllUnregisterServer will fail on those platforms, leaving behind the dsound GUIDs on those platforms. This is bad practice, but I don't see how else this will work (assuming that these are run on native). > +static typeof(RegDeleteTreeW) * pRegDeleteTreeW; Is it common practice in Wine to use typeof? I was under the assumption that this was limited to the gcc C++ compiler. Even if it is available in the C compiler, it is not portable to compilers that don't support that, such as pre-typeof gcc compilers. - Reece

2 2

Hmm. Cider and the LGPL
by Dan Kegel Sept. 3, 2007

Sept. 3, 2007

http://www.linux-community.de/story?storyid=23294 and http://www.macnews.de/news/102145.html mention that some users are using Cider from one game to run a second game on the Mac. The game vendors are upset, and are saying they'll do something to make that harder. There is some question about whether Cider includes LGPL components of Wine, and whether there are any violations lurking there. I imagine our friends at Cedega would instinctively avoid such infringement, but accidents might happen. It'll be interesting to see if anybody finds a real problem. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

6 7

UbiSoft giving away games
by Michael Lothian Sept. 3, 2007

Sept. 3, 2007

Hi Just thought I'd share this with you all. http://www.theinquirer.net/default.aspx?article=42069 For those of you that haven't heard I know FarCry works with wine I'm not sure about the other 2 but it could be worth making them work if they don't as a PR exercise especally if they work under Ceider Any hoo I should be off to bed now Mike

3 2

Re: regedit: fixed a memory leak in listview.c (found by Smatch).
by Dmitry Timoshkov Sept. 3, 2007

Sept. 3, 2007

"Lionel_Debroux" <lionel_debroux(a)yahoo.fr> wrote: > diff --git a/programs/regedit/listview.c b/programs/regedit/listview.c > index 0e4b52b..8b58eec 100644 > --- a/programs/regedit/listview.c > +++ b/programs/regedit/listview.c > @@ -61,7 +61,10 @@ static LPTSTR get_item_text(HWND hwndLV, int item) > > curStr = HeapAlloc(GetProcessHeap(), 0, maxLen); > if (!curStr) return NULL; > - if (item == 0) return NULL; /* first item is ALWAYS a default */ > + if (item == 0) { /* first item is ALWAYS a default */ > + HeapFree(GetProcessHeap(), 0, curStr); > + return NULL; > + } A more logical fix would be to move if (item == 0) return NULL; /* first item is ALWAYS a default */ before HeapAlloc() call. -- Dmitry.

1 0

Re: winhelp, Vector NTI, molecular biologists
by Misha Koshelev Sept. 3, 2007

Sept. 3, 2007

> 2007/9/3, Misha Koshelev <mk144210(a)bcm.edu>: > Hi everybody, > > So as you all know I've been working on various bug fixes > throughout > wine, with my most significant contributions to date being MSI > OLE > automation support and implementation of http protocol support > in > urlmon. This involvement was driven by my initial experiences > of getting > a key program used by molecular biologists, Invitrogen's > Vector NTI, to > install on wine with a fairly convoluted shell script and > submitting my > first patch to fix a crash with this program; Dan Kegel helped > me iron > out this first patch a lot and furthermore his comments about > how it'd > be nice if such a complicated shell script was not necessary > with wine > got me started with my other patches and the rest, as they > say, is > history. > > So why, you may ask, am I sending all this in an email to > wine-devel? > The short answer is that this is a shameless email to see if I > might > motivate someone to work on our winhelp implementation a bit, > as it is > currently completely useless with Vector NTI. This seems like > a fairly > significant task, and my obligations at school/work have > recently kicked > up quite a bit, making it unlikely I will be able to take it > on anytime > soon. However, I hope to motivate someone with these reasons: > > (i) I feel like I've certainly been doing (and will continue > to do) my > part in helping out wine, and if this in any case motivates > someone > looking for a development direction I would certainly not > object; and > > (ii) My ultimate vision/goal has been to have Vector NTI run > so well > that I could approach Invitrogen and see if they might at the > very least > say something to that effect on their Web site ("add wine + > linux as a > supported platform"), if not package Vector NTI a la Google > Picassa, > which would be great publicity for wine. Also, as you can see > from the > comments on my ubuntuforums howto > http://ubuntuforums.org/showthread.php?t=347095 for a lot of > molecular > biologists, Vector NTI is the only reason they have to > dual-boot/use > VMWare at all (full-disclaimer: this is not 100% true for > myself). So > you could help perhaps a fairly small but non-insignificant > group of > people by doing some work on winhelp. > > Although Vector NTI is a rather large set of programs, > currently I > believe the only things keeping it from installing/working to > a "gold" > level according to winehq definitions are (i) winhelp and (ii) > either > MFC42 implementation (required for WSH to install properly; I > suppose > only a few functions prob are really required, but I'm not > sure how good > an idea having a very small stub MFC42 would be) or JScript > support in > wine. Either item in (ii) seems like a very significant > undertaking, but > (i) seems doable and prob. necessary for a lot of apps. > > So anyhow just my attempt to influence someone to start > working on > winhelp. Sorry for cluttering your inboxes. > > Misha > Btw I should have posted the URL to the demo version: http://download.invitrogen.com/evergreen/Vector%20NTI%20Advance%2010.exe To me the main problem with winhelp here is just that none of the winhelp navigation (Contents, Search, etc.) is implemented, making it difficult to, for example, answer the question "how do I do X?" which I'm sure Invitrogen would care about. From what I understand looking over some of the winhelp bug reports, the way .hlp files are currently processed this would be difficult/slow to implement, so probably a different way of processing them is necessary (don't know more than I read from searching for winhelp in the bugzilla for this tho, haven't investigated it myself). Currently there is also a "bug" where WinHelp returns the incorrect value (WM_SENDDATA in winhelp program returns 0L and thus so does WinHelp which just returns the result of SendMessage, whereas according to MSDN WinHelp() shoudl return non-zero on success). In any case this latter thing would be pretty easy to fix, but I think really the rest of winhelp would need to be fixed for this second part to have any real use (other than removing an annoying "Failed to open help file" dialog). Thanks everybody Misha

1 0

Re: ddraw: fix cases where desc2.u2.dwMipMapCount is 0.
by Stefan Dösinger Sept. 3, 2007

Sept. 3, 2007

Am Sonntag, 2. September 2007 14:16 schrieb David Hedberg: > (Resending mail after subscribing to list) > > Hi, > > This patch fixes a problem visible in Delta Force Land Warrior and > Delta Force Task Force Dagger, where extra_surfaces would sometimes > get a value of -1 and later cause a "near infinite" loop in > CreateAdditionalSurfaces. I think you should test that in the desc2.dwFlags & DDSD_MIPMAPCOUNT case above, where currently the "Mipmap count is given, nothing to do" comment is. It would be good if you extended the test case in dlls/ddraw/tests/dsurface.c to test the case where the mipmapcount flag is set, but the mipmap count is 0. It could either create a one-level surface (like your patch currently does), or ignore the mipmapcount flag, and create mipmaps until either width and height are 0.

2 2

Re: Window decorations missing on Compiz/Debian Etch
by Maarten Lankhorst Sept. 2, 2007

Sept. 2, 2007

Michael Jung schreef: > Hi Maarten, > > Thanks for pointing me to the FAQ. The FAQ entry seems to address > primarily OpenGL related issues, however, which I'm currently not > concerned about that much. Given the fact that the window decorations > used to work just fine before the mentioned patch, I would consider > this a regression. > > Bye, > -- > Michael Jung > mjung(a)iss.tu-darmstadt.de > Hi Michael, First of all, please do 'reply all' so a copy gets sent to wine-devel too. Second, if the bug only occurs with compiz/beryl it is really likely that it is a compiz/beryl bug., since it's not really a mature window manager, and has a lot of bugs, even not considering opengl. Cheers, Maarten

2 1

[RFC] [PATCH] GNU make based build system for Winelib applications
by Kirill Smelkov Sept. 2, 2007

Sept. 2, 2007

Hello Wine developers, Francois! I am going to port some Win32 applications to GNU/Linux and though it would be useful to improve the build system for Winelib applications. Current status and Motivation ============================= 1. Wine in-tree Makefiles for programs & dlls are pretty much good and maintainable, but they lack C++ support. 2. Initial approach taken by winemaker (I used it in 2003-2004) was to adapt Wine's make rules to support C++ . 3. At present winemaker dropped supplying above mentioned rules and generates very simple makefiles. To me this approach have several problems: - lack of dependency tracking - hard to maintain Makefiles. The rules generated are substituted in each Makefile instead of being in one place. - good as a starting point, but not a complete solution. Winemaker already relies on GNU toolchain (in form of gcc and g++), and I though:: Why not use GNU make with all available extensions when necessary, and deploy a simple full-featured build system for Winelib based applications The result is presented here for public review. Comments, suggestions? Features ======== * support C, C++ and resource files. * automatic dependency tracking for C and C++. * beautified build output (to increase SNR and concentrate on errors and warnings). * winemaker patches provided (although I don't know Perl -- help needed, Francois?). * Tested with GNU make 3.81. This version of GNU make was released in 2006 and is present in all recent Linux distributions. Usage example ============= I attach winelib-gnu-make.tar.gz where an interested reader can see Winemake build system usage. For usage example see directory clock+wow32/ . There I provide example of how to build 1 program and 2 dlls. Original clock.exe & wow32.dll processed by winemaker are located in misc/ for comparison.

1 0

Re: [5/5] WineD3D: texkill ignores the .w only in ps 1.x
by Tomas Carnecky Sept. 1, 2007

Sept. 1, 2007

+ + hr = IDirect3DDevice9_Clear(device, 0, NULL, D3DCLEAR_TARGET, 0xff00ff00, 0.0, 0); + ok(hr == D3D_OK, "IDirect3DDevice9_CreatePixelShader returned %s\n", DXGetErrorString9(hr)); Is that worth changing? tom

2 1

Re: secur32: Add some missing prototypes to ntsecapi.h.
by Kai Blin Sept. 1, 2007

Sept. 1, 2007

On Saturday 01 September 2007 02:45:33 Francois Gouget wrote: > --- > include/ntsecapi.h | 6 ++++++ > 1 files changed, 6 insertions(+), 0 deletions(-) Thanks, that was on my list, but I didn't get around to it yet. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

1 0

Re: [1/3] whhc - add chm compiler
by Vitaliy Margolen Aug. 31, 2007

Aug. 31, 2007

Miikka Viljanen wrote: > adds the whhc chm compiler under tools/whhc > > And what told you that you can just change the license from GPL to Wine's LGPL by just editing the header? Have you even asked authors of the program? Vitaliy.

1 0

Re: [PATCH] user32: edit control should respond to ctrl + z (try 2)
by Dmitry Timoshkov Aug. 31, 2007

Aug. 31, 2007

"Lei Zhang" <thestig(a)google.com> wrote: > This patch lets users hit ctrl + Z in edit controls to trigger an > undo. The test case has been improved to check for return values when > appropriate. > + /* select all, cut (ctrl-x), undo (ctrl-z) */ > + SendMessage(hwEdit, EM_SETSEL, 0, -1); > + r = SendMessage(hwEdit, WM_CHAR, 24, 0); > + todo_wine { ok(r == 1, "Expected: %d, got: %d\n", 1, r); } > + r = SendMessage(hwEdit, WM_CHAR, 26, 0); > + todo_wine { ok(r == 1, "Expected: %d, got: %d\n", 1, r); } By "I'd suggest to add checks to make sure that every message you send above really worked." I meant not simply check the SendMessage return values, but actual Edit contents/selection changes tracking. -- Dmitry.

1 0