October 2010 - Wine-Devel - list.winehq.org

Re: [PATCH 3/8] jscrpt: Added VBScript.lbound() implementation

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6281 Your paranoid android. === W98SE (32 bit) === No test summary line found === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

Oct. 18, 2010

Re: [PATCH 2/2] ntdll: Check for case-insensitive volumes.

by Alexandre Julliard

Charles Davis <cdavis(a)mymail.mines.edu> writes: > Only if the file system doesn't preserve case. Most modern > case-insensitive file systems (FAT, NTFS, HFS) preserve case. CIOPFS > preserves case if it's allowed to write xattrs to the underlying FS. > This is why I even had the case-preserving handling in there in the > first place. > > So, if I understand correctly, you think that, if we determine that file > system is case-insensitive, we should also assume it doesn't preserve > case. Is that correct? No. The check_case flag is used to specify Unix semantics, but Unix semantics on a case-insensitive filesystem are just the same as Windows. It doesn't make sense to try to be more case sensitive than the filesystem. -- Alexandre Julliard julliard(a)winehq.org

Oct. 18, 2010

Re: [PATCH 2/2] ntdll: Check for case-insensitive volumes.

by Charles Davis

On 10/18/10 10:57 AM, Alexandre Julliard wrote: > Charles Davis <cdavis(a)mymail.mines.edu> writes: > >> When I wrote that, I was thinking, "If we do the stat() on a >> case-insensitive file system, it will succeed even if the filename has >> the wrong case. We don't want that when we're checking case, so we may >> as well read the dirents to see if the file exists with the right case." >> Is there something I'm missing? Would check_case even matter when >> case_sensitive is FALSE? > > If the file system is not case sensitive then there's no case to check. Only if the file system doesn't preserve case. Most modern case-insensitive file systems (FAT, NTFS, HFS) preserve case. CIOPFS preserves case if it's allowed to write xattrs to the underlying FS. This is why I even had the case-preserving handling in there in the first place. So, if I understand correctly, you think that, if we determine that file system is case-insensitive, we should also assume it doesn't preserve case. Is that correct? Chip

Oct. 18, 2010

Re: [PATCH 2/2] ntdll: Check for case-insensitive volumes.

by Alexandre Julliard

Charles Davis <cdavis(a)mymail.mines.edu> writes: > When I wrote that, I was thinking, "If we do the stat() on a > case-insensitive file system, it will succeed even if the filename has > the wrong case. We don't want that when we're checking case, so we may > as well read the dirents to see if the file exists with the right case." > Is there something I'm missing? Would check_case even matter when > case_sensitive is FALSE? If the file system is not case sensitive then there's no case to check. -- Alexandre Julliard julliard(a)winehq.org

Oct. 18, 2010

Re: [PATCH 1/8] jscript: Added VBArray stub

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6279 Your paranoid android. === W98SE (32 bit) === No test summary line found === WNT4WSSP6 (32 bit) === No test summary line found === W2KPROSP4 (32 bit) === No test summary line found === WXPPROSP3 (32 bit) === No test summary line found === W2K3R2SESP2 (32 bit) === No test summary line found === WVISTAADM (32 bit) === No test summary line found === W2K8SE (32 bit) === No test summary line found === W7PRO (32 bit) === No test summary line found === W7PROX64 (32 bit) === No test summary line found === W7PROX64 (64 bit) === No test summary line found

Oct. 18, 2010

Re: [PATCH 2/2] ntdll: Check for case-insensitive volumes.

by Charles Davis

On 10/18/10 8:28 AM, Alexandre Julliard wrote: > Charles Davis <cdavis(a)mymail.mines.edu> writes: > >> @@ -1828,13 +2054,24 @@ static NTSTATUS find_file_in_dir( char *unix_name, int pos, const WCHAR *name, i >> if (ret >= 0 && !used_default) >> { >> unix_name[pos + ret] = 0; >> - if (!stat( unix_name, &st )) >> + /* when checking case on a case insensitive but case preserving >> + * fs, don't even bother doing the stat(), so we don't match the >> + * file case-insensitively. >> + */ >> + if ((case_sensitive || !check_case) && !stat( unix_name, &st )) >> { >> if (is_win_dir) *is_win_dir = is_same_file( &windir, &st ); >> return STATUS_SUCCESS; >> } > > This still doesn't make sense. There's no reason to ever skip the stat. When I wrote that, I was thinking, "If we do the stat() on a case-insensitive file system, it will succeed even if the filename has the wrong case. We don't want that when we're checking case, so we may as well read the dirents to see if the file exists with the right case." Is there something I'm missing? Would check_case even matter when case_sensitive is FALSE? > >> @@ -2455,6 +2713,10 @@ static NTSTATUS lookup_unix_name( const WCHAR *name, int name_len, char **buffer >> const WCHAR *end, *next; >> int is_win_dir = 0; >> >> + unix_name[pos] = 0; >> + stat( unix_name, &st ); >> + unix_name[pos] = '/'; > > You can't add extra stat calls to the normal path. This is supposed to > be an optimization. Yeah, you're right, as usual. I'll fix this in try 4. Chip

Oct. 18, 2010

Re: About: [PATCH 2/2] ntdll: Check for case-insensitive volumes.

by Charles Davis

On 10/18/10 8:10 AM, Joris Huizer wrote: > Hello, > > In the proposed patch "[PATCH 2/2] ntdll: Check for case-insensitive volumes.", I found this piece: > > + /* Add a new entry */ > + for (i = 0; i < sizeof(fs_cache)/sizeof(fs_cache[0]); i++) > + if (fs_cache[i].dev == 0) > + { > + /* This entry is empty, use it */ > + fs_cache[i].dev = dev; > + fs_cache[i].fsid = fsid; > + fs_cache[i].case_sensitive = case_sensitive; > + } > > Maybe I'm missing something, but shouldn't you return from the function when finding a cache entry to fill? This seems to be filling every empty > cache entry? Ah, you're right. I'll fix this in try 4. Chip

Oct. 18, 2010

Re: [PATCH 2/2] ntdll: Check for case-insensitive volumes.

by Alexandre Julliard

Charles Davis <cdavis(a)mymail.mines.edu> writes: > @@ -1828,13 +2054,24 @@ static NTSTATUS find_file_in_dir( char *unix_name, int pos, const WCHAR *name, i > if (ret >= 0 && !used_default) > { > unix_name[pos + ret] = 0; > - if (!stat( unix_name, &st )) > + /* when checking case on a case insensitive but case preserving > + * fs, don't even bother doing the stat(), so we don't match the > + * file case-insensitively. > + */ > + if ((case_sensitive || !check_case) && !stat( unix_name, &st )) > { > if (is_win_dir) *is_win_dir = is_same_file( &windir, &st ); > return STATUS_SUCCESS; > } This still doesn't make sense. There's no reason to ever skip the stat. > @@ -2455,6 +2713,10 @@ static NTSTATUS lookup_unix_name( const WCHAR *name, int name_len, char **buffer > const WCHAR *end, *next; > int is_win_dir = 0; > > + unix_name[pos] = 0; > + stat( unix_name, &st ); > + unix_name[pos] = '/'; You can't add extra stat calls to the normal path. This is supposed to be an optimization. -- Alexandre Julliard julliard(a)winehq.org

Oct. 18, 2010

Re: About: msxml3: Partially implement ::setAttributeNode()

by Nikolay Sivov

On 10/18/2010 18:21, Joris Huizer wrote: > Hello, > > In proposed patch msxml3: Partially implement ::setAttributeNode() > I think I found a little possible memory leak: > > + name = xmlChar_from_wchar(nameW); > + value = xmlChar_from_wchar(V_BSTR(&valueW)); > + > + if (!name || !value) > + { > + SysFreeString(nameW); > + VariantClear(&valueW); > + return E_OUTOFMEMORY; > + } > > Wouldn't you need to free memory allocated for both name and value, in case one of the allocations succeeded ? Yes, I already spotted this, will resend whole set anyway. > HTH, > Joris

Oct. 18, 2010

About: msxml3: Partially implement ::setAttributeNode()

by Joris Huizer

Hello, In proposed patch msxml3: Partially implement ::setAttributeNode() I think I found a little possible memory leak: + name = xmlChar_from_wchar(nameW); + value = xmlChar_from_wchar(V_BSTR(&valueW)); + + if (!name || !value) + { + SysFreeString(nameW); + VariantClear(&valueW); + return E_OUTOFMEMORY; + } Wouldn't you need to free memory allocated for both name and value, in case one of the allocations succeeded ? HTH, Joris

Oct. 18, 2010

About: [PATCH 2/2] ntdll: Check for case-insensitive volumes.

by Joris Huizer

Hello, In the proposed patch "[PATCH 2/2] ntdll: Check for case-insensitive volumes.", I found this piece: + /* Add a new entry */ + for (i = 0; i < sizeof(fs_cache)/sizeof(fs_cache[0]); i++) + if (fs_cache[i].dev == 0) + { + /* This entry is empty, use it */ + fs_cache[i].dev = dev; + fs_cache[i].fsid = fsid; + fs_cache[i].case_sensitive = case_sensitive; + } Maybe I'm missing something, but shouldn't you return from the function when finding a cache entry to fill? This seems to be filling every empty cache entry? HTH, Joris

Oct. 18, 2010

Re: [1/4]winegstreamer: add wine gstreamer parser filter

by Damjan Jovanovic

On Mon, Oct 18, 2010 at 3:26 PM, Aric Stewart <aric(a)codeweavers.com> wrote: > --- > dlls/winegstreamer/regsvr.c | 951 +++++++++++++++++++ Please consider IRegistrar or inf file based registration instead, regsvr.c is the worst way to support DLL registration, especially if you have to customize it the way you have. Damjan

Oct. 18, 2010

Re: [1/4] msxml3: Get rid of ::get_dataType() forward to IXMLDOMNode interface

by Nikolay Sivov

On 10/18/2010 16:03, Jacek Caban wrote: > On 10/18/10 1:57 PM, Nikolay Sivov wrote: >> On 10/18/2010 15:53, Jacek Caban wrote: >>> Hi Nikolay, >>> >>> On 10/18/10 11:26 AM, Nikolay Sivov wrote: >>>> Get rid of ::get_dataType() forward to IXMLDOMNode interface >>>> >>> >>> switch ( This->node->type ) >>> { >>> case XML_ELEMENT_NODE: >>> >>> >>> On of points of such patches is to get rid of such switches. In this >>> case it seems like introducing new helper return_null_var, adding >>> FIXME to extityref implementation and moving element-specific part >>> to element.c is way to go. Also it would be nice to have consistent >>> TRACEs, so moving them to node-specific objects would be nice. >>> >>> Jacek >> Ok, so you mean use a dummy helper for those nodes that don't have >> implementation now > > Yes, we already have a few such return_* helper functions in > msxml_private.h. Will take a look. > >> and move what is supposed to work already to an object that it >> belongs to? > > In this case yes. The code is element-specific anyways, so it doesn't > make sense to have a function that pretends to be generic. Agreed. > > > Jacek >

Oct. 18, 2010

Re: [1/4] msxml3: Get rid of ::get_dataType() forward to IXMLDOMNode interface

by Jacek Caban

On 10/18/10 1:57 PM, Nikolay Sivov wrote: > On 10/18/2010 15:53, Jacek Caban wrote: >> Hi Nikolay, >> >> On 10/18/10 11:26 AM, Nikolay Sivov wrote: >>> Get rid of ::get_dataType() forward to IXMLDOMNode interface >>> >> >> switch ( This->node->type ) >> { >> case XML_ELEMENT_NODE: >> >> >> On of points of such patches is to get rid of such switches. In this >> case it seems like introducing new helper return_null_var, adding FIXME >> to extityref implementation and moving element-specific part to >> element.c is way to go. Also it would be nice to have consistent TRACEs, >> so moving them to node-specific objects would be nice. >> >> Jacek > Ok, so you mean use a dummy helper for those nodes that don't have > implementation now Yes, we already have a few such return_* helper functions in msxml_private.h. > and move what is supposed to work already to an object that it belongs to? In this case yes. The code is element-specific anyways, so it doesn't make sense to have a function that pretends to be generic. Jacek

Oct. 18, 2010

Re: [1/4] msxml3: Get rid of ::get_dataType() forward to IXMLDOMNode interface

by Nikolay Sivov

On 10/18/2010 15:53, Jacek Caban wrote: > Hi Nikolay, > > On 10/18/10 11:26 AM, Nikolay Sivov wrote: >> Get rid of ::get_dataType() forward to IXMLDOMNode interface >> > > switch ( This->node->type ) > { > case XML_ELEMENT_NODE: > > > On of points of such patches is to get rid of such switches. In this > case it seems like introducing new helper return_null_var, adding > FIXME to extityref implementation and moving element-specific part to > element.c is way to go. Also it would be nice to have consistent > TRACEs, so moving them to node-specific objects would be nice. > > Jacek Ok, so you mean use a dummy helper for those nodes that don't have implementation now and move what is supposed to work already to an object that it belongs to?

Oct. 18, 2010

Re: [1/4] msxml3: Get rid of ::get_dataType() forward to IXMLDOMNode interface

by Jacek Caban

Hi Nikolay, On 10/18/10 11:26 AM, Nikolay Sivov wrote: > Get rid of ::get_dataType() forward to IXMLDOMNode interface > switch ( This->node->type ) { case XML_ELEMENT_NODE: On of points of such patches is to get rid of such switches. In this case it seems like introducing new helper return_null_var, adding FIXME to extityref implementation and moving element-specific part to element.c is way to go. Also it would be nice to have consistent TRACEs, so moving them to node-specific objects would be nice. Jacek

Oct. 18, 2010

Re: [PATCH 3/3] winspool: Use UNICODE for CUPS printer names [fixes bug 6437]

by Alexandre Julliard

Detlef Riekenberg <wine.dev(a)web.de> writes: > or do we have to remove all related "const" from the strings? Yes. -- Alexandre Julliard julliard(a)winehq.org

Oct. 18, 2010

Re: cmd: Add a space at the end of the first echo'ed batch line [try4]

by Alexandre Julliard

Alexandre Goujon <ale.goujon(a)gmail.com> writes: > I was looking for a forbidden char in batch files but just I found accentuated chars whereas I wanted a single (not wide) char. > Finally, I found it in the ASCII table. > The \x1a character name is SUBSTITUTE and is exactly what we need. It means end of file on Windows, so it's not a good choice. Please don't add magic control chars, do a @space@ style of thing. -- Alexandre Julliard julliard(a)winehq.org

Oct. 18, 2010

Re: [4/4] msxml3: Partially implement ::setAttributeNode()

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6265 Your paranoid android. === WXPPROSP3 (32 bit domdoc) === domdoc.c:6872: Test failed: got 1 === W2K3R2SESP2 (32 bit domdoc) === domdoc.c:6872: Test failed: got 1 === WVISTAADM (32 bit domdoc) === domdoc.c:6872: Test failed: got 1 === W2K8SE (32 bit domdoc) === domdoc.c:6872: Test failed: got 1 === W7PRO (32 bit domdoc) === domdoc.c:6872: Test failed: got 1 === W7PROX64 (32 bit domdoc) === domdoc.c:6872: Test failed: got 1 === W7PROX64 (64 bit domdoc) === domdoc.c:6872: Test failed: got 1

Oct. 18, 2010

Re: [PATCH] mscms: patch for problem with displaying images with enabled color management in system and some apps

by Hans Leidekker

Hi Tomasz, Please use a more specific subject such as "mscms: Handle bitmap formats BM_xRGBQUADS and BM_xBGRQUADS in TranslateBitmapBits".

Oct. 18, 2010

Re: [PATCH] mscms: patch for problem with displaying images with enabled color management in system and some apps

by Nikolay Sivov

On 10/17/2010 22:46, Tomasz Michno wrote: > --- > dlls/mscms/tests/Makefile.in | 3 ++- > dlls/mscms/transform.c | 2 ++ > 2 files changed, 4 insertions(+), 1 deletions(-) > > > You forgot to add new file to a patch.

Oct. 17, 2010

Re: [PATCH] Compiling Wine at Ubuntu 10.10

by Gerold Jens Wucherpfennig

-------- Original-Nachricht -------- > Datum: Sat, 16 Oct 2010 17:26:49 +0200 > Von: Detlef Riekenberg <wine.dev(a)web.de> > An: Gerold Jens Wucherpfennig <gjwucherpfennig(a)gmx.net> > CC: wine-devel(a)winehq.org > Betreff: Re: [PATCH] Compiling Wine at Ubuntu 10.10 > On Sa, 2010-10-16 at 10:02 +0200, Gerold Jens Wucherpfennig wrote: > > You will need this patch to compile Wine at Ubuntu 10.10, > > because of the new Xorg Server 1.9. > > You can't do that. > Your patch will break the build on many systems. Yes I only made the patch, because I couldn't find a solution by googling. It was a hot fix for me just to get wine compiled... > Are you missing libxxf86vm1 or libxxf86vm-dev? No. > > > If you still get a compilation error in dlls/winex11.drv you > > will need to add the flag "-lXxf86vm". > > cd dlls/winex11.drv/ > make > > => works here on a clean 32bit build > (ubuntu 10.10 / x86_64) Hm, that's strange. Let's see if other people need my fix... With kind Regards, Gerold -- GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

Oct. 17, 2010

Re: ws2_32: Add support and tests for WSARecvMsg and IP_PKTINFO.

by Erich Hoover

On Sat, Oct 16, 2010 at 1:41 PM, Mike Kaplinskiy <mike.kaplinskiy(a)gmail.com> wrote: > On Thu, Oct 14, 2010 at 10:08 PM, Erich Hoover <ehoover(a)mines.edu> wrote: >> ... >> DWORD flags; >> unsigned int n_iovecs; >> unsigned int first_iovec; >>+ WSABUF *control; >> struct iovec iovec[1]; >> } ws2_async; > I would prefer control declared above n_iovecs purely for > organizational purposes (params first, buffers and info about them > last). Also you can't just store the passed in WSABUF pointer; it may > be stack allocated and may disappear before the overlapped call > completes. You could just add control and control_len instead of using > WSABUF. That's why in the original version I had those parameters split out; however, I realized that since the length parameter gets modified by WSARecvMsg that it is impossible for the WSAMSG structure (or any of its parameters) to disappear before WSARecvMsg completes. I have re-written the tests (see patch 4 at the end) to show that this structure gets modified even when an overlapped request is used and results in modification of the structure at a later time, the results from the test bot can be found here: https://testbot.winehq.org/JobDetails.pl?Key=6250 >>+ /* Insufficient room for control headers */ >>+ errno = EINVAL; > This should probably be ENOMEM then. On that note, it would be nice to > test what windows actually does when you don't give it enough space > (like 1 byte). We should probably rewrite that function at some point > since I'm not sure what errno it returns anymore. This is odd, I must have copy-pasted the wrong error code from the recvmsg() manual page. I've investigated this issue more and discovered that the code should actually be EMSGSIZE. This change and the corresponding tests can be found in my revised patches (at the end), I've also included support for reporting back the MSG_CTRUNC flag. >>+#ifdef IP_PKTINFO >>+ case WS_IP_PKTINFO: >>+#endif > You probably don't need the ifdef. convert_sockopt will just fail. I did this to match how IP_HDRINCL was done nearby, should this really be changed? >>+ hdr.Control.buf = pktbuf; > .len = sizeof(pktbuf)? The length parameter is declared within the loop, otherwise it gets resized (as mentioned earlier) when WSARecvMsg is called. Thank you so much for all your help, I hope you find the following to be more to your liking. [1/4] include: Add IP_PKTINFO response structure. http://www.compholio.com/wine-kane/patches/2010-10-17/0001-include-Add-IP_P… [2/4] include: Add macros for retrieving control message headers. http://www.compholio.com/wine-kane/patches/2010-10-17/0002-include-Add-macr… [3/4] ws2_32: Add support for WSARecvMsg and IP_PKTINFO. http://www.compholio.com/wine-kane/patches/2010-10-17/0003-ws2_32-Add-suppo… [4/4] ws2_32/tests: Add regression tests for WSARecvMsg and IP_PKTINFO. http://www.compholio.com/wine-kane/patches/2010-10-17/0004-ws2_32-tests-Add… Erich Hoover ehoover(a)mines.edu

Oct. 17, 2010

Re: windowscodecs: Fix *_CopyPixels functions to properly handle a NULL rectangle

by Vitaliy Margolen

On 10/17/2010 01:59 AM, Krzysztof Nowicki wrote: > Doing a memcpy to a local rectangle seems a morenatural way to do it Not really. Doing RECT = RECT is the natural way to do it. Don't use memcpy to copy one structure to another structure of the same type. Vitaliy.

Oct. 17, 2010

Re: Set base direction of web site to RTL language for Hebrew

by Yaron Shahrabani

On Sun, Oct 17, 2010 at 3:07 PM, Shachar Shemesh <shachar(a)shemesh.biz>wrote: > On 17/10/10 15:00, Yaron Shahrabani wrote: > > >> Another manifestation of this difference can be seen when you place a >> "dir=" directive on the <body> tag of "content_print.template". This is >> change does not pass strict HTML validation, and would be unnecessary had >> the two CSS approaches been used. >> > So they should be combined? > >> I think, no. I think the RTL file should only contain RTL related stuff, > and will therefor be okay to use it also in the content_print file, without > adding a tag to the body. > Currently the RTL file I created contains only RTL stuff (and imports the other). It could be loaded in addition to the winehq_styles.css (where is this file anyway?) in content_print.template, this will solve the entire problem and ensures the site would look at its best. Kind regards, Yaron Shahrabani. > Just MHO. > > > Shachar > > -- > Shachar Shemesh > Lingnu Open Source Consulting Ltd.http://www.lingnu.com > >

Oct. 17, 2010

Re: Set base direction of web site to RTL language for Hebrew

by Shachar Shemesh

On 17/10/10 15:00, Yaron Shahrabani wrote: > > > Another manifestation of this difference can be seen when you > place a "dir=" directive on the <body> tag of > "content_print.template". This is change does not pass strict HTML > validation, and would be unnecessary had the two CSS approaches > been used. > > So they should be combined? > I think, no. I think the RTL file should only contain RTL related stuff, and will therefor be okay to use it also in the content_print file, without adding a tag to the body. Just MHO. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com

Oct. 17, 2010

Re: Ubuntu Package Archive is back!

by Yaron Shahrabani

On Sun, Oct 17, 2010 at 2:01 PM, Scott Ritchie <scott(a)open-vote.org> wrote: > When I switched Ubuntu package hosting to a launchpad PPA (away from > manual .deb hosting), one thing lost was the ease of archiving old > versions, since Launchpad doesn't provide this. > > I've written some scripts to manually copy the packages from the PPA to > form a new archive and am hosting it at the old location > http://wine.budgetdedicated.com/archive/ -- currently it carries all > the Wine packages that have been on the Ubuntu Wine PPA since 1.3.3 or so. > > The main use of the archive is to aid in regression testing - installing > from packages is much easier/quicker than recompiling from source, and > will help you narrow down the last working/nonworking wine version > before doing a proper git bisect. > > > All I have to do is run the script every time I update the PPA with new > Wine packages, and it's good. > > Due to server space issues, I don't plan to archive daily package builds > (which is my next project). > > Thanks, > Scott Ritchie > > > That's awesome! Ive been using your PPA for a really long time until I started compiling wine by myself! Keep up the good work and thank you very much! Yaron Shahrabani <Hebrew translator>

Oct. 17, 2010

Re: Set base direction of web site to RTL language for Hebrew

by Yaron Shahrabani

On Sun, Oct 17, 2010 at 2:18 PM, Shachar Shemesh <shachar(a)shemesh.biz>wrote: > On 17/10/10 13:52, Yaron Shahrabani wrote: > >> Waste of time, there are several objects that should be LTR (like the news >> list) and some images that need to be flipped horizontally, plus I have >> already done all the stuff I said, basically this patch is useless... >> > I will accept and admit your accusation of me not being psychic in sensing > your incoming patches. Your patches are, indeed, more comprehensive than > mine, but I believe they are inferior in at least one important aspect. > For some reason I got your patch only half an hour ago so I was absolutely sure you sent it way later... > > You direct the code to load styles-rtl.css instead of styles.css. This > encourages future site maintainers to perform changes to the CSS that will > break the RTL version of it, due to not noticing the existence of the rtl > version. I believe the approach I took, of including styles.css, and then > including a second css only aimed at correcting the what needs to be > corrected, would work better in the long run. > It is actually a linked CSS file... I used @import ("styles.css") in order to maintain the original CSS, its the same approach you took only from a different point of view and practically there's no difference... (I can switch the method in a matter of click :) ). > > Another manifestation of this difference can be seen when you place a > "dir=" directive on the <body> tag of "content_print.template". This is > change does not pass strict HTML validation, and would be unnecessary had > the two CSS approaches been used. > So they should be combined? > > Shachar > > > -- > Shachar Shemesh > Lingnu Open Source Consulting Ltd. > http://www.lingnu.com > >

Oct. 17, 2010

Re: Set base direction of web site to RTL language for Hebrew

by Shachar Shemesh

On 17/10/10 13:52, Yaron Shahrabani wrote: > Waste of time, there are several objects that should be LTR (like the > news list) and some images that need to be flipped horizontally, plus > I have already done all the stuff I said, basically this patch is > useless... I will accept and admit your accusation of me not being psychic in sensing your incoming patches. Your patches are, indeed, more comprehensive than mine, but I believe they are inferior in at least one important aspect. You direct the code to load styles-rtl.css instead of styles.css. This encourages future site maintainers to perform changes to the CSS that will break the RTL version of it, due to not noticing the existence of the rtl version. I believe the approach I took, of including styles.css, and then including a second css only aimed at correcting the what needs to be corrected, would work better in the long run. Another manifestation of this difference can be seen when you place a "dir=" directive on the <body> tag of "content_print.template". This is change does not pass strict HTML validation, and would be unnecessary had the two CSS approaches been used. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com

Oct. 17, 2010

Ubuntu Package Archive is back!

by Scott Ritchie

When I switched Ubuntu package hosting to a launchpad PPA (away from manual .deb hosting), one thing lost was the ease of archiving old versions, since Launchpad doesn't provide this. I've written some scripts to manually copy the packages from the PPA to form a new archive and am hosting it at the old location http://wine.budgetdedicated.com/archive/ -- currently it carries all the Wine packages that have been on the Ubuntu Wine PPA since 1.3.3 or so. The main use of the archive is to aid in regression testing - installing from packages is much easier/quicker than recompiling from source, and will help you narrow down the last working/nonworking wine version before doing a proper git bisect. All I have to do is run the script every time I update the PPA with new Wine packages, and it's good. Due to server space issues, I don't plan to archive daily package builds (which is my next project). Thanks, Scott Ritchie

Oct. 17, 2010

Re: RTL in console windows

by Yaron Shahrabani

On Sun, Oct 17, 2010 at 1:52 PM, Shachar Shemesh <shachar(a)shemesh.biz>wrote: > On 15/10/10 16:06, Yaron Shahrabani wrote: > >> >> So my dillema is as follows: >> Should we continue helping improving the support of displaying RTL >> languages in wineconsole or should we just ignore the CLI strings like MS >> did with all of their OSes (Since Windows XP Hebrew is no longer supported >> officially, meaning that you have to apply 3rd party patches in order to >> make Hebrew text appear in cmd), Hebrew in command line is only used by some >> old healthcare services and lots of old games and ancient word processors >> and database apps (some of them died after Windows dominated the market). >> > If Windows doesn't do it, I don't think we should. > Assuming Wine should offer support to versions prior to Windows XP there should be a support. > > Then again, it is my understanding that in some places, Windows does do it. > Powershell, was pointed out by Michael Kaplan ( > http://blogs.msdn.com/b/michkap/archive/2010/10/07/10072032.aspx - myth > 6). I have not tested it myself, but if that is correct, we need to do it > like Windows does it, under the same circumstances. > > > >> Another vital question I want to to this message is to ask our fellow >> Arabic and Persian speakers what do they have to say about this issue and if >> their propriatery operating systems has the same issues... >> > This is irrelevant. Our standard of operation is "what Windows does". > I was not asking what the Arabs or Persian did, I was asking if Microsoft did the same with the Arabic and Persian versions of Windows. Arabs and Persians, please tell us how did Windows versions prior to XP natively handled your languages in console windows (cmd/command etc.). > > Shachar > > > > -- > Shachar Shemesh > Lingnu Open Source Consulting Ltd. > http://www.lingnu.com > >

Oct. 17, 2010

Re: Set base direction of web site to RTL language for Hebrew

by Yaron Shahrabani

Waste of time, there are several objects that should be LTR (like the news list) and some images that need to be flipped horizontally, plus I have already done all the stuff I said, basically this patch is useless...

Oct. 17, 2010

Re: RTL in console windows

by Shachar Shemesh

On 15/10/10 16:06, Yaron Shahrabani wrote: > > So my dillema is as follows: > Should we continue helping improving the support of displaying RTL > languages in wineconsole or should we just ignore the CLI strings like > MS did with all of their OSes (Since Windows XP Hebrew is no longer > supported officially, meaning that you have to apply 3rd party patches > in order to make Hebrew text appear in cmd), Hebrew in command line is > only used by some old healthcare services and lots of old games and > ancient word processors and database apps (some of them died after > Windows dominated the market). If Windows doesn't do it, I don't think we should. Then again, it is my understanding that in some places, Windows does do it. Powershell, was pointed out by Michael Kaplan (http://blogs.msdn.com/b/michkap/archive/2010/10/07/10072032.aspx - myth 6). I have not tested it myself, but if that is correct, we need to do it like Windows does it, under the same circumstances. > > Another vital question I want to to this message is to ask our fellow > Arabic and Persian speakers what do they have to say about this issue > and if their propriatery operating systems has the same issues... This is irrelevant. Our standard of operation is "what Windows does". Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com

Oct. 17, 2010

Translation of the AppDB

by Yaron Shahrabani

Is there any way to localize the AppDB? The Israeli community assumes that having a Hebrew system will make more users report issues. Kind regards, Yaron Shahrabani <Hebrew translator>

Oct. 17, 2010

Re: Website: Change language string

by Yaron Shahrabani

Thanks Paul :) Yaron Shahrabani <Hebrew translator>

Oct. 17, 2010

Re: Website: Change language string

by Paul Vriens

On 10/17/2010 12:21 PM, Yaron Shahrabani wrote: > Where does the translation of "Change Language" string at the bottom of > the page and in the lang.template come from? > (The current term used is male specific, I want to make it genderless). > > Kind regards, > Yaron Shahrabani > > <Hebrew translator> Hi Yaron, See http://source.winehq.org/git/website.git/?a=commitdiff;h=6f11f1577987817638… -- Cheers, Paul.

Oct. 17, 2010

Website: Change language string

by Yaron Shahrabani

Where does the translation of "Change Language" string at the bottom of the page and in the lang.template come from? (The current term used is male specific, I want to make it genderless). Kind regards, Yaron Shahrabani <Hebrew translator>

Oct. 17, 2010

Re: windowscodecs: Fix *_CopyPixels functions to properly handle a NULL rectangle

by Krzysztof Nowicki

W dniu 17.10.2010 01:45, Vincent Povirk pisze: > +1 > > + if (!prc) > + { > + UINT width, height; > + hr = IWICBitmapSource_GetSize(This->source,&width,&height); > + if (FAILED(hr)) return hr; > + rc.X = 0; > + rc.Y = 0; > + rc.Width = width; > + rc.Height = height; > + prc =&rc; > + } > > Any reason you didn't use this approach in the other functions? > > > I don't know really. Doing a memcpy to a local rectangle seems a more natural way to do it, as I don't really like to modify input arguments. In this case I guess I just blindly copied an existing solution that I found later during the review of the other codecs. If you want I can unify the implementations so that all of them look like the one above.

Oct. 17, 2010

Re: Packagers: cups-bsd/cupsys-bsd (lpr and friends) no longer needed

by James McKenzie

On 10/16/10 3:30 PM, Detlef Riekenberg wrote: > Hi Wine packing Team. > > Cups has a compatibility package for the BSD style printing system > (lpr, lpq, lprm, lpc and related files). > The package is named cups-bsd on ubuntu and cupsys-bsd on debian. > > This compatibility package is no longer needed since Wine-1.3.5, > when cups is installed: > http://source.winehq.org/git/wine.git/?a=commit;h=f69a4ef07f7b1b0017e1bf335… > > Thanks for updating the Wine dependency. > Is this also true for Macs? If I remember we used lpr to pick up printers on that platform. James McKenzie

Oct. 16, 2010

Re: windowscodecs: Fix *_CopyPixels functions to properly handle a NULL rectangle

by Vincent Povirk

+1 + if (!prc) + { + UINT width, height; + hr = IWICBitmapSource_GetSize(This->source, &width, &height); + if (FAILED(hr)) return hr; + rc.X = 0; + rc.Y = 0; + rc.Width = width; + rc.Height = height; + prc = &rc; + } Any reason you didn't use this approach in the other functions?

Oct. 16, 2010

Packagers: cups-bsd/cupsys-bsd (lpr and friends) no longer needed

by Detlef Riekenberg

Hi Wine packing Team. Cups has a compatibility package for the BSD style printing system (lpr, lpq, lprm, lpc and related files). The package is named cups-bsd on ubuntu and cupsys-bsd on debian. This compatibility package is no longer needed since Wine-1.3.5, when cups is installed: http://source.winehq.org/git/wine.git/?a=commit;h=f69a4ef07f7b1b0017e1bf335… Thanks for updating the Wine dependency. -- By by ... Detlef

Oct. 16, 2010

Re: user32: Update last active popup for all parents

by testbot＠testbot.winehq.org

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=6225 Your paranoid android. === W7PROX64 (64 bit win) === win.c:2684: Test failed: GetActiveWindow() = 0000000000000000 win.c:2684: Test failed: GetFocus() = 0000000000000000 win.c:2710: Test failed: GetActiveWindow() = 0000000000000000 win.c:2710: Test failed: GetFocus() = 0000000000000000 win.c:2769: Test failed: GetActiveWindow() = 0000000000000000 win.c:2769: Test failed: GetFocus() = 0000000000000000

Oct. 16, 2010

Re: ws2_32: Add support and tests for WSARecvMsg and IP_PKTINFO.

by Mike Kaplinskiy

On Thu, Oct 14, 2010 at 10:08 PM, Erich Hoover <ehoover(a)mines.edu> wrote: > If you guys would mind looking over this revised patchset I would > greatly appreciate it, I believe I've appropriately included your > corrections. Please note that mswsock.h and ws2ipdef.h will be > submitted as separate patches. Thanks in advance! > > Erich Hoover > ehoover(a)mines.edu > I still have a few comments on the patch, but all of them are minor. - You should have the test in a separate patch as well. > DWORD flags; > unsigned int n_iovecs; > unsigned int first_iovec; >+ WSABUF *control; > struct iovec iovec[1]; > } ws2_async; I would prefer control declared above n_iovecs purely for organizational purposes (params first, buffers and info about them last). Also you can't just store the passed in WSABUF pointer; it may be stack allocated and may disappear before the overlapped call completes. You could just add control and control_len instead of using WSABUF. >+ /* Loop over all the headers, converting as appropriate */ >+ struct cmsghdr *cmsg_unix = (struct cmsghdr *) CMSG_FIRSTHDR(hdr); >... >+ for (ptr = cmsg_win; cmsg_unix != NULL; cmsg_unix = CMSG_NXTHDR(hdr, cmsg_unix)) That's just confusing. Please initialize cmsg_unix in the for loop and ptr outside the for loop. >+ /* Insufficient room for control headers */ >+ errno = EINVAL; This should probably be ENOMEM then. On that note, it would be nice to test what windows actually does when you don't give it enough space (like 1 byte). We should probably rewrite that function at some point since I'm not sure what errno it returns anymore. >+ if (!msg) return SOCKET_ERROR; That doesn't seem right to me (no SetLastError?). Is there a test for this? >+#ifdef IP_PKTINFO >+ case WS_IP_PKTINFO: >+#endif You probably don't need the ifdef. convert_sockopt will just fail. >+ hdr.Control.buf = pktbuf; .len = sizeof(pktbuf)? >+ if (!pWSARecvMsg) >+ { >+ skip("WSARecvMsg is unsupported, some tests will be skipped.\n"); >+ return; >+ } You probably want win_skip. You also leak some sockets here. Mike.

Oct. 16, 2010

Re: [PATCH] problem with color management with mscms and gdi

by Detlef Riekenberg

Hi Tomasz. Welcome to Wine. You already fixed your missing real name in your first patch. That is good, but there are more suggestions. > For applications which uses EnumICMProfiles to detect monitor icc profile, > there should be a copy of monitor profile in > windows\system32\spool\drivers\color\monitor.icc. If there is no monitor.icc > in this directory, application works the same as if there were no color > management enabled (but image is displayed ok). A description for the issue is a good idea. > INT WINAPI EnumICMProfilesA(HDC hdc, ICMENUMPROCA func, LPARAM > lparam) > { > FIXME("%p, %p, 0x%08lx stub\n", hdc, func, lparam); > - return -1; > + (*func)("C: > \\windows\\system32\\spool\\drivers\\color\\monitor.icc",lparam); > + FIXME("partially fixed: force C: > \\windows\\system32\\spool\\drivers\\color\\monitor.icc\n"); > + return 1; > } What you wrote in your patch is a hack and hacks are missing the code quality to be accepted in Wine. Wine development is test driven. You should add some tests for this function and try to invent a real implementation, which match the tests. - Does this function handle a NULL parameter for hdc and/or for func? (If a NULL produce a crash on Windows, there is no need to check for a NULL in the implementation in Wine) - What does the function return, when the directory does not exist or when there are no icc profiles in the directory? - A HDC for a window on the monitor is not the only type for an HDC. (memory, printers, metafiles) Implementing all possible types is not a requirement (as long, as an app does not need it), but the usual way in Wine is at least printing a FIXME for the unimplemented part of the API. - There are usable API functions, to get the icc profile path. - Reading the directory and calling the user func for every file is not very difficult, as wine has examples in the source. You can ask for help for the implementation or for the tests on wine-devel or use #winehackers on freenode. There is has also http://testbot.winehq.org and later http://tests.winehq.org > INT WINAPI EnumICMProfilesW(HDC hdc, ICMENUMPROCW func, LPARAM ... > + (*func)("C: > \\windows\\system32\\spool\\drivers\\color\\monitor.icc",lparam); Providing an ANSI Path to a UNICODE callback will never work. > /********************************************************************** > diff --git a/dlls/mscms/transform.c b/dlls/mscms/transform.c This is a separate Patch I know, that the starting step is not easy, but once you contributed successfully to Wine, your Development results (patches) are much better. Did you read http://wiki.winehq.org/DeveloperFaq and http://wiki.winehq.org/SubmittingPatches ? Overview: http://wiki.winehq.org/Developers -- By by ... Detlef

Oct. 16, 2010

Re: [PATCH] Compiling Wine at Ubuntu 10.10

by Detlef Riekenberg

On Sa, 2010-10-16 at 10:02 +0200, Gerold Jens Wucherpfennig wrote: > You will need this patch to compile Wine at Ubuntu 10.10, > because of the new Xorg Server 1.9. You can't do that. Your patch will break the build on many systems. Are you missing libxxf86vm1 or libxxf86vm-dev? > If you still get a compilation error in dlls/winex11.drv you > will need to add the flag "-lXxf86vm". cd dlls/winex11.drv/ make => works here on a clean 32bit build (ubuntu 10.10 / x86_64) -- By by ... Detlef

Oct. 16, 2010

Re: [PATCH] Compiling Wine at Ubuntu 10.10

by Detlef Riekenberg

On Sa, 2010-10-16 at 13:29 +0200, Alexandre Julliard wrote: > Gerold Jens Wucherpfennig <gjwucherpfennig(a)gmx.net> writes: > > You will need this patch to compile Wine at Ubuntu 10.10, > > because of the new Xorg Server 1.9. > > If you still get a compilation error in dlls/winex11.drv you > > will need to add the flag "-lXxf86vm". > We can't do that. What did they change that breaks the build? No Idea. I'm doing a clean build on Ubuntu 10.10 now, but it need ~1h. Nothing special from configure: checking for -lXxf86vm... libXxf86vm.so.1 -- By by ... Detlef

Oct. 16, 2010

Re: [PATCH] Compiling Wine at Ubuntu 10.10

by Trygve Vea

On Sat, Oct 16, 2010 at 1:29 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Gerold Jens Wucherpfennig <gjwucherpfennig(a)gmx.net> writes: > >> You will need this patch to compile Wine at Ubuntu 10.10, >> because of the new Xorg Server 1.9. >> If you still get a compilation error in dlls/winex11.drv you >> will need to add the flag "-lXxf86vm". > > We can't do that. What did they change that breaks the build? I'm running Ubuntu 10.10, and I can't reproduce the problem. It compiles just fine, here. -- Trygve Vea

Oct. 16, 2010

Re: [PATCH] problem with color management with mscms and gdi

by James McKenzie

On 10/16/10 5:38 AM, André Hentschel wrote: > Hi and welcome to wine development, > your patch is wrapped. see the gdi part of it at http://source.winehq.org/patches/. > so you should check your mailclient. > Further you might want to split it per module (gdi and mscms, one patch each) Andre: The patch displays just fine on my mail reader and in Firefox with no wrapping here. The patch description lines continue on off the screen of Firefox. You are correct in that it needs to be two separate patches. Very respectfully, James McKenzie

Oct. 16, 2010

Re: [PATCH] problem with color management with mscms and gdi

by Hans Leidekker

Hi Tomasz, This patch is wrapped, unlike your first attempt were you attached the patch. > dlls/gdi32/icm.c | 8 ++++++-- > dlls/mscms/transform.c | 2 ++ > 2 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/dlls/gdi32/icm.c b/dlls/gdi32/icm.c > index 0e346ee..d75c528 100644 > --- a/dlls/gdi32/icm.c > +++ b/dlls/gdi32/icm.c > @@ -44,7 +44,9 @@ WINE_DEFAULT_DEBUG_CHANNEL(icm); > INT WINAPI EnumICMProfilesA(HDC hdc, ICMENUMPROCA func, LPARAM > lparam) > { > FIXME("%p, %p, 0x%08lx stub\n", hdc, func, lparam); > - return -1; > + (*func)("C: > \\windows\\system32\\spool\\drivers\\color\\monitor.icc",lparam); > + FIXME("partially fixed: force C: > \\windows\\system32\\spool\\drivers\\color\\monitor.icc\n"); > + return 1; > } You can't hardcode the filename like that. EnumICMProfiles should call down into the driver and probably enumerate a registry key. > /********************************************************************** > diff --git a/dlls/mscms/transform.c b/dlls/mscms/transform.c > index a795386..e7a3faa 100644 > --- a/dlls/mscms/transform.c > +++ b/dlls/mscms/transform.c > @@ -65,6 +65,8 @@ static DWORD from_bmformat( BMFORMAT format ) > { > case BM_RGBTRIPLETS: return TYPE_RGB_8; > case BM_BGRTRIPLETS: return TYPE_BGR_8; > + case BM_xRGBQUADS: return TYPE_RGBA_8; > + case BM_xBGRQUADS: return TYPE_ABGR_8; > case BM_GRAY: return TYPE_GRAY_8; > default: > if (quietfixme == 0) You should send this as a separate patch.

Oct. 16, 2010

Re: [Website] Foundation of the Hebrew website

by Yaron Shahrabani

On Sat, Oct 16, 2010 at 9:22 AM, James McKenzie <jjmckenzie51(a)earthlink.net>wrote: > On 10/15/10 8:44 PM, Yaron Shahrabani wrote: > > On Fri, Oct 15, 2010 at 10:54 PM, Yaron Shahrabani <sh.yaron(a)gmail.com>wrote: > >> On Fri, Oct 15, 2010 at 4:39 PM, James McKenzie < >> jjmckenzie51(a)earthlink.net> wrote: >> >>> On 10/11/10 9:28 AM, Yaron Shahrabani wrote: >>> >>> Started some translation work, there is still much more RTLing work to do >>> so we will settle for an LTR for now and I will handle it soon. >>> Yaron Shahrabani >>> >>> <Hebrew translator> >>> >>> >>> >>> Yaron: >>> >>> Since the web site works runs on a Web Server, should you not be building >>> the work RTL rather than LTR? >>> >> Its a bit of a problem because I don't have a platform to run the >> website so I can't really RTL myself at the moment... >> >> I was thinking about RTLing after translating, in my case it would a >> little easier (there are things you can't see when the site appears in a >> different language including things you don't see..) >> >> Thanks alot for the offer, I'll start working on the CSS once I'll see >> the site working (can we have some additions to the css to the RTL >> languages?) >> >> Kind regards, >> Yaron Shahrabani. >> >>> >>> Just a thought, mind you and it might save work later. >>> >>> James McKenzie >>> >> I prepared a screenshot, I can't get this style though since I created > it with Chromium inspector... > Are there any specific CSS files or instructions for RTL site? > > I like it, but I'm not a that familiar with where the Wine project wants > to go with RTL web pages. That will be up to the web team. If this is how > it should look, that is fantastic (great, stupendous, etc.) > LOL :) > > I did notice that your initial web site was accepted. Congratulations are > in order. > Thank you! > > Questions about the design of the web site should be addressed to the > Development team at large and not directly to me from this point forward. > Of course, that's why the wine-devs are cced... Well, is anyone working on the websites I can talk to? Kind regards, Yaron Shahrabani. > > James McKenzie > >

Oct. 16, 2010