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

Re: [PATCH 4/5] [Kernel32, Server]: fixed a couple of bugs when reading bare console input with overlapped operations

by Alexandre Julliard

Eric Pouech <eric.pouech(a)orange.fr> writes: > @@ -3011,6 +3014,7 @@ BOOL CONSOLE_Init(RTL_USER_PROCESS_PARAMETERS *params) > /* reply->event shouldn't be created by server */ > } > SERVER_END_REQ; > + fcntl( 0, F_SETFL, O_NONBLOCK ); I don't think that's a good idea, the calling process may not expect that. Also using overlapped I/O seems overkill considering that you already have a Unix fd. -- Alexandre Julliard julliard(a)winehq.org

Nov. 29, 2010

Re: winex11: remove unused field

by Marcus Meissner

On Sun, Nov 28, 2010 at 08:36:51PM -0600, Vincent Povirk wrote: > I don't know much about this area of Wine, but I think the change is incorrect. > > The DC's transform is applied to the font when it is rendered. To do > this correctly, the glyphs must be transformed when they are > rasterized and uploaded. > > Note that we only appear to use the first four fields of XFORM (they > are copied to a shorter FMAT2 struct) to rasterize the glyphs. The > last two fields of XFORM only specify an offset, so I think they can > be safely ignored. Steam still has a 1x0x0x1 matrix, and only sends different eDX and eDY values. So would setting them to 0 help? Like this? --- dlls/winex11.drv/xrender.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/dlls/winex11.drv/xrender.c b/dlls/winex11.drv/xrender.c index 4f900b2..f0ec1b1 100644 --- a/dlls/winex11.drv/xrender.c +++ b/dlls/winex11.drv/xrender.c @@ -1067,6 +1067,9 @@ BOOL X11DRV_XRender_SelectFont(X11DRV_PDEVICE *physDev, HFONT hfont) lfsz.devsize.cx = X11DRV_XWStoDS( physDev, lfsz.lf.lfWidth ); lfsz.devsize.cy = X11DRV_YWStoDS( physDev, lfsz.lf.lfHeight ); GetWorldTransform( physDev->hdc, &lfsz.xform ); + /* Not used fields, would break hashing */ + lfsz.xform.eDx = lfsz.xform.eDy = 0; + lfsz_calc_hash(&lfsz); info = get_xrender_info(physDev); -- 1.7.1

Nov. 29, 2010

Re: [PATCH] ntdll: Increase size of buffer used to read lines of /proc/cpuinfo

by Damjan Jovanovic

On Mon, Nov 29, 2010 at 10:00 AM, Damjan Jovanovic <damjan.jov(a)gmail.com> wrote: > On Mon, Nov 29, 2010 at 2:03 AM, James Eder <jimportal(a)gmail.com> wrote: >> On 11/26/10 12:15 AM, Damjan Jovanovic wrote: >>> On Fri, Nov 26, 2010 at 6:56 AM, Vitaliy Margolen >>> <wine-devel at kievinfo.com> wrote: >>>> On 11/24/2010 07:19 PM, James McKenzie wrote: >>>>> On 11/24/10 6:56 PM, Vitaliy Margolen wrote: >>>>>> On 11/24/2010 12:23 PM, jimportal at gmail.com wrote: >>>>>>> From: James Eder<jimportal at gmail.com> >>>>>>> >>>>>>> - while (fgets(line,200,f) != NULL) >>>>>>> + while (fgets(line,450,f) != NULL) >>>>>> You might as well then change this to "sizeof(line)". >>>>> Just for my edification, is there not a better way then setting the >>>>> variable >>>>> line to a flexible length for this purpose. >>>> Unless I didn't understand your question - you can't set a buffer to a >>>> "variable length". You have to provide fgets() a size of the buffer so it >>>> can read at most that many characters -1 for terminating \0. >>>> >>>> Vitaliy. >>>> >>>> >>>> >>> So read lines dynamically instead: >>> >> >> It would be nice to not reinvent that wheel all the time. I don't >> suppose your function could be pulled out of winemenubuilder.c and >> placed in a more accessible location. Should I just copy and paste >> it? It's a good function and it would fit just fine in my opinion. >> >> Alternatively, I doubt 2k or 4k worth of processor features ("flags") >> are going to show up for some years, but I don't know. At any rate, >> at least it would fix it for current systems. >> >> -- >> Jim > > That function is broken by the way, it doesn't preserve the file > pointer across short reads by fgets, and it apparently doesn't even > handle fgets short reads (which return an undocumented NULL). > > Feel free to copy and paste it in a more accessible location once I > send patches. There are also other variations of that function > floating around in Wine. > > Damjan > Sorry, next_line() works perfectly, I was just using it wrongly (non-NULL line initially passed in). Damjan

Nov. 29, 2010

Re: [PATCH] ntdll: Increase size of buffer used to read lines of /proc/cpuinfo

by Damjan Jovanovic

On Mon, Nov 29, 2010 at 2:03 AM, James Eder <jimportal(a)gmail.com> wrote: > On 11/26/10 12:15 AM, Damjan Jovanovic wrote: >> On Fri, Nov 26, 2010 at 6:56 AM, Vitaliy Margolen >> <wine-devel at kievinfo.com> wrote: >>> On 11/24/2010 07:19 PM, James McKenzie wrote: >>>> On 11/24/10 6:56 PM, Vitaliy Margolen wrote: >>>>> On 11/24/2010 12:23 PM, jimportal at gmail.com wrote: >>>>>> From: James Eder<jimportal at gmail.com> >>>>>> >>>>>> - while (fgets(line,200,f) != NULL) >>>>>> + while (fgets(line,450,f) != NULL) >>>>> You might as well then change this to "sizeof(line)". >>>> Just for my edification, is there not a better way then setting the >>>> variable >>>> line to a flexible length for this purpose. >>> Unless I didn't understand your question - you can't set a buffer to a >>> "variable length". You have to provide fgets() a size of the buffer so it >>> can read at most that many characters -1 for terminating \0. >>> >>> Vitaliy. >>> >>> >>> >> So read lines dynamically instead: >> > > It would be nice to not reinvent that wheel all the time. I don't > suppose your function could be pulled out of winemenubuilder.c and > placed in a more accessible location. Should I just copy and paste > it? It's a good function and it would fit just fine in my opinion. > > Alternatively, I doubt 2k or 4k worth of processor features ("flags") > are going to show up for some years, but I don't know. At any rate, > at least it would fix it for current systems. > > -- > Jim That function is broken by the way, it doesn't preserve the file pointer across short reads by fgets, and it apparently doesn't even handle fgets short reads (which return an undocumented NULL). Feel free to copy and paste it in a more accessible location once I send patches. There are also other variations of that function floating around in Wine. Damjan

Nov. 29, 2010

Re: [PATCH] ntdll: Increase size of buffer used to read lines of /proc/cpuinfo

by Peter Rosin

Den 2010-11-29 08:36 skrev Peter Rosin: > Den 2010-11-29 01:03 skrev James Eder: >> On 11/26/10 12:15 AM, Damjan Jovanovic wrote: >>> On Fri, Nov 26, 2010 at 6:56 AM, Vitaliy Margolen >>> <wine-devel at kievinfo.com> wrote: >>>> On 11/24/2010 07:19 PM, James McKenzie wrote: >>>>> On 11/24/10 6:56 PM, Vitaliy Margolen wrote: >>>>>> On 11/24/2010 12:23 PM, jimportal at gmail.com wrote: >>>>>>> From: James Eder<jimportal at gmail.com> >>>>>>> >>>>>>> - while (fgets(line,200,f) != NULL) >>>>>>> + while (fgets(line,450,f) != NULL) >>>>>> You might as well then change this to "sizeof(line)". >>>>> Just for my edification, is there not a better way then setting the >>>>> variable >>>>> line to a flexible length for this purpose. >>>> Unless I didn't understand your question - you can't set a buffer to a >>>> "variable length". You have to provide fgets() a size of the buffer so it >>>> can read at most that many characters -1 for terminating \0. >>>> >>>> Vitaliy. >>>> >>>> >>>> >>> So read lines dynamically instead: >>> >> >> It would be nice to not reinvent that wheel all the time. I don't >> suppose your function could be pulled out of winemenubuilder.c and >> placed in a more accessible location. Should I just copy and paste >> it? It's a good function and it would fit just fine in my opinion. >> >> Alternatively, I doubt 2k or 4k worth of processor features ("flags") >> are going to show up for some years, but I don't know. At any rate, >> at least it would fix it for current systems. > > I'm just making a note that the fgets function is not very well suited > for CRNL style line endings. In the cases discussed here, you appear to > only handle linux files with NL style line endings, but if you ever try > to handle CRNL files, fgets may read CR as the last character on one > invocation and then forget that until the next invocation and thus fail > to find the line ending. The proposed function a few messages back > would in that case read two lines into the buffer, and they would be > separated by a CR. > > For this reason, I consider fgets completely unusable (on Windows) for > anything where the maximum line length isn't known in advance. > > But maybe wine does not have this problem? However, my XP SP3 sure does. Scratch that, it appears to behave. I must have screwed up my previous tests. However, I do remember fgets misbehavior on Windows. Cheers, Peter

Nov. 29, 2010

Re: [PATCH] ntdll: Increase size of buffer used to read lines of /proc/cpuinfo

by Peter Rosin

Den 2010-11-29 01:03 skrev James Eder: > On 11/26/10 12:15 AM, Damjan Jovanovic wrote: >> On Fri, Nov 26, 2010 at 6:56 AM, Vitaliy Margolen >> <wine-devel at kievinfo.com> wrote: >>> On 11/24/2010 07:19 PM, James McKenzie wrote: >>>> On 11/24/10 6:56 PM, Vitaliy Margolen wrote: >>>>> On 11/24/2010 12:23 PM, jimportal at gmail.com wrote: >>>>>> From: James Eder<jimportal at gmail.com> >>>>>> >>>>>> - while (fgets(line,200,f) != NULL) >>>>>> + while (fgets(line,450,f) != NULL) >>>>> You might as well then change this to "sizeof(line)". >>>> Just for my edification, is there not a better way then setting the >>>> variable >>>> line to a flexible length for this purpose. >>> Unless I didn't understand your question - you can't set a buffer to a >>> "variable length". You have to provide fgets() a size of the buffer so it >>> can read at most that many characters -1 for terminating \0. >>> >>> Vitaliy. >>> >>> >>> >> So read lines dynamically instead: >> > > It would be nice to not reinvent that wheel all the time. I don't > suppose your function could be pulled out of winemenubuilder.c and > placed in a more accessible location. Should I just copy and paste > it? It's a good function and it would fit just fine in my opinion. > > Alternatively, I doubt 2k or 4k worth of processor features ("flags") > are going to show up for some years, but I don't know. At any rate, > at least it would fix it for current systems. I'm just making a note that the fgets function is not very well suited for CRNL style line endings. In the cases discussed here, you appear to only handle linux files with NL style line endings, but if you ever try to handle CRNL files, fgets may read CR as the last character on one invocation and then forget that until the next invocation and thus fail to find the line ending. The proposed function a few messages back would in that case read two lines into the buffer, and they would be separated by a CR. For this reason, I consider fgets completely unusable (on Windows) for anything where the maximum line length isn't known in advance. But maybe wine does not have this problem? However, my XP SP3 sure does. Cheers, Peter

Nov. 29, 2010

Re: winex11: remove unused field

by Dmitry Timoshkov

Ričardas Barkauskas <miegalius(a)gmail.com> wrote: > typedef struct > { > LOGFONTW lf; > - XFORM xform; > SIZE devsize; /* size in device coords */ > DWORD hash; > } LFANDSIZE; > @@ -639,7 +638,6 @@ static BOOL fontcmp(LFANDSIZE *p1, LFANDSIZE *p2) > { > if(p1->hash != p2->hash) return TRUE; > if(memcmp(&p1->devsize, &p2->devsize, sizeof(p1->devsize))) return TRUE; > - if(memcmp(&p1->xform, &p2->xform, sizeof(p1->xform))) return TRUE; > if(memcmp(&p1->lf, &p2->lf, offsetof(LOGFONTW, lfFaceName))) return TRUE; > return strcmpiW(p1->lf.lfFaceName, p2->lf.lfFaceName); > } It's not useless, probably you need to check the DC graphics mode before storing the XFORM in the cache, like dlls/gdi32/freetype.c,WineEngCreateFontInstance() is doing. -- Dmitry.

Nov. 29, 2010

Re: [PATCH] user32/tests: Fix test failures by disabling IME when testing unicode input.

by Marvin

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=7331 Your paranoid android. === W7PRO (32 bit input) === input.c:817: Test failed: 0 (a4/0): the msg sequence is not complete: expected 0000 - actual c0ae

Nov. 29, 2010

Re: winex11: remove unused field

by Vincent Povirk

I don't know much about this area of Wine, but I think the change is incorrect. The DC's transform is applied to the font when it is rendered. To do this correctly, the glyphs must be transformed when they are rasterized and uploaded. Note that we only appear to use the first four fields of XFORM (they are copied to a shorter FMAT2 struct) to rasterize the glyphs. The last two fields of XFORM only specify an offset, so I think they can be safely ignored. 2010/11/28 Ričardas Barkauskas <miegalius(a)gmail.com>: > Makes Steam store page scrolling smoother. > Didn't find where this field would be used or what relevant difference > between fonts it would indicate for this caching. > Without it lots of fonts differing only by fields in this structure are > created in such a way that they get marked as unused almost immediately and > thus cache entries get reused fast. > Hacking to allow for much more generous cache growth resulted ~880 entries > (in short run) in font cache and it still managed not to find font in cache > quite often. > With this I didn't notice any such growth, no visual changes and no tests > complained (that don't complain usually). > Don't know what if any tests I could write for this (or more likely I simply > wouldn't be able :P). > > Rčardas Barkauskas > REalm > > > >

Nov. 29, 2010

Re: Packaging 1.3.7 and newer, lucid?

by Scott Ritchie

On 11/28/2010 08:47 AM, rozwell wrote: > Scott Ritchie <scott <at> open-vote.org> writes: > >> Uploaded as of 10 minutes ago, probably still building in launchpad. I >> put 1.3.7 on hold for Lucid/Karmic because I hadn't yet updated >> ia32-libs for them to support the newer gstreamer stuff. But it's >> better to release with those broken than to delay the release, so I'm >> gonna put 1.3.8 there too. >> >> Thanks, >> Scott Ritchie >> >> > > > Greetings, > > Will the package delay be 1 release behind for Lucid? I'd rather stick to it for > now... > I'm curious if it's just a temporary situation? > Maybe I could help somehow to build the newest wine packages for Lucid? > > rozwell > > > > That won't be necessary. I uploaded 1.3.7 first so I could sync it to the archive, then uploaded 1.3.8 afterwards. -Scott

Nov. 29, 2010