Re: [PATCH] ntdll: Increase size of buffer used to read lines of /proc/cpuinfo
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
>>> 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
>>>
>>> - 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
Re: [PATCH] ntdll: Increase size of buffer used to read lines of /proc/cpuinfo
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
>> 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
>>
>> - 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
Re: winex11: remove unused field
Ričardas Barkauskas wrote:
> typedef struct
> {
> LOGFONTW lf;
> -XFORMxform;
> SIZE devsize; /* size in device coords */
> DWORDhash;
> } 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.
Re: [PATCH] user32/tests: Fix test failures by disabling IME when testing unicode input.
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 - actual c0ae
Re: winex11: remove unused field
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 : > 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 > > > >
Re: Packaging 1.3.7 and newer, lucid?
On 11/28/2010 08:47 AM, rozwell wrote: > Scott Ritchie 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
[PATCH] ntdll: Increase size of buffer used to read lines of /proc/cpuinfo
On 11/26/10 12:15 AM, Damjan Jovanovic wrote:
> On Fri, Nov 26, 2010 at 6:56 AM, Vitaliy Margolen
> 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
>
> - 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
Re: Packaging 1.3.7 and newer, lucid?
Scott Ritchie 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
Re: quartz: Start DirectSound renderer as soon as possible.
Hi Erich, 2010/11/28 Erich Hoover : > On Sun, Nov 28, 2010 at 8:28 AM, Maarten Lankhorst > wrote: >> ... >> There are other ways to handle this. What you're doing is wrong. I'm >> guessing the assert(!pSample); is wrong, if it's flushing it ought to >> return all samples held. If it has a sample and returned VFW_E_TIMEOUT >> I guess it has to break. The preferred allocator would have to be a >> separate patch. > > If you'd prefer I can attach these separately, but I really consider > this to be three separate patches (applied in this order): > 1) Freeing all pending samples when terminating > 2) Only asserting when VFW_E_TIMEOUT actually times out > 3) Passing a preferred allocator > > Patch 3 is the "main problem" for F3 and the first two are issues with > paused/stopped filters. Without Patch 1 then Patch 3 always causes > Fallout 3 to crash when exiting the main menu, and it will sometimes > (very rarely) crash when exiting the menu without Patch 2. It sounds > to me like you're taking issue with Patch 2 (the VFW_E_TIMEOUT > portion), and I can look into better ways to do this part. The big > thing that I was hoping you could help me with is that, with commit > 64b14c0ecdd13530a92ff636c451523a99253a0b applied, once you exit the > main menu then absolutely all the audio stops working - but only when > both your commit and my patches are applied. It's not obvious to me > how these patches could interact with your commit in this way, and > nothing obvious stands out in the log, so I was hoping you could point > me in the right direction for where to start figuring this out. > Thanks so much for taking the time to look at this. Well, that is because that assertion is wrong. pSample can be returned on timeout when flushing, but it wouldn't contain any data. I assume this is the bug you're hitting in patch 2, so if it holds a sample just break, and release all pSamples returned by that function. Why my commit breaks things? If all sound stops working I'm guessing it is a sound bug. Cheers, Maarten
Re: quartz: Start DirectSound renderer as soon as possible.
On Sun, Nov 28, 2010 at 8:28 AM, Maarten Lankhorst wrote: > ... > There are other ways to handle this. What you're doing is wrong. I'm > guessing the assert(!pSample); is wrong, if it's flushing it ought to > return all samples held. If it has a sample and returned VFW_E_TIMEOUT > I guess it has to break. The preferred allocator would have to be a > separate patch. If you'd prefer I can attach these separately, but I really consider this to be three separate patches (applied in this order): 1) Freeing all pending samples when terminating 2) Only asserting when VFW_E_TIMEOUT actually times out 3) Passing a preferred allocator Patch 3 is the "main problem" for F3 and the first two are issues with paused/stopped filters. Without Patch 1 then Patch 3 always causes Fallout 3 to crash when exiting the main menu, and it will sometimes (very rarely) crash when exiting the menu without Patch 2. It sounds to me like you're taking issue with Patch 2 (the VFW_E_TIMEOUT portion), and I can look into better ways to do this part. The big thing that I was hoping you could help me with is that, with commit 64b14c0ecdd13530a92ff636c451523a99253a0b applied, once you exit the main menu then absolutely all the audio stops working - but only when both your commit and my patches are applied. It's not obvious to me how these patches could interact with your commit in this way, and nothing obvious stands out in the log, so I was hoping you could point me in the right direction for where to start figuring this out. Thanks so much for taking the time to look at this. Erich Hoover ehoo...@mines.edu
Re: quartz: Start DirectSound renderer as soon as possible.
Hi Erich, 2010/11/21 Erich Hoover : > I've been working on a set of patches (compiled together and attached for > your convenience) to fix the background music in Fallout 3 (Bug #24478) and > I've run into some trouble recently with commit > 64b14c0ecdd13530a92ff636c451523a99253a0b. Before that commit (or removing > that commit in current git) and applying the patches allows the music to > function in both the main menu, properly stop when the menu is closed, and > later play again when the user is in the game. With said commit applied > these patches still permit the background music to work when at the main > menu; however, the moment the "stop" occurs on exiting the menu then all > audio in the entire game ceases to function. I would really appreciate any > feedback you can provide or pointers on where to look for the source of this > problem. Thanks in advance! There are other ways to handle this. What you're doing is wrong. I'm guessing the assert(!pSample); is wrong, if it's flushing it ought to return all samples held. If it has a sample and returned VFW_E_TIMEOUT I guess it has to break. The preferred allocator would have to be a separate patch. Cheers, Maarten
Re: [2/2] atl: add support for binary values in IRegistrar
Hi Paul, On 11/27/10 11:11 PM, Paul Vriens wrote: On 11/27/2010 10:50 PM, Paul Vriens wrote: On 11/27/2010 10:18 PM, Paul Vriens wrote: I could imagine that binary values are not supported on Win95 but the same (?) issue is also present on some NT4, XP and even Windows7. The XP and Windows7 failures can be explained by the fact that those users weren't running the tests as Administrator. If I run the tests are a normal user on my WinXP box it also fails with the same errors. Sounds easy to fix by using registries inside HKCU instead of HKCR. The common denominator here is that both on Win95 and NT4 where the failures occur the version of atl.dll is too old. Both boxes that show failures also show a skip in atl:atl_ax (AtlAxAttachControl is not available). I'll sent a patch to use a different script on the old versions. Can we please just skip all tests on those versions instead of trying to cope with them? It's not only easier to do but also it will save us efforts in the future when we'll be adding more tests. Thanks, Jacek
re: msvcrt: Fixed problem parsing multi-byte characters in _mbspbrk.
http://en.wiktionary.org/wiki/negato says Adjective negato m. (f. negata, m plural negati, f plural negate) 1. denied, refused negato m. (f. negata, m plural negati, f plural negate) (per) or (in) 1. useless, hopeless (at) Neither that, nor the William Gates pseudonym, are particularly helpful. Wine is built on a web of trust, and if we have no idea who you are -- and if you act like you have something to hide -- we might have to assume that you've purloined Windows source code, and refuse your patch to protect ourselves. So, who are you, really? - Dan
