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

Re: DIB Engine : Almost 100% working
by Roderick Colenbrander 10 May '09

10 May '09

> 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 10 May '09

10 May '09

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 09 May '09

09 May '09

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 09 May '09

09 May '09

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 09 May '09

09 May '09

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 08 May '09

08 May '09

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 08 May '09

08 May '09

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 08 May '09

08 May '09

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 08 May '09

08 May '09

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 08 May '09

08 May '09

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