September 2007 - Wine-Devel

osalt.com top-requested commercial app stats

by Dan Kegel

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

Sept. 4, 2007

Re: shlwapi: Duplicate shell32.ShellMessageBoxW implementation in shlwapi.ShellMessageBoxWrapW

by Dmitry Timoshkov

"Reece Dunn" <msclrhd(a)googlemail.com> wrote: >> 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. It's possible, but after discussion with Alexandre it was decided that as long as the duplication is small enough it's not worth it. -- Dmitry.

Sept. 4, 2007

Re: shlwapi: Duplicate shell32.ShellMessageBoxW implementation in shlwapi.ShellMessageBoxWrapW

by Reece Dunn

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

Sept. 4, 2007

Re: comctl32: TCM_SETCURSEL also updates the focus item

by Reece Dunn

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

Sept. 4, 2007

re: Would like to contribute to wine

by Dan Kegel

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

Sept. 4, 2007

re: winhelp, Vector NTI, molecular biologists

by Dan Kegel

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

Sept. 4, 2007

Would like to contribute to wine

by Maciej Kowalczyk

Hi all, I'm looking for subject for my Master's thesis. It might be interesting to do something useful for Wine. On this year's Google SoC I found an interesting application called "Windows Printing subsystem bridge (i.e. use WIN32 drivers to print from wine)". It was accepted but I can't find any information about any progress. I think it is doable because Windows 2000 and later printer drivers are work in user-space. In suse repository I found ddiwrapper package. It does something similar but only for some Canon drivers and wraps to use by CUPS. Or maybe you have other ideas? Best regards, Maciej Kowalczyk

Sept. 4, 2007

Re: winhelp, Vector NTI, molecular biologists

by Misha Koshelev

On Mon, 2007-09-03 at 19:51 -0600, Jesse Allen wrote: > On 9/3/07, Misha Koshelev <mk144210(a)bcm.edu> wrote: > > 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). > > > > I think if these vendors are supplying programs that require these > dlls and do not provide them, then I think the person who buys this > program needs to take up the issue with the vendor. If I bought a > program and did not get the dll and do not have it, I essentially have > a dud, essentially since downloading the dlls is legally risky. > > Jesse Good point. In a way it seems kind of Microsoft's fault, since they are the ones who ultimately provide the Windows Script redistributable which requires MFC42.DLL but does not provide it (in fact, the accurate statement is that Windows Script redistributable installs "incorrectly" without MFC42.DLL; it does not give any errors and places all the correct DLLs in the right places, but does not write a bunch of registry keys like I believe Scriptable.Dictionary if I remember the name correctly and ends up failing on certain scripts). As for Vector NTI, I think one of the reasons it is so popular is because it is free for academic/research use, so technically I didn't pay for it, but yes I agree with you completely that companies should provide necessary DLLs with their products. Additionally, I checked on my "plain vanilla Win98 install" and actually it was _VMWare Tools_ that provided MFC42.DLL... go figure :) Misha

Sept. 3, 2007

Re: winhelp, Vector NTI, molecular biologists

by Jesse Allen

On 9/3/07, Misha Koshelev <mk144210(a)bcm.edu> wrote: > 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). > I think if these vendors are supplying programs that require these dlls and do not provide them, then I think the person who buys this program needs to take up the issue with the vendor. If I bought a program and did not get the dll and do not have it, I essentially have a dud, essentially since downloading the dlls is legally risky. Jesse

Sept. 3, 2007

Re: winhelp, Vector NTI, molecular biologists

by Misha Koshelev

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

Sept. 3, 2007

Re: winhelp, Vector NTI, molecular biologists

by Stefan Dösinger

Am Montag, 3. September 2007 16:02:54 schrieb Charity Abbott: > I wouldn't be too worried about the legal issue of using DLLs unless > you were planning on using it for a business. If you are, then you > should probably purchase a Windows license for each computer that has > to use those DLLs. Waste of money, but when it comes to the corporate > world, copyright infringement is taken much more seriously. Wine does target the corporate world, so we have to take extreme care not to violate the license of any single DLL. Microsoft would love a pretext to shut everything down.

Sept. 3, 2007

Re: winhelp, Vector NTI, molecular biologists

by Stefan Dösinger

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.

Sept. 3, 2007

Re: dsound: Runtime link to advapi32 RegDeleteTree

by Reece Dunn

On 03/09/07, Maarten Lankhorst <m.b.lankhorst(a)gmail.com> wrote: > Reece Dunn schreef: > > 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? > > > Yes, what other windows is there? Wine dsound works fine under windows. I was wondering if you meant Wine running as Windows XP. Thanks for the clarification. > >> 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. > > > Running a mingw compiled dsound in windows xp or earlier. In wine it > will work correctly even in xp mode. It may not be a bad idea to add a > function to libwine that can be used in case RegDeleteTree is > unavailable in advapi32. IIUC, libwine is a DLL that provides additional Wine-based helpers. If that is correct, then a RegDeleteTree could be implemented there. The question is how that is done. If the idea is that all Wine DLLs can be run on native Windows (most notably the DirectX DLLs), then this fallback mechanism applies to these as well. Therefore, it may be better to directly call a Wine equivalent of this API, such as the originally named RegDeleteTreeWine, in libwine to simplify the logic (i.e. no need to call GetProcAddress). Then, the advapi32 RegDeleteTree can forward to the libwine version, preventing code duplication. > > 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). > > > I am aware of that, however you can still use the native dsound to > unregister in those cases, which may not be ideal but should work. Sure. > >> +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. > > > If you check in the wine tree, other places use typeof too, so I didn't > think it would be that big an issue. If other places are using it then that is ok. - Reece

Sept. 3, 2007

Re: dsound: Runtime link to advapi32 RegDeleteTree

by Maarten Lankhorst

Reece Dunn schreef: > 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? > Yes, what other windows is there? Wine dsound works fine under 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. > Running a mingw compiled dsound in windows xp or earlier. In wine it will work correctly even in xp mode. It may not be a bad idea to add a function to libwine that can be used in case RegDeleteTree is unavailable in advapi32. > 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). > I am aware of that, however you can still use the native dsound to unregister in those cases, which may not be ideal but should work. >> +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. > If you check in the wine tree, other places use typeof too, so I didn't think it would be that big an issue. Cheers, Maarten

Sept. 3, 2007

Re: Hmm. Cider and the LGPL

by Kevin Krammer

On Friday 31 August 2007, Stefan Dösinger wrote: > Am Donnerstag, 30. August 2007 22:26 schrieb Dan Kegel: > > it'd be nice to have responses to questions like > > "The LGPL seems to give users the right to remove > > the LGPL'd portions of Cider from game A and use it > > with other apps. The gamers who are currently doing this > > are also copying proprietary parts of Cider, which isn't allowed. > > How will Transgaming prevent the copying of the proprietary > > parts of Cider without preventing the copying or modification > > of the LGPL portions?". > > Well, just link everything to the game and ask the 'porter' to rebuild the > LGPL'ed parts from source. I don't think the LGPL requires the binaries to > be reusable, the source should be enough. Or ask people to use Wine for > that business. My understanding is that it must be possible to change the LGPL part to to a modified one. In cases where the LGPL code is in a native shared library or in this case also in a DLL, it can be replaced by rebuilding that module from source and replacing the respective library file. In cases where the LGPL code is statically linked into an application, the rest of the application needs to be available in re-linkable form, e.g. object files. Cheers, Kevin

Sept. 3, 2007

Re: UbiSoft giving away games

by Kovács András

Hi, Rayman Raving Rabbids input related pateches isn't in because, it hason't been cleaned yet because ofl ack of time. If somebody interested in, i can send tha patch, that makes RRR to run. andras 2007. szeptember 2. 12.22 dátummal Stefan Dösinger ezt írta: > Am Sonntag, 2. September 2007 06:58 schrieb Michael Lothian: > > 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 > > PoP SoT also works, but I think it has some graphics troubles. Also it is > multithreaded, so it depends a bit on well-behaved drivers. > > Andras fixed a bug in Rayman Raving Rabbids some time ago(not d3d related I > afair, it was some input stuff), I think that game runs now too. > > Far Cry, as you say, runs properly in opengl mode, and d3d mode, at least > with 1.x shaders. 2.x shaders and hdr had some problems. It has input > troubles too. > > I would love it if they freed good old settlers 2 :-) I know it's available > on abadonware sites, but still :-)

Sept. 3, 2007

Re: regedit: fixed a memory leak in listview.c (found by Smatch).

by Dmitry Timoshkov

"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.

Sept. 3, 2007

Re: winhelp, Vector NTI, molecular biologists

by Charity Abbott

> 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. It would be unnecessary if software developers would check for needed .DLL's and install them if they are not present. This is not just a problem on wine. It occasionally arrises in Windows as well (although not as often). I recently bought a new laptop with Vista on it and was missing d3d9_30.dll for my Everquest game. EQ did not install it. Vista did not come with it. Neither did my default installation of direct X. I've seen this problem occur quite a few times on our guild's message board technical question section. I wouldn't be too worried about the legal issue of using DLLs unless you were planning on using it for a business. If you are, then you should probably purchase a Windows license for each computer that has to use those DLLs. Waste of money, but when it comes to the corporate world, copyright infringement is taken much more seriously. Individuals who want to appease their conscience should just find a Linux equivalent of the needed program, use Windows, or just download the DLLs and not worry about it. If you're morrally opposed to taking DLLs, then you should be morrally opposed to simulating Windows to get Windows programs to run. A can of worms, I know. I just keep seeing this issue come up. I'm not a lawyer, but using Microsoft's DLLs in a wine installation doesn't seem any different than installing Windows media player, Internet Explorer or MS office into wine. Some applications won't work in wine without them. Even if you paid for office, Microsoft expects you to run it on a Windows machine. Mac will run windows now you say? Yes, but you have to purchase a copy of Windows to do so. What if a small company got started by agreeing to develop for Windows? (Don't know an example, but I wouldn't put it past MS to make deals like that.) Then you take their program and run it on wine therefore violating their agreement? Anyway, I would examine the reason you're concerned about using the DLLs. Wine just doesn't bundle the needed DLLs because that would definately violate copy protection laws. It's an annoyance, but having someone develop a program like you suggest seems a little under the table. ;)

Sept. 3, 2007

Re: winhelp, Vector NTI, molecular biologists

by Misha Koshelev

> 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

Sept. 3, 2007

Re: winhelp, Vector NTI, molecular biologists

by Damjan Jovanovic

On 9/3/07, Misha Koshelev <mk144210(a)bcm.edu> wrote: > 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. Better winhelp is a goal of wine 1.0 (bug 664). > 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. 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. > So anyhow just my attempt to influence someone to start working on > winhelp. Sorry for cluttering your inboxes. > Misha > > > Damjan

Sept. 3, 2007

Re: ddraw: fix cases where desc2.u2.dwMipMapCount is 0.

by Stefan Dösinger

Am Sonntag, 2. September 2007 19:22 schrieb David Hedberg: > Hi again, > > I played around a bit with a simple test case, and it seems that my > first attempt at a patch was faulty. From what I can see and what the > test case says, windows does not allow the creation of these surfaces > at all. I've remade the patch to mimic the behaviour of windows, and > also added a test case. Even with this, delta force still seems to > work fine. > > Does this look ok? Yes, looks great, but you can send test and fix in one patch since both are small.

Sept. 3, 2007

Re: [PATCH 3 of 3] shell32: implement SHPathPrepareForWrite

by Dmitry Timoshkov

"Vincent Povirk" <madewokherd+d41d(a)gmail.com> wrote: > Well, I COULD do that if SHCreateDirectoryExW worked the way the Wine > API docs claim. It seems to be returning ERROR_ALREADY_EXISTS even > when the thing that already exists is a file and not a directory. Then it needs a separate test case and a fix. -- Dmitry.

Sept. 2, 2007

Re: [PATCH 3 of 3] shell32: implement SHPathPrepareForWrite

by Vincent Povirk

On 9/2/07, Vincent Povirk <madewokherd+d41d(a)gmail.com> wrote: > On 9/2/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > > By checking return value of SHCreateDirectoryExW you can make a shortcut > > in the deciding logic, in both cases: when the function fails you exit > > right away (returning *correct* error to the caller and not a guessed one), > > in the case of success GetFileAttributes call is redundant and you exit > > right away again. > > After looking into this a bit more, yes, one of those calls will > always be sufficient to do the work and determine what the result > should be, at least in the cases I tested. Which one depends on flags > and whether the path is relative (to my knowledge no apps actually use > relative paths). Well, I COULD do that if SHCreateDirectoryExW worked the way the Wine API docs claim. It seems to be returning ERROR_ALREADY_EXISTS even when the thing that already exists is a file and not a directory. -- Vincent Povirk

Sept. 2, 2007

Re: [PATCH 3 of 3] shell32: implement SHPathPrepareForWrite

by Vincent Povirk

On 9/2/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > "Vincent Povirk" <madewokherd+d41d(a)gmail.com> wrote: > > >> Why there is no check for SHCreateDirectoryExW return value? > > The return value of SHCreateDirectoryExW doesn't matter. All that > > matters is whether the directory exists when the function returns. It > > may or may not have existed when the function was called > > (SHCreateDirectoryExW fails when that happens, but > > SHPathPrepareForWrite should not fail). > > > > I could check the SHCreateDirectoryExW return value and probably > > decide on a result based on that, but I think it's better to write the > > result-deciding logic only once. > > By checking return value of SHCreateDirectoryExW you can make a shortcut > in the deciding logic, in both cases: when the function fails you exit > right away (returning *correct* error to the caller and not a guessed one), > in the case of success GetFileAttributes call is redundant and you exit > right away again. After looking into this a bit more, yes, one of those calls will always be sufficient to do the work and determine what the result should be, at least in the cases I tested. Which one depends on flags and whether the path is relative (to my knowledge no apps actually use relative paths). -- Vincent Povirk

Sept. 2, 2007

Re: [PATCH 3 of 3] shell32: implement SHPathPrepareForWrite

by Dmitry Timoshkov

"Vincent Povirk" <madewokherd+d41d(a)gmail.com> wrote: >> Why there is no check for SHCreateDirectoryExW return value? > The return value of SHCreateDirectoryExW doesn't matter. All that > matters is whether the directory exists when the function returns. It > may or may not have existed when the function was called > (SHCreateDirectoryExW fails when that happens, but > SHPathPrepareForWrite should not fail). > > I could check the SHCreateDirectoryExW return value and probably > decide on a result based on that, but I think it's better to write the > result-deciding logic only once. By checking return value of SHCreateDirectoryExW you can make a shortcut in the deciding logic, in both cases: when the function fails you exit right away (returning *correct* error to the caller and not a guessed one), in the case of success GetFileAttributes call is redundant and you exit right away again. -- Dmitry.

Sept. 2, 2007

winhelp, Vector NTI, molecular biologists

by Misha Koshelev

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

Sept. 2, 2007

Re: Window decorations missing on Compiz/Debian Etch

by Michael Jung

Hi Maarten, Maarten Lankhorst wrote: > Hi Michael, > > First of all, please do 'reply all' so a copy gets sent to wine-devel too. Oops, sorry. Will do. > 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. You're probably right. Will try to investigate a little further about what has really changed with regard to informing the window manager about decorations. And then go on and write a bug report to the Compiz/Beryl guys. Thanks, -- Michael Jung mjung(a)iss.tu-darmstadt.de

Sept. 2, 2007

Re: Window decorations missing on Compiz/Debian Etch

by Michael Jung

Hi, L. Rahyen wrote: > On Saturday September 1 2007 16:35, Michael Jung wrote: >> Hi all, >> >> since a couple of weeks all wine GUI applications are missing the window >> manager decorations on my Debian Etch box with the Compiz window >> manager. > > Have you tried to report this bug to Compiz developers? It really seems that > this is Compiz bug because the patch you are talking about cannot have such > side-effects. So I think you should report this to Compiz bugzilla. Yes, that's probably the right way to attack this problem. However, I'm going to investigate this a little further beforehand. Would like to figure out what this patch has changed with regard to informing the window manager that a window should have decorations. Thanks, -- Michael Jung mjung(a)iss.tu-darmstadt.de

Sept. 2, 2007

Re: Window decorations missing on Compiz/Debian Etch

by L. Rahyen

On Saturday September 1 2007 16:35, Michael Jung wrote: > Hi all, > > since a couple of weeks all wine GUI applications are missing the window > manager decorations on my Debian Etch box with the Compiz window > manager. Have you tried to report this bug to Compiz developers? It really seems that this is Compiz bug because the patch you are talking about cannot have such side-effects. So I think you should report this to Compiz bugzilla.

Sept. 2, 2007

Re: ddraw: fix cases where desc2.u2.dwMipMapCount is 0.

by David Hedberg

Hi again, I played around a bit with a simple test case, and it seems that my first attempt at a patch was faulty. From what I can see and what the test case says, windows does not allow the creation of these surfaces at all. I've remade the patch to mimic the behaviour of windows, and also added a test case. Even with this, delta force still seems to work fine. Does this look ok? David On 9/2/07, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > 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. > > >

Sept. 2, 2007

Re: IDirect3DImpl_EnumDevices only enumerating IID_IDirect3DTnLHalDevice

by Stefan Dösinger

Am Sonntag, 2. September 2007 14:15 schrieb David Hedberg: > While this works as a "fix", it's obviously not a good one. In my > (somewhat limited and at the moment not doublechecked) understanding, > windows "always" returns (at least) two devices, one reporting T&L > capable and one not. So I am wondering how one would implement a > proper fix for this in wine. It is quite likely that windows enumerates more than one device, but you have to keep an eye on the direct3d interface version. IDirect3D1 enumerates other devices than IDirect3D7, which is pretty tricky. IDirect3D7 only has HAL and TnLHal I think, others have HAL, TnLHal, MMX, RGB, Ramp. IDirect3D (1) does NOT enumerate the REF device. What you could do is to add a test in dlls/ddraw/tests/d3d.c for this. The test could enumerate the devices, and verify that if the TnlHal device is enumerated, HAL is enumerated too, or something like that, depending on what Windows really does. You've run into a pretty nasty and long-lasting problem here, a game that breaks with certain advertized or not advertized capabilities.

Sept. 2, 2007

Re: [PATCH 3 of 3] shell32: implement SHPathPrepareForWrite

by Vincent Povirk

On 9/2/07, Dmitry Timoshkov <dmitry(a)codeweavers.com> wrote: > It's better to not use fixed buffer sizes but allocate the buffer dynamically. OK. I avoided that because I didn't want to have to worry about freeing the buffer later when it's only needed in some cases. > If the job must be done only when SHPPFW_IGNOREFILENAME is specified then > don't do it in all cases. And using strrchrW would simplify the code a bit. OK. > Why there is no check for SHCreateDirectoryExW return value? The return value of SHCreateDirectoryExW doesn't matter. All that matters is whether the directory exists when the function returns. It may or may not have existed when the function was called (SHCreateDirectoryExW fails when that happens, but SHPathPrepareForWrite should not fail). I could check the SHCreateDirectoryExW return value and probably decide on a result based on that, but I think it's better to write the result-deciding logic only once. > 0x10b == 267, therefore 0x8007010b is HRESULT_FROM_WIN32(ERROR_DIRECTORY) <snip> > Please use above and in other places symbolic error names instead of hex, > and print expected and received codes to make life easier for those who looks > at the (failing) test results without looking at the source. OK. > For some reason your mailer attaches the patch in text and html formats, > it would save some time/traffic by avoiding html in wine-patches. *checks* So it does. I should be able to avoid that now that I know to look for it. -- Vincent Povirk

Sept. 2, 2007

Re: [PATCH 3 of 3] shell32: implement SHPathPrepareForWrite

by Dmitry Timoshkov

"Vincent Povirk" <madewokherd(a)gmail.com> wrote: > HRESULT WINAPI SHPathPrepareForWriteA(HWND hwnd, IUnknown *modless, LPCSTR path, DWORD flags) > { > - FIXME("%p %p %s 0x%08x\n", hwnd, modless, debugstr_a(path), flags); > - return S_OK; > + WCHAR wpath[MAX_PATH]; > + MultiByteToWideChar( CP_ACP, 0, path, -1, wpath, MAX_PATH); > + return SHPathPrepareForWriteW(hwnd, modless, wpath, flags); It's better to not use fixed buffer sizes but allocate the buffer dynamically. > + /* make a copy of the path so we can cut off the filename */ > + for (i=0; i<MAX_PATH; i++) > + { > + realpath[i] = path[i]; > + if (path[i] == '\\') > + last_slash = i; > + else if (path[i] == 0) > + break; > + } > + realpath[MAX_PATH-1] = 0; > + > + if (flags & SHPPFW_IGNOREFILENAME) > + realpath[last_slash] = 0; If the job must be done only when SHPPFW_IGNOREFILENAME is specified then don't do it in all cases. And using strrchrW would simplify the code a bit. > + /* try to create the directory if asked to */ > + if (flags & (SHPPFW_DIRCREATE|SHPPFW_ASKDIRCREATE)) > + { > + if (flags & SHPPFW_ASKDIRCREATE) > + FIXME("treating SHPPFW_ASKDIRCREATE as SHPPFW_DIRCREATE\n"); > + > + SHCreateDirectoryExW(0, realpath, NULL); > + } Why there is no check for SHCreateDirectoryExW return value? > + > + /* check if we can access the directory */ > + res = GetFileAttributesW(realpath); > + > + if (res == INVALID_FILE_ATTRIBUTES) > + { > + err = GetLastError(); > + if (err == ERROR_FILE_NOT_FOUND) > + err = ERROR_PATH_NOT_FOUND; > + return HRESULT_FROM_WIN32(err); > + } > + else if (res & FILE_ATTRIBUTE_DIRECTORY) > + return S_OK; > + else > + return 0x8007010b; 0x10b == 267, therefore 0x8007010b is HRESULT_FROM_WIN32(ERROR_DIRECTORY) > --- a/dlls/shell32/tests/shpathprep.c > +++ b/dlls/shell32/tests/shpathprep.c > @@ -82,27 +82,27 @@ START_TEST(shpathprep) > ok(res == S_OK, "res == 0x%08x\n", res); > > res = SHPathPrepareForWriteA(0, 0, "c:\\testdir\\nonexistent", SHPPFW_NONE); > - todo_wine ok(res == 0x80070003, "res == 0x%08x\n", res); > + ok(res == 0x80070003, "res == 0x%08x\n", res); Please use above and in other places symbolic error names instead of hex, and print expected and received codes to make life easier for those who looks at the (failing) test results without looking at the source. For some reason your mailer attaches the patch in text and html formats, it would save some time/traffic by avoiding html in wine-patches. -- Dmitry.

Sept. 2, 2007

Re: Window decorations missing on Compiz/Debian Etch

by Maarten Lankhorst

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

Sept. 2, 2007

Re: ddraw: fix cases where desc2.u2.dwMipMapCount is 0.

by Stefan Dösinger

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.

Sept. 2, 2007

IDirect3DImpl_EnumDevices only enumerating IID_IDirect3DTnLHalDevice

by David Hedberg

(Resending mail after subscribing to list) Hi, I've been tracking down the reason for bug 7993 ( http://bugs.winehq.org/show_bug.cgi?id=7993 , "Delta Force Land Warrior 1.31 -> Can't find 3D Video Card" ), and I think I've found it. It appears as if the EnumDevices callback in Delta Force for some reason discards all devices with a GUID of IID_IDirect3DTnLHalDevice, thus discarding the only device enumerated by wine. This is "easily" checked (and bypassed) by searching for and altering the IID_IDirect3DTnLHalDevice value used in the check (78 9E 04 F5 (..) ) in the delta force executable. While this works as a "fix", it's obviously not a good one. In my (somewhat limited and at the moment not doublechecked) understanding, windows "always" returns (at least) two devices, one reporting T&L capable and one not. So I am wondering how one would implement a proper fix for this in wine. Fixing this together with applying (or otherwise fixing the issue highlighted in) the patch at http://flodaby.ath.cx/~david/0001-ddraw-fix-cases-where-desc2.u2.dwMipMapCo… (also sent to wine-patches), would enable both Delta Force Land Warrior and Delta Force Task Force Dagger to run great with wine. David

Sept. 2, 2007

[RFC] [PATCH] GNU make based build system for Winelib applications

by Kirill Smelkov

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.

Sept. 2, 2007

IDirect3DImpl_EnumDevices only enumerating IID_IDirect3DTnLHalDevice

by David Hedberg

Hi, I've been tracking down the reason for bug 7993 ( http://bugs.winehq.org/show_bug.cgi?id=7993 , "Delta Force Land Warrior 1.31 -> Can't find 3D Video Card" ), and I think I've found it. It appears as if the EnumDevices callback in Delta Force for some reason discards all devices with a GUID of IID_IDirect3DTnLHalDevice, thus discarding the only device enumerated by wine. This is "easily" checked (and bypassed) by searching for and altering the IID_IDirect3DTnLHalDevice value used in the check (78 9E 04 F5 (..) ) in the delta force executable. While this works as a "fix", it's obviously not a good one. In my (somewhat limited and at the moment not doublechecked) understanding, windows "always" returns (at least) two devices, one reporting T&L capable and one not. So I am wondering how one would implement a proper fix for this in wine. Fixing this together with applying (or otherwise fixing the issue highlighted in) the patch at http://flodaby.ath.cx/~david/0001-ddraw-fix-cases-where-desc2.u2.dwMipMapCo… (also sent to wine-patches), would enable both Delta Force Land Warrior and Delta Force Task Force Dagger to run great with wine. David

Sept. 2, 2007

Re: UbiSoft giving away games

by Stefan Dösinger

Am Sonntag, 2. September 2007 06:58 schrieb Michael Lothian: > 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 PoP SoT also works, but I think it has some graphics troubles. Also it is multithreaded, so it depends a bit on well-behaved drivers. Andras fixed a bug in Rayman Raving Rabbids some time ago(not d3d related I afair, it was some input stuff), I think that game runs now too. Far Cry, as you say, runs properly in opengl mode, and d3d mode, at least with 1.x shaders. 2.x shaders and hdr had some problems. It has input troubles too. I would love it if they freed good old settlers 2 :-) I know it's available on abadonware sites, but still :-)

Sept. 2, 2007

UbiSoft giving away games

by Michael Lothian

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

Sept. 1, 2007

Re: dsound: Runtime link to advapi32 RegDeleteTree

by Reece Dunn

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

Sept. 1, 2007

Re: Window decorations missing on Compiz/Debian Etch

by Maarten Lankhorst

2007/9/1, Michael Jung <mjung(a)iss.tu-darmstadt.de>: > Hi all, > > since a couple of weeks all wine GUI applications are missing the window > manager decorations on my Debian Etch box with the Compiz window > manager. I did'nt get to doing a bisect until today. The problematic > patch seems to be: Compiz is a broken window manager, bug is in compiz not wine. If you would read the FAQ you would have known that! Maarten

Sept. 1, 2007

Window decorations missing on Compiz/Debian Etch

by Michael Jung

Hi all, since a couple of weeks all wine GUI applications are missing the window manager decorations on my Debian Etch box with the Compiz window manager. I did'nt get to doing a bisect until today. The problematic patch seems to be: --- commit ac98e0c07535af4a373c0af343498903e2ff42a6 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Mon Aug 20 22:06:33 2007 +0200 winex11: Switch windows to managed mode in SetWindowPos instead of at creation time. --- Anybody else seeing this problem? I'll attach a +x11drv log from starting up notepad with a current version of wine as of today (wine-0.9.44-g282696b). Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de libGL warning: 3D driver claims to not support visual 0x4b trace:x11drv:xinerama_init monitor 0x1: (0,0)-(1024,768) (primary) trace:x11drv:xinerama_init virtual size: (0,0)-(1024,768) primary size: 1024x768 trace:x11drv:X11DRV_SetupXIM X display of IM = 0x7c1a3f38 trace:x11drv:X11DRV_SetupXIM Using en_US.UTF-8 locale of Input Method trace:x11drv:X11DRV_SetupXIM ximStyles->count_styles = 2 trace:x11drv:X11DRV_SetupXIM ximStyles[0] = XIMPreeditNone trace:x11drv:X11DRV_SetupXIM ximStyles[1] = XIMPreeditNothing trace:x11drv:X11DRV_SetupXIM Setting Style: ximStyleRoot = STYLE_ROOT trace:x11drv:X11DRV_SetupXIM No callback style avalable trace:x11drv:X11DRV_CreateBitmap (0x1a4) 32x32 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x1a8) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1a8, buffer=0x38065c, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1a4, buffer=0x3806dc, count=0x80) trace:x11drv:X11DRV_CreateBitmap (0x1ac) 32x32 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x1b0) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1b0, buffer=0x380784, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1ac, buffer=0x380804, count=0x80) trace:x11drv:X11DRV_CreateBitmap (0x1c0) 16x16 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x1c4) 16x16 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1c4, buffer=0x3808ac, count=0x20) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1c0, buffer=0x3808cc, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x1c8) 16x16 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x1cc) 16x16 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1cc, buffer=0x380bf4, count=0x20) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1c8, buffer=0x380c14, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x1d0) 16x16 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x1d4) 16x16 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1d4, buffer=0x380f3c, count=0x20) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1d0, buffer=0x380f5c, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x210) 64x16 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x248) 128x32 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x264) 16x16 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x268) 16x16 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x268, buffer=0x381284, count=0x20) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x264, buffer=0x3812a4, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x26c) 32x32 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x270) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x270, buffer=0x3815cc, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x26c, buffer=0x38164c, count=0xc00) trace:x11drv:X11DRV_CreateBitmap (0x274) 16x16 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x278) 16x16 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x278, buffer=0x382274, count=0x20) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x274, buffer=0x382294, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x27c) 16x16 24 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x27c, bits=0x121308, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x280) 16x16 1 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x280, bits=0x120ff0, count=0x20) trace:x11drv:X11DRV_CreateBitmap (0x290) 32x32 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x294) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x294, buffer=0x382274, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x290, buffer=0x3822f4, count=0xc00) trace:x11drv:X11DRV_CreateBitmap (0x298) 32x32 24 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x298, bits=0x121308, count=0xc00) trace:x11drv:X11DRV_CreateBitmap (0x29c) 32x32 1 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x29c, bits=0x121f10, count=0x80) trace:x11drv:X11DRV_CreateBitmap (0x2ac) 16x16 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x2b0) 16x16 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x2b0, buffer=0x382274, count=0x20) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x2ac, buffer=0x382294, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x2cc) 64x144 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x2b4) 16x16 24 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x2b4, bits=0x121308, count=0x300) trace:x11drv:X11DRV_CreateBitmap (0x2b8) 16x16 1 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x2b8, bits=0x121660, count=0x20) trace:x11drv:X11DRV_CreateBitmap (0x2dc) 32x32 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x2e0) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x2e0, buffer=0x382274, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x2dc, buffer=0x3822f4, count=0xc00) trace:x11drv:X11DRV_CreateBitmap (0x2fc) 128x288 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x2e4) 32x32 24 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x2e4, bits=0x121ad0, count=0xc00) trace:x11drv:X11DRV_CreateBitmap (0x2e8) 32x32 1 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x2e8, bits=0x120378, count=0x80) trace:x11drv:X11DRV_CreateBitmap (0x30c) 32x32 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x310) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x310, buffer=0x382274, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x30c, buffer=0x3822f4, count=0xc00) libGL warning: 3D driver claims to not support visual 0x4b trace:x11drv:xinerama_init monitor 0x1: (0,0)-(1024,768) (primary) trace:x11drv:xinerama_init virtual size: (0,0)-(1024,768) primary size: 1024x768 trace:x11drv:X11DRV_SetupXIM X display of IM = 0x7c06e720 trace:x11drv:X11DRV_SetupXIM Using en_US.UTF-8 locale of Input Method trace:x11drv:X11DRV_SetupXIM ximStyles->count_styles = 2 trace:x11drv:X11DRV_SetupXIM ximStyles[0] = XIMPreeditNone trace:x11drv:X11DRV_SetupXIM ximStyles[1] = XIMPreeditNothing trace:x11drv:X11DRV_SetupXIM Setting Style: ximStyleRoot = STYLE_ROOT trace:x11drv:X11DRV_SetupXIM No callback style avalable trace:x11drv:X11DRV_CreateBitmap (0x1a4) 32x32 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x1a8) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1a8, buffer=0x39065c, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1a4, buffer=0x3906dc, count=0x80) trace:x11drv:X11DRV_CreateBitmap (0x1ac) 32x32 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x1b0) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1b0, buffer=0x390784, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1ac, buffer=0x390804, count=0x80) trace:x11drv:X11DRV_SetWindowPos win 0x10020 window (0,0)-(1024,768) client (0,0)-(1024,768) style 86000000 trace:x11drv:X11DRV_CreateWindow hwnd 0x10020 cs 0,0 1024x768 trace:x11drv:X11DRV_CreateWindow win 0x10020 window 0,0,1024,768 client 0,0,1024,768 whole 0,0,1024,768 X client 0,0,1024,768 xwin 4d trace:x11drv:X11DRV_ShowWindow hwnd=0x10020, cmd=5, wasVisible 0 trace:x11drv:X11DRV_CreateBitmap (0x1d4) 32x32 24 bpp trace:x11drv:X11DRV_CreateBitmap (0x1d8) 32x32 1 bpp trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1d8, buffer=0x3908ac, count=0x80) trace:x11drv:X11DRV_GetBitmapBits (bmp=0x1d4, buffer=0x39092c, count=0xc00) trace:x11drv:X11DRV_SetWindowPos win 0x10022 window (0,0)-(0,0) client (0,0)-(0,0) style 04c00000 trace:x11drv:X11DRV_SetWindowPos making win 0x10022/4000001 managed trace:x11drv:X11DRV_SetWindowPos win 0x10022 window (0,0)-(0,0) client (0,0)-(0,0) style 04c00000 trace:x11drv:X11DRV_CreateWindow hwnd 0x10022 cs 0,0 0x0 trace:x11drv:X11DRV_SetWindowPos win 0x10022 window (0,0)-(0,0) client (3,22)-(3,22) style 04c00000 trace:x11drv:X11DRV_sync_window_position setting win 4000001 pos 0,0,0x0 after 7ecb8ec0 changes=40 trace:x11drv:X11DRV_CreateWindow win 0x10022 window 0,0,0,0 client 3,22,3,22 whole 0,0,0,0 X client 3,22,3,22 xwin 4000001 trace:x11drv:X11DRV_SetWindowPos win 0x10024 window (153,75)-(861,599) client (153,75)-(861,599) style 04cf0000 trace:x11drv:X11DRV_SetWindowPos making win 0x10024/3c00001 managed trace:x11drv:X11DRV_SetWindowPos win 0x10024 window (153,75)-(861,599) client (153,75)-(861,599) style 04cf0000 trace:x11drv:X11DRV_sync_window_position setting win 3c00001 pos 157,98,700x497 after 4 changes=f trace:x11drv:X11DRV_CreateWindow hwnd 0x10024 cs 153,75 708x524 trace:x11drv:X11DRV_CreateBitmap (0x33c) 7x11 1 bpp trace:x11drv:X11DRV_CreateBitmap (0x34c) 7x11 1 bpp trace:x11drv:X11DRV_SetWindowPos win 0x10024 window (153,75)-(861,599) client (157,117)-(857,595) style 04cf0000 trace:x11drv:X11DRV_sync_window_position setting win 3c00001 pos 157,98,700x497 after 4 changes=40 trace:x11drv:X11DRV_CreateWindow win 0x10024 window 153,75,861,599 client 157,117,857,595 whole 157,98,857,595 X client 0,19,700,497 xwin 3c00001 trace:x11drv:X11DRV_SetWindowPos win 0x10026 window (0,0)-(700,478) client (0,0)-(700,478) style 40a00144 trace:x11drv:X11DRV_CreateWindow hwnd 0x10026 cs 0,0 700x478 trace:x11drv:X11DRV_SetWindowPos win 0x10026 window (0,0)-(700,478) client (3,3)-(681,475) style 40a00144 trace:x11drv:X11DRV_CreateWindow win 0x10026 window 0,0,700,478 client 3,3,681,475 whole 0,0,700,478 X client 3,3,681,475 xwin 0 trace:x11drv:X11DRV_ShowWindow hwnd=0x10026, cmd=5, wasVisible 0 trace:x11drv:X11DRV_CreateBitmap (0x404) 2x13 1 bpp trace:x11drv:X11DRV_ShowWindow hwnd=0x10024, cmd=1, wasVisible 0 trace:x11drv:X11DRV_SetWindowPos win 0x10024 window (153,75)-(861,599) client (157,117)-(857,595) style 14cf0000 trace:x11drv:X11DRV_sync_window_position setting win 3c00001 pos 157,98,700x497 after 359 changes=40 trace:x11drv:X11DRV_SetWindowPos mapping win 0x10024 trace:x11drv:X11DRV_CreateBitmap (0x420) 32x32 1 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x420, bits=0x1266f0, count=0x80) trace:x11drv:X11DRV_CreateBitmap (0x41c) 32x32 24 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x41c, bits=0x1269e8, count=0xc00) trace:x11drv:update_fullscreen_state setting fullscreen state for window 3c00001 to false trace:x11drv:X11DRV_SetWindowPos win 0x10026 window (0,0)-(700,478) client (3,3)-(681,475) style 50a00144 trace:x11drv:X11DRV_Expose win 0x10024 (3c00001) 0,0 700x497 trace:x11drv:X11DRV_CreateBitmap (0x194) 8x8 1 bpp trace:x11drv:X11DRV_SetBitmapBits (bmp=0x194, bits=0x1189a0, count=0x10) trace:x11drv:X11DRV_SetWindowPos win 0x10024 window (153,75)-(861,599) client (157,117)-(857,595) style 04cf0000 trace:x11drv:X11DRV_SetWindowPos unmapping win 0x10024 trace:x11drv:destroy_whole_window win 0x10024 xwin 3c00001

Sept. 1, 2007

Re: [5/5] WineD3D: texkill ignores the .w only in ps 1.x

by Stefan Dösinger

Am Freitag, 31. August 2007 23:30 schrieb Tomas Carnecky: > + > + 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? Ooops yes, that ok() isn't quite right

Sept. 1, 2007

Re: secur32: Add some missing prototypes to ntsecapi.h.

by Kai Blin

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.

Sept. 1, 2007

Re: [1/3] whhc - add chm compiler

by Vitaliy Margolen

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.

Aug. 31, 2007

Re: [PATCH] user32: edit control should respond to ctrl + z (try 2)

by Dmitry Timoshkov

"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.

Aug. 31, 2007