May 2009 - Wine-Devel - list.winehq.org

Unused functions in fusion.dll
by Francois Gouget May 11, 2009

May 11, 2009

CompareAssemblyIdentity() and GetAssemblyIdentityFromFile() have stubs in fusion.c, but they are not used and not exported in any way. Is there any point in keeping them in their current state? Where/how should they be exported? A look at the fusion.dll export table on my Windows XP turned up nothing... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: Because rebooting is for adding new hardware

1 0

Re: wined3d: Fix ATI dx10 cards max varying quirk
by Stefan Dösinger May 11, 2009

May 11, 2009

Am Montag, 11. Mai 2009 02:51:29 schrieb Robert Key: > Changelog: > * This adds a quirk to change the default max varying value from > 68 to 48 on ATI dx10 cards that use fglrx because a declaration > of 17 varying vec4s causes shaders not to render and using > 48 (12 varyings vec4s) works for HD2000 to HD4000 ATI cards. > > Fixes bug #17437 I'm fine with putting the quirk in until fglrx is fixed. The ATI developers confirmed the bug and recommended this workaround for now. (I somewhere heard that their driver shipping latency is > 3 months for some reason) Looking at the code again I saw a few details I don't like though: +static BOOL match_fglrx_r600_to_700(const WineD3D_GL_Info *gl_info) { + if(gl_info->gl_vendor != VENDOR_ATI) return FALSE; + if(strstr(gl_info->gl_renderer, "DRI")) return FALSE; + if(gl_info->max_glsl_varyings == 68) return TRUE; + return FALSE; +} Maybe its better to compare max_glsl_varyings to > 44. 44 is the amount advertised on dx9 cards(and I think we fix this up somewhere already). The main question is if we want this quirk to disable itself as soon as the driver is fixed, or if we want to disable it manually. The other thing that bothers me is the replacement value 48 or 52: According to an ATI dev[1] the correct value is 64, which would match the dx10 limit of 16 varyings. Assuming we subtract 8 for the builtin primary and secondary color we're still at 56, not 52 or even 48. There's probably the fog color or the gl_ClipVertex "varying", but we're not using the clip vertex position currently. I think we should figure out where the 48 comes from. Can you play a bit with the attached program and see how many varyings you can declare, and if the builtin color varyings, fog coord or gl_ClipPos change anything? 1: http://ati.cchtml.com/show_bug.cgi?id=1462

1 0

Re: Simplify dlls/comctl32/rebar.c (RESEND)
by Dmitry Timoshkov May 11, 2009

May 11, 2009

"Gerald Pfeifer" <gerald(a)pfeifer.com> wrote: > static LRESULT > -REBAR_GetPalette (const REBAR_INFO *infoPtr, WPARAM wParam, LPARAM lParam) > +REBAR_GetPalette () > { (void) is mandatory, please don't omit it. -- Dmitry.

1 0

Re: regedit: remember settings state
by Dmitry Timoshkov May 11, 2009

May 11, 2009

"André Hentschel" <nerv(a)dawncrow.de> wrote: > LRESULT CALLBACK ChildWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) > { > +HKEY hKey; > +LPWSTR lpKeyPath; > switch (message) { > case WM_CREATE: Indentation is weird. And an empty line after variables won't hurt. -- Dmitry.

1 0

Re: comctl32: add ListView_SetCheckState and ListView_GetCheckState withtests(try4)
by Dmitry Timoshkov May 11, 2009

May 11, 2009

"André Hentschel" <nerv(a)dawncrow.de> wrote: > now with LVITEMW and SNDMSGW You are still casting to LPLVITEMA in ListView_SetCheckState while using LVITEMW and SNDMSGW. As been said by using SNDMSGW/LVITEMW you are making these macros incompatible with PSDK ones, and breaking compatibility if someone will try to compile a non-unicode application with Wine headers. -- Dmitry.

1 0

RFC: Removing the --use-cached-creds parameter from ntlm_auth
by Kai Blin May 11, 2009

May 11, 2009

Hi Rob, I've done some digging about using cached credentials from winbindd, and this currently breaks with how we use this from Wine. Specifically, it's not possible to get the session key from winbindd. This breaks our later attempts to do signing/sealing. It might be possible to change winbindd to include this information, but in order to not leak user password information, winbindd can only do so for NTLMv2 and NTLM2. In any case, --use-cached-creds will make things break in new and interesting ways for users who actually are running winbindd. I propose to stop setting that parameter until we figure out how to make this work. 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: wined3d: Fix ATI dx10 cards max varying quirk
by Henri Verbeet May 11, 2009

May 11, 2009

2009/5/11 Robert Key <hpestilence(a)gmail.com>: > Changelog: > * This adds a quirk to change the default max varying value from > 68 to 48 on ATI dx10 cards that use fglrx because a declaration > of 17 varying vec4s causes shaders not to render and using > 48 (12 varyings vec4s) works for HD2000 to HD4000 ATI cards. > R600 and r700 are supposed to be actively supported. But you know, I don't actually care anymore.

1 0

Re: Shuttleworth on Wine
by nn May 11, 2009

May 11, 2009

And the slashdot thread: Shuttleworth Says Ubuntu Can't Just Be Windows http://linux.slashdot.org/article.pl?sid=09/05/05/1546230 --- On Wed, 6/5/09, nn <saturn_systems(a)yahoo.com> wrote: > From: nn <saturn_systems(a)yahoo.com> > Subject: Shuttleworth on Wine > To: wine-devel(a)winehq.org > Received: Wednesday, 6 May, 2009, 9:04 AM > > Shuttleworth on Wine > http://www.osnews.com/story/21438/Shuttleworth_on_Wine > > > Yahoo!7 recommends that you update > your browser to the new Internet Explorer 8.Get it now. > > > The new Internet Explorer 8 optimised for Yahoo!7: Faster, Safer, Easier.

9 26

New icons for 1.1.21
by Scott Ritchie May 10, 2009

May 10, 2009

Hey everyone, I just wanted to say that the icon discussion I started a couple weeks back has born even more fruit, and I'm really happy with the current state of the icons that I'm now using in the 1.1.21 Ubuntu packages. I've attached them, and will be sending them as patches soon as well. I'm still not quite done with them, and they will likely change a bit after I get some UI feedback at the Ubuntu Developer Summit at the end of the month, but in the meantime I think they're quite better than what we have. Unlike the ubuntustudio icons I found (and packaged with 1.1.20 as an experiment), these should be a bit more visible (and fully tango-compliant). In particular, the stem of the glass is no longer two semitransparent pixels at normal 48x48 size, but instead has a full Tango border/inner brush stroke. Smaller icons for the other standard sizes are being worked on as well, however they have to be retouched individually to maintain the 1 pixel border/brush stroke in the Tango style. Eventually I'll submit a patch for our website's mini icon as well. Anyway, please feel free to give way too much feedback :) Thanks, Scott Ritchie

4 8

Re: dlls/ddraw/executebuffer.c: silence compiler warnings
by Stefan Dösinger May 10, 2009

May 10, 2009

> executebuffer.c:230: warning: comparison between 'D3DRENDERSTATETYPE' and > 'enum _D3DTRANSFORMSTATETYPE' executebuffer.c:232: warning: comparison > between 'D3DRENDERSTATETYPE' and 'enum _D3DTRANSFORMSTATETYPE' > executebuffer.c:234: warning: comparison between 'D3DRENDERSTATETYPE' and > 'enum _D3DTRANSFORMSTATETYPE' Does the attached patch fix the warning?

1 0

Re: DIB Engine : Almost 100% working
by Roderick Colenbrander May 10, 2009

May 10, 2009

> Office won't benefit at all, I'm afraid. Photoshop, maybe. > If sponsorship will be based on those apps, I guess we'll wait > forever :-) > > Max > > Photoshop is quite important for Wine (remember for 1.0 getting photoshop working was one of our main goals). There is still no serious Photoshop replacement for most companies which use Linux. Note that there are also others for obtaining the sponsoring and there is one about which I have been taking a lot but clear goals would need to be formulated for it and that would be a Wine fund raiser. We would raise money to get sponsorship for areas like this which else stay unfixed for years but money can also be used for Wineconf, buying hardware for patchwatcher, buying software for use on test machines, ..... Roderick

1 0

Re: Shuttleworth on Wine
by nn May 10, 2009

May 10, 2009

Great find added link to AppDB entry http://appdb.winehq.org/objectManager.php?sClass=version&iId=5392 Thanks. Nat --- On Mon, 11/5/09, Ken Sharp <kennybobs(a)o2.co.uk> wrote: > From: Ken Sharp <kennybobs(a)o2.co.uk> > Subject: Re: Shuttleworth on Wine > To: "Austin English" <austinenglish(a)gmail.com> > Cc: wine-devel(a)winehq.org > Received: Monday, 11 May, 2009, 12:04 AM > > > Austin English wrote: > > > It's the registering/download manager that makes it > not useful. It's > > much harder to script all of that. > > > > Is CS2 too old? > http://download.adobe.com/pub/adobe/photoshop/win/cs2/Photoshop_CS2.exe >

1 0

Re: Dynamically adding debug channels (__wine_dbg_set_channel_flags)
by Daniel Santos May 9, 2009

May 9, 2009

What I'm proposing shouldn't interfere with that. However, my original proposal is lacking (as I discovered when trying it out) because most of the object files that use debug logging end up with a static struct __wine_debug_channel variable that can't be changed from libwine after initialization. I think I just need to create a working solution and propose it as a patch. Performance is a pretty huge issue where, especially when running with WINEDEBUG=+all, so whatever I come up with will have to be very performance sensitive. Either way, the idea is to provide a mechanism for dynamically changing debug channels. Since this isn't something that many people should need (and especially not end users) this should be disabled by default. --- On Fri, 5/8/09, André Hentschel <nerv(a)dawncrow.de> wrote: From: André Hentschel <nerv(a)dawncrow.de> Subject: Re: Dynamically adding debug channels (__wine_dbg_set_channel_flags) To: daniel.santos(a)pobox.com, wine-devel(a)winehq.org Date: Friday, May 8, 2009, 7:07 AM The Problem with a pre-processor setting would be that the endusers may not be able to make good logs for the devs. At the moment you can say to a user "send a log using 'WINEDEBUG=commctrl wine program.exe'", the user doesnt have to know what he is doing exactly, but he sends a usefull text. That wouldnt be possible anymore as i understand it. Best regards André Hentschel Daniel Santos schrieb: > It would seem quite helpful for debugging odd situations to be able to turn debugging on and off programmatically. I like not having every debug class loaded in memory by default (and everything that goes with maintaining that global list), but it would seem quite helpful for troubleshooting, testing and debugging special cases (mostly where one doesn't have the sources of the troublesome app). > > Thus, perhaps __wine_dbg_set_channel_flags could add the debug channel to debug_options if it doesn't exist and even allow setting the default_flags (say by having a zero-length name in the channel argument) or even another function which would allow it. I'm not sure what thread synchronization implications this would bring about (and the associated costs of the sync objects), it seems it would require at the least the use of a critical section to modify the debug_options, but perhaps this can be a pre-processor driven option? The configure could have a --enable-dynamic-channels or some such that would set a pre-processor macro, etc. > > Alternatively, a cheaper (hackier) mechanism of thread-safety could be achived by having the debug_options be contained in a struct along with the nb_debug_options and have them heap-allocated so that the debug_options pointer could be changed in a single machine instruction. A similar mechanism (i.e., hack) could be use to free the old debug_options struct. That's ugly, but I'm just presenting options. > > Daniel > > > ------------------------------------------------------------------------ > > >

2 1

Re: comctl32: add ListView_SetCheckState and ListView_GetCheckState with tests(try3)
by Vitaliy Margolen May 9, 2009

May 9, 2009

André Hentschel wrote: > now using SNDMSGW > --- > dlls/comctl32/listview.c | 1 - > dlls/comctl32/tests/listview.c | 8 ++++++++ > include/commctrl.h | 6 ++++++ > 3 files changed, 14 insertions(+), 1 deletions(-) > > +#define ListView_SetCheckState(hwndLV, iIndex, bCheck) \ > + { LVITEMA _LVi; _LVi.state = ((bCheck?2:1) << 12); _LVi.stateMask = LVIS_STATEIMAGEMASK;\ > + SNDMSGW(hwndLV, LVM_SETITEMSTATE, (WPARAM)(INT)(iIndex), (LPARAM) (LPLVITEMA)&_LVi);} If you using SendMessageW you must use W structures (LVITEMW not LVITEMA). Also why are you typecasting WP & LP two times? Vitaliy.

1 0

Re: comctl32: add ListView_SetCheckState and ListView_GetCheckState with tests(try3)
by Nikolay Sivov May 9, 2009

May 9, 2009

André Hentschel wrote: > now using SNDMSGW > --- > dlls/comctl32/listview.c | 1 - > dlls/comctl32/tests/listview.c | 8 ++++++++ > include/commctrl.h | 6 ++++++ > 3 files changed, 14 insertions(+), 1 deletions(-) I still don't follow you. How will it run on systems without unicode support? In general it's better to correct all A-only macros to SNDMSG. This eliminates problem with missed SendMessageW and superfluous AtoW conversion when it's present. In native header ListView_SetCheckSate is implemented as a wrapper over ListView_SetItemState which in turn is defined as SNDMSG.

1 0

possible-wrong return value of PdhMakeCounterPathA
by Joris Huizer May 8, 2009

May 8, 2009

Obviously mostly a small and theoretical problem, but anyway: Looking at git commit 754b97c72c38f736100c6542af234c31a4bf7a5b, it seems, PdhMakeCounterPathA may be returning the wrong error in this case: Everything goes well until the allocation of bufferW. Assuming this fails, the function will return PDH_MORE_DATA, which seems the wrong error value (instead it should probably return PDH_MEMORY_ALLOCATION_FAILURE ? ) regards, Joris

1 0

Re: comctl32/test: test CheckState Macros
by Austin English May 8, 2009

May 8, 2009

2009/5/5 André Hentschel <nerv(a)dawncrow.de>: > --- > dlls/comctl32/tests/listview.c | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) This patch fails without your other patch. In the future, please combine them into one patch, or number them in a series. Wine must compile and pass the tests before and after every patch. -- -Austin

4 4

Dynamically adding debug channels (__wine_dbg_set_channel_flags)
by Daniel Santos May 8, 2009

May 8, 2009

It would seem quite helpful for debugging odd situations to be able to turn debugging on and off programmatically. I like not having every debug class loaded in memory by default (and everything that goes with maintaining that global list), but it would seem quite helpful for troubleshooting, testing and debugging special cases (mostly where one doesn't have the sources of the troublesome app). Thus, perhaps __wine_dbg_set_channel_flags could add the debug channel to debug_options if it doesn't exist and even allow setting the default_flags (say by having a zero-length name in the channel argument) or even another function which would allow it. I'm not sure what thread synchronization implications this would bring about (and the associated costs of the sync objects), it seems it would require at the least the use of a critical section to modify the debug_options, but perhaps this can be a pre-processor driven option? The configure could have a --enable-dynamic-channels or some such that would set a pre-processor macro, etc. Alternatively, a cheaper (hackier) mechanism of thread-safety could be achived by having the debug_options be contained in a struct along with the nb_debug_options and have them heap-allocated so that the debug_options pointer could be changed in a single machine instruction. A similar mechanism (i.e., hack) could be use to free the old debug_options struct. That's ugly, but I'm just presenting options. Daniel

2 1

Re: tools/winedump: sign compare fixes
by Alexandre Julliard May 8, 2009

May 8, 2009

Austin English <austinenglish(a)gmail.com> writes: > -static const char *debugstr_wn(const WCHAR *wstr, int n) > +static const char *debugstr_wn(const WCHAR *wstr, uint n) > { > static char buf[80]; > char *p; > - int i; > + uint i; uint is not a standard type. Use "unsigned int" instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Fwd: [Wine] How to Rip DVD and Convert video on OS X
by Austin English May 8, 2009

May 8, 2009

I know it's been mentioned a few times on wine-users, and the signup question was recently changed, but is there anything else we can do to prevent the forum spam? It's getting a bit out of hand. There is at least one message similar to the below daily. -- -Austin ---------- Forwarded message ---------- From: rahul6 <wineforum-user(a)winehq.org> Date: Fri, May 8, 2009 at 1:31 AM Subject: [Wine] How to Rip DVD and Convert video on OS X To: wine-users(a)winehq.org Now portable devices can be seen everywhere. They don't take so much space and are easy to use. Many people use their devices such as iPod, iPhone, PSP, Mobile Phone, Zune, Creative Zen, iRiver, Sansa, etc. to be served as their DVD Players or Video players. But the first thing kept in mind is that most such devices can not support DVD and some other video formats. But it is not difficult, some third-party conversion software such as Mac DVD Ripper

1 0

RE: Severity levels
by Nicklas Börjesson May 8, 2009

May 8, 2009

Hi all, it seems that some of my earlier mails(and some other) has been re-mailed to the list. I don't think that our(here, at my workplace) servers has done this, rather, it feels like the mailing list server did it. So understand that I am not bombarding the list. I see that many are replying to some really old posts. //Nicklas

1 0

Severity levels
by Nicklas Börjesson May 8, 2009

May 8, 2009

Hi all! First, I couldn't find any list more suitable than this one to comment the severity levels in the bug reporting so I post it here. If this was a really bad thing to do, please tell me were to do so. Secondly, don't take this wrong, I am not here to preach, I actually think this is a serious problem. I am not drunk either. Currently. :-) So, with regards to severity levels: Current severity levels are perfect for server applications where everything is simply about functionality working or not working. However, the overwhelming majority of windows applications in general, and those being ported through wine in particular are GUI-based, end-user applications. When it comes to these kinds of applications, in front of which actual people sit for hours on end doing actual work, other factors come into play. So I would like to introduce a bold new weight into the severity assessment: The user experience. Or at least the bugs' negative impact on it. The user experience(UE from here on) is really quite impossible to quantify exactly, luckily that is not usually necessary. There are several reasons to incorporate this into the severity classification, but I'll stop at two: 1. The ones reporting the bugs will come across with how severe they think the bug is to them. Currently, there is far too much of "you've got a almost black screen or black square instead of icons running Photoshop?..hmm that's really trivial...an 'UI glitch', but OK then, I'll mark it minor to be nice to ya." To a user, even an advanced one, this must feel like talking to a condescending Martian. Frustrating, if not infuriating. Likely, they will never again take the time to make a bug report. It is even quite likely that they will give up their move away from windows. 2. Currently, fixing a "trivial" UE-bug can make way more users happy than fixing a "normal" functionality-bug. This means that bug fixing is prioritized on a basis other than catering to the users needs. And to me, that's something that really shows. Can one defend this without invalidating the wine project? It is a serious question, I might have missed something fundamental. Anyway, I have some ideas on how to make the severity classifications better(and more intuitive for the mere user), but I won't go in to that now. I just want to know if any of you agree with me. Do I make a valid point? //Nicklas PS. I repost this since I didn't get any post from the server the first time. Also I expect this post to piss some off, which makes it even stranger not to get any replies at all. BTW, I also just read in a comment in a bug report that the severity flag doesn't mean much at all when it comes to how a bug is prioritized. So the only input the users have on how important a bug is to them is practically ignored? Why have that checkbox then? And why make such a big thing of it not being correctly set? DS.

10 55

msvcrt crash issue, tracing
by Kjell Rune Skaaraas May 7, 2009

May 7, 2009

Hello, I've been working for some time now trying to resolve bug 15817 because it's a kickass game that apart from one crashing issue works great under wine. The situation in brief is that it works with a msvcrt.dll override, but crashes randomly and sometimes consistantly using wine's stub. Now, when I run it with trace+msvcrt, it always crashes right after attaching a new thread: trace:msvcrt:MSVCRT_operator_delete (0x8edfda0) trace:msvcrt:DllMain (0x7e510000, DLL_THREAD_ATTACH, (nil)) pid(8), tid(28), tls(2) trace:msvcrt:MSVCRT_setlocale (4 (null)) err:seh:setup_exception_record stack overflow 1440 bytes in thread 0009 eip 7ef8c40e esp 02910d90 stack 0x2910000-0x2911000-0x2e10000 However, I've been looking at the functions in the trace and it doesn't seem to be any of these functions causing the crash. Now, having looked at what msvcrt.dll is, it's much, much more than these functions, it's the C Run-Time dll and contains lots of functions, most are probably very standard and so don't contain any TRACEs. The only thing I can think of being the cause is that it must be some sort of untraced function causing this. I'm sorta out of my depth here on fixing this thing, how would you go about solving it? I think I'd be 90% of the way there if I could just figure out what functions it's really calling. Is there any way to track every access to the DLL, and I mean every? Like say a wrapper that would output a trace line then it calls the wine/real DLL? Regards, Kjell Rune Skaaraas _________________________________________________________ Alt i ett. Få Yahoo! Mail med adressekartotek, kalender og notisblokk. http://no.mail.yahoo.com

2 1

Re: [5/5] wined3d: Add support for immediate constants to the GLSL backend.
by Stefan Dösinger May 7, 2009

May 7, 2009

Am Donnerstag, 7. Mai 2009 16:39:19 schrieb Henri Verbeet: I don't see an issue with the code in this patch, but did you find out anything new regarding the geforce 8 immval handling in the Nvidia driver? Remember the issue where my more-uniforms patch blew the constant limit because the driver encoded scalars as replicated vec4 immvals that still needed a full vec4 uniform for some reason? Was that a driver bug that is fixed in the newer drivers?

2 1

Re: Resend of xinput patch for bug 18218
by Austin English May 7, 2009

May 7, 2009

On Sun, May 3, 2009 at 7:12 PM, Rafał Mużyło <galtgendo(a)gmail.com> wrote: > I didn't put DllMain in this file, as it was not > in the current version, just added numbers and > sorted (latter probably unnecessary). > --- dlls/xinput1_3/xinput1_3_main.c.old 2009-04-25 16:54:42.000000000 +0200 > +++ dlls/xinput1_3/xinput1_3_main.c 2009-04-26 00:41:04.000000000 +0200 If possible, please use git diff. > @@ -95,12 +95,20 @@ > { > FIXME("(%d %d %p)\n", dwUserIndex, dwFlags, pCapabilities); > > + //pCapabilities = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(XINPUT_CAPABILITIES)); No C++ code/comments. Thanks for helping wine! -- -Austin

1 0