January 2006 - Wine-Devel - list.winehq.org

Symbol fonts bug
by David Moore Jan. 12, 2006

Jan. 12, 2006

Hi, I submitted a patch (attached) on the 15th of December. Without my patch, Solar Fire is broken on Wine, as it can't display its symbol font (codepage 42) correctly. As far as I can tell, according to this documentation: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/unico…, my patch does the right thing in freetype.c to make sure UTF7, UTF8 and Symbol fonts will be displayed properly after going through the affected function call. My patch has not been included yet. I was wondering whether this had anything to do with the format of the patch, the coding style or something else I can fix to get the patch included. This patch is very important to me, so I'm happy to take suggestions to fix it if necessary. thanks, David Moore

1 0

Re: Static control [06/10]: STN_ENABLE and STN_DISABLE notifications
by James Hawkins Jan. 12, 2006

Jan. 12, 2006

On 1/11/06, Michael Kaufmann <hallo(a)michael-kaufmann.ch> wrote: > > > --- static-old.c 2006-01-11 22:43:23.000000000 +0100 > +++ static.c 2006-01-11 22:44:20.000000000 +0100 > @@ -31,10 +31,6 @@ Think you forgot the changelog. -- James Hawkins

2 1

Still need help fixing deadlock (GDI/metafile)
by Cihan Altinay Jan. 12, 2006

Jan. 12, 2006

Hi, I am still trying to finding the reason for PowerPoint 2000 causing a deadlock if a file is opened that contains a preview which itself contains a bitmap >90x90 pixels (ie. on the first slide). After inserting some traces I feel I am pretty close but I'm stuck since before the holidays. The problem is connected to GDI's and/or metafile's StretchBlt (bitblt.c). It calls MFDRV_StretchBlt and then the trouble begins as can be seen from the output: <snip> trace:bitblt:StretchBlt --Start-- trace:gdi:GDI_GetObjPtr (0x3b0c): enter 1 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3b0c): leave 1 trace:gdi:GDI_GetObjPtr (0x3aec): enter 1 trace:dc:DC_GetDCPtr trace:gdi:GDI_GetObjPtr (0x3b0c): enter 2 trace:dc:DC_GetDCPtr trace:bitblt:StretchBlt 0x3aec 0,0 160x120 -> 0x3b0c 0,0 960x720 rop=cc0020 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GetObjectW 0x3af8 24 0x7fc2f760 trace:gdi:GDI_GetObjPtr (0x3af8): enter 3 trace:gdi:GDI_ReleaseObj (0x3af8): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:metafile:MFDRV_StretchBlt MF_StretchBltViaDIB->len = 20292 rop=cc0020 PixYPM=3780 Caps=96 trace:bitmap:GetDIBits trace:dc:CreateCompatibleDC --Checking lock-- hdc=0x3aec err:syslevel:_CheckNotSysLevel Holding lock 0x7fad49e0 level 3 </snip> Yes well... hdcDst and hdcSrc aren't freed yet from within StretchBlt. There is a comment "FIXME: there is a race condition here". Could that be the cause for the deadlock? Btw. this might be the same problem as bug #3125 as both refer to the preview and both cause a deadlock. Can somebody give me a hint on how to tackle this? It is really important for us... If you need more output please let me know. Thanks a lot, Cihan

2 3

Regression caused by "ntdll: Check file size when mapping image sections to avoid SIGBUS errors."
by Troy Rollo Jan. 11, 2006

Jan. 11, 2006

On Wed, 4 Jan 2006 08:21, Alexandre Julliard wrote: > Module: wine > Branch: refs/heads/master > Commit: 67f29999a36ce3725a52b79ed618964244cc96ae ... > status = STATUS_INVALID_IMAGE_FORMAT; /* generic error */ > + if (header_size > st.st_size) goto error; > if (map_file_into_view( view, fd, 0, header_size, 0, VPROT_COMMITTED | ... This change prevents Wine from loading Win32 executables that are less than 64K long. header_size is 65536, but st.st_size is less than that. -- Troy Rollo - wine(a)troy.rollo.name

2 3

Re: ntdll/tests: Load test on win95 again
by Alexandre Julliard Jan. 11, 2006

Jan. 11, 2006

Detlef Riekenberg <wine.dev(a)web.de> writes: > Changelog: > > - ntdll/tests: Load test on win95 again > (kernel32,CreateWaitableTimerA not present) A better fix would be to avoid the call completely, the ntdll tests shouldn't need to use kernel32 functions. -- Alexandre Julliard julliard(a)winehq.org

3 5

Re: A modest proposal
by gslink Jan. 11, 2006

Jan. 11, 2006

The whole point of what I am proposing is a collaboration with RH so that new features are in the distributed Wine. If they are willing to undertake one of the tasks that Wine HQ is now doing then we should let them. At least they are supposed to know RH so they should be capable of the task. This would free manpower for some sorely needed other tasks.

1 0

Re: modifying _fullpath test
by Alexandre Julliard Jan. 11, 2006

Jan. 11, 2006

Aric Stewart <aric(a)codeweavers.com> writes: > ChangeLog: > modify msvcrt dir test to create its own directory to ensure the directory > exists for the test. It would be better to use something like GetTempPath instead of hardcoding the directory name. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: modifying _fullpath test
by Dmitry Timoshkov Jan. 11, 2006

Jan. 11, 2006

"Aric Stewart" <aric(a)codeweavers.com> wrote: > ChangeLog: > modify msvcrt dir test to create its own directory to ensure the directory > exists for the test. > - SetCurrentDirectory("C:\\Windows\\System\\"); > + free1=free2=TRUE; > + rc = CreateDirectory("C:\\msvcrt-test\\",NULL); > + if (!rc && GetLastError()==ERROR_ALREADY_EXISTS) > + free1=FALSE; > + rc = CreateDirectory("C:\\msvcrt-test\\nextlevel\\",NULL); > + if (!rc && GetLastError()==ERROR_ALREADY_EXISTS) > + free2=FALSE; > + SetCurrentDirectory("C:\\msvcrt-test\\nextlevel\\"); Drive C: root directory is not the best place to create temporary directories, I'd suggest to use GetTempPath (and maybe GetTempFileName) to get a more appropriate starting point. -- Dmitry.

1 0

Re: advpack: Implement ExtractFiles
by Mike McCormack Jan. 11, 2006

Jan. 11, 2006

James Hawkins wrote: > What is the policy about attaching changes to tests that pass because > of a patch sent in? Should I also diff the tests? There's a higher level policy of "all changes should be atomic", which requires Wine to be in a working state before and after each change, so yes, you should update tests that pass with the patch that makes them pass. If you're adding new tests, it makes sense to send them in a seperate patch after the patch that implements functionality to make the new tests pass. Mike

1 0

Need help to fix a failing test
by Kai Blin Jan. 10, 2006

Jan. 10, 2006

Hi folks, As far as I can see, secur32 tests are failing on all windows platforms right now. (http://test.winehq.org/data/200601101000/) Now, this seems to be due to the following: main.c:475: Test failed: cbMaxToken for NTLM is 1904, not 12000. I'm pretty sure that I got the 12000 from my win2k system when I compiled the test code there using the platform sdk that was current this july. Now, I have no clue where the 1904 comes from, but if windows really uses a cbMaxToken of 1904, I need to fix that in my code (I couldn't use the 12000 I thought I had to implement before due to implementation restrictions. I can easily work with 1904, if those are correct.) Still, I'm sure I didn't pull the 12000 out of my sleeve. Could I ask someone who runs msvc and a platform sdk to build the secur32 tests, run them on any windows box and send the results to me? Thanks in advance, Kai -- Kai Blin, (blin at gmx dot net) Are you mentally here at Pizza Hut??

1 0