wine-devel December 2005

wine-devel@winehq.org

147 participants
299 discussions

Should the AppDB make public the number of unique page views each app gets?
by Scott Ritchie 25 Jan '06

25 Jan '06

This was an idea we discussed in IRC for a short bit, and I think it would be good to bring it up here. Essentially, if the AppDB displayed the number of page views each app got it would go a long way towards estimating the demand for particular applications, whether they work or not. It seems fair to say that someone looking an app up in the AppDB either wants to run it in Wine or wants to know if it's doable should he switch to Wine. Coincidentally, this also helps solve the voting problem - since votes for gold apps are supposed to be replaced with votes for apps that work should be done on, we now have a mechanism to sort the Gold list other than by votes. Sorting the gold list by page views would also greatly help navigation from the front page of the AppDB, as it would place the most popular applications at the top. Then again, maybe there's something I've overlooked. Thoughts? -Scott Ritchie

4 3

Problem with WineD3D Surface Locking
by Stefan Dösinger 24 Jan '06

24 Jan '06

Hello, I've spotted a bug in WineD3D's surface locking, and I have no clue how to fix this. The problem is that unlocking the back buffer causes it to become completely black, no matter what's written to it's memory or what has been there before. I have written a small D3D9 test app which shows this behavior: Compile it with "winemaker .", followed by make, and run it. Pressing ESC will cause it to quit, pressing any other keys makes IDirect3DDevice9::Clear call on the back buffer, with a color value based on the pressed keys. A click anywhere will LockRect() the whole backbuffer, write 0xff into the whole locked memory, and UnlockRect() it. The screen should become completely white, but instead it goes black. With the fglrx driver and 24 bit color depth it shows the correct behavior, but with any other driver(radeon, software rendering) or 16 bit color depth, it doesn't work. The bug is somehow related to some GL calls in UnlockRect(glPixelZoom and glOrtho), but I couldn't find anything specific. I hope you can help me, I am quite stuck here, Stefan

2 4

Invisible fonts - unimplemented SPI_GETFONTSMOOTHINGTYPE
by Peter Åstrand 19 Jan '06

19 Jan '06

I'm trying to get the application "Nya Multigram" (http://www.softogram.se/multigramkunskapsbanken.html) running in Wine. It works somewhat, but the initial screen (which should look like http://www.softogram.se/grafik/multigramkunskapsbanken/mgkbscreenshot4.jpg) doesn't have any text. The buttons are rendered very slowly, and this error message appears: fixme:system:SystemParametersInfoW Unimplemented action: 8202 (SPI_GETFONTSMOOTHINGTYPE) A screenshot is available at http://www.cendio.com/~peter/multigram.png. A partial log when running with WINEDEBUG=+font,+nativefont,+wc_font is included below. Any ideas on how to solve this? trace:font:GetTextMetricsW text metrics: Weight = 700 FirstChar = 32 AveCharWidth = 16 Italic = 0 LastChar = 64258 MaxCharWidth = 16 UnderLined = 0 DefaultChar = 0 Overhang = 0 StruckOut = 0 BreakChar = 32 CharSet = 0 PitchAndFamily = 36 -------------------- InternalLeading = 4 Ascent = 24 Descent = 6 Height = 30 fixme:system:SystemParametersInfoW Unimplemented action: 8202 (SPI_GETFONTSMOOTHINGTYPE) trace:font:WineEngCreateFontInstance L"System", h=16, it=0, weight=400, PandF=22, charset=0 orient 0 escapement 0 trace:font:WineEngCreateFontInstance returning cached gdiFont(0x7fe9b888) for hFont 0x7c trace:font:X11DRV_SelectFont hdc=0x1154, hfont=0x7c trace:font:X11DRV_SelectFont gdiFont = 0x7fe9b888 trace:font:WineEngCreateFontInstance L"System", h=16, it=0, weight=400, PandF=22, charset=0 orient 0 escapement 0 trace:font:WineEngCreateFontInstance returning cached gdiFont(0x7fe9b888) for hFont 0x7c trace:font:X11DRV_SelectFont hdc=0x2284, hfont=0x7c trace:font:X11DRV_SelectFont gdiFont = 0x7fe9b888 trace:font:X11DRV_SelectFont hdc=0x2284, hfont=0x7c trace:font:X11DRV_SelectFont gdiFont = 0x7fe9b888 trace:font:X11DRV_SelectFont hdc=0x2284, hfont=0x7c trace:font:X11DRV_SelectFont gdiFont = 0x7fe9b888 trace:font:X11DRV_SelectFont hdc=0x2284, hfont=0x7c trace:font:X11DRV_SelectFont gdiFont = 0x7fe9b888 trace:font:WineEngCreateFontInstance L"Arial", h=31, it=0, weight=700, PandF=00, charset=0 orient 0 escapement 0 trace:font:WineEngCreateFontInstance returning cached gdiFont(0x7b7abd70) for hFont 0xec8 trace:font:X11DRV_SelectFont hdc=0x2218, hfont=0xec8 trace:font:X11DRV_SelectFont gdiFont = 0x7b7abd70 trace:font:X11DRV_SelectFont hdc=0x1154, hfont=0x7c trace:font:X11DRV_SelectFont gdiFont = 0x7fe9b888 trace:font:WineEngCreateFontInstance L"Arial", h=31, it=0, weight=700, PandF=00, charset=0 orient 0 escapement 0 trace:font:WineEngCreateFontInstance returning cached gdiFont(0x7b7abd70) for hFont 0xec8 trace:font:X11DRV_SelectFont hdc=0x1154, hfont=0xec8 trace:font:X11DRV_SelectFont gdiFont = 0x7b7abd70 -- Peter Åstrand ThinLinc Chief Developer Cendio www.cendio.se Teknikringen 3 583 30 Linköping Phone: +46-13-21 46 00

4 12

Re: [bug 4004] MenuItemInfo vs GetMenuString
by Dmitry Timoshkov 18 Jan '06

18 Jan '06

"Ann & Jason Edmeades" <us(a)edmeades.me.uk> wrote: > Copy and store the dwTypeData of a menu item even for a ownerdraw item, and > ensure the memory allocations/freeing occurs correctly > + /* Just change ftype to string and see what text is stored */ > + memset(&info, 0x00, sizeof(info)); > + info.cbSize= sizeof(MENUITEMINFO); > + info.fMask= MIIM_FTYPE; /* Set string type */ > + info.fType= MFT_STRING; > + info.dwTypeData= (char *)0xdeadbeef; > + SetMenuItemInfo( hmenu, 0, TRUE, &info ); > + > + /* Did we keep the old dwTypeData? */ > + ok (GetMenuString( hmenu, 0, strback, 99, MF_BYPOSITION), "GetMenuString on ownerdraw entry failed\n"); > + ok (!strcmp( strback, "Dummy string" ), "Menu text from Ansi version incorrect\n"); > + > + /* Just change ftype to bitmap and back to ensure data isnt freed */ > + memset(&info, 0x00, sizeof(info)); > + info.cbSize= sizeof(MENUITEMINFO); > + info.fMask= MIIM_FTYPE; /* Set as bitmap type */ > + info.fType= MFT_BITMAP; > + info.dwTypeData= (char *)0xdeadbee2; > + SetMenuItemInfo( hmenu, 0, TRUE, &info ); > + info.fType= MFT_OWNERDRAW; /* Set as ownerdraw type */ > + info.dwTypeData= (char *)0xdeadbee3; > + SetMenuItemInfo( hmenu, 0, TRUE, &info ); You don't check SetMenuItemInfo return code after the above calls and I very much suspect that they fail leading to the observed results. -- Dmitry.

5 15

Re: PATCH/RFC: defer OLE apartment window creation
by Marcus Meissner 18 Jan '06

18 Jan '06

On Wed, Dec 21, 2005 at 02:55:14AM +0000, Robert Shearman wrote: > Marcus Meissner wrote: > > >@@ -257,6 +254,15 @@ > > return apt; > >} > > > >+void make_apartment_window(APARTMENT *apt) { > >+ if (apt->win) return; > >+ if (!(apt->model & COINIT_APARTMENTTHREADED)) > >+ return; > >+ apt->win = CreateWindowW(wszAptWinClass, NULL, 0, > >+ 0, 0, 0, 0, > >+ 0, 0, OLE32_hInstance, NULL); > >+} > >+ > > > > This isn't thread-safe. It would also be better to make this an accessor > function for the win field of struct apartment and fix up all callers to > use this. I still have to verify on Windows whether this is what it does > or whether it does something funny with message loops. I lack the time and testing abilities to do this right now (and now on xmas break). Its just a quick hack to get Google Earth running. It is now up to showing the famous GL "black screen". :( (WINEDLLOVERRIDES=*usp10=n) Ciao, Marcus

2 2

WINE 0.9.3 and Photoshop 7 & CS
by Aleksey 06 Jan '06

06 Jan '06

Yesterday I upgraded to WINE 0.9.3, and then tried running Photoshop 7. Photoshop gave me a hardware error. I thought, no problem, I'll just reinstall it, same result. Then I reconfigured WINE using winetools and tried again, same thing. Here is what I got in the Terminal when running Photoshop 7: fixme:actctx:QueryActCtxW stub! fixme:font:WineEngRemoveFontResourceEx :stub fixme:win:EnumDisplayDevicesW ((null),0,0x7fa7de2c,0x00000000), stub! fixme:win:EnumDisplayDevicesW (L"\\\\.\\DISPLAY1",0,0x7fa7de2c,0x00000000), stub! fixme:mscms:EnumColorProfilesA ( (nil), 0x7fa7e694, 0x7fa7e1ac, 0x7fa7e6f4, 0x7fa7e704 ) stub fixme:win:EnumDisplayDevicesW ((null),0,0x7fa7de34,0x00000000), stub! fixme:win:EnumDisplayDevicesW (L"\\\\.\\DISPLAY1",0,0x7fa7de34,0x00000000), stub! fixme:mscms:EnumColorProfilesA ( (nil), 0x7fa7e69c, 0x7fa7e1b4, 0x7fa7e6fc, 0x7fa7e70c ) stub err:shell:HCR_GetFolderAttributes HCR_GetFolderAttributes should be called for simple PIDL's only! fixme:font:WineEngRemoveFontResourceEx :stub fixme:font:WineEngRemoveFontResourceEx :stub Then I tried installing Photoshop CS, knowing that it worked fine with 0.9.2. Photoshop CS told me that certain required files was missing, but I forgot to get down the results from the Terminal. After that I downgraded to WINE 0.9.2 and both versions of Photoshop work great. A little side note: ImageReady 7 works great under 0.9.3, I did not test ImageReady CS. ImageReady 7 works great under 0.9.2 also, but ImageReady CS crashes. God Bless. - Aleksey

6 8

safedisc
by Ivan Leo Puoti 04 Jan '06

04 Jan '06

Raphael Junqueira asked on bugzilla what the safedisc status is. Currently it works fine, and I believe what we have is more or less ready for CVS. However Vitaly told me Alexandre didn't like the object manager Vitaly wrote, mostly he didn't like permanent objects, that drivers depend on. I haven't talked to Alexandre about this but hopefully some reasonable solution can be found so we can get Vitaly's OM into wineserver (I mean my original implementation that uses pointers as handles also works, but things look better with a real OM). So let's try and trigger some community discussion, we are talking about the guts of wine after all. Vitaly, what's the OM status currently? Alexandre, what didn't you like about it? Ivan.

4 3

Re: ntdll: Implement few Dbg* functions.
by Eric Pouech 03 Jan '06

03 Jan '06

Vitaliy Margolen wrote: > ChangeLog: > ntdll: Implement few Dbg* functions. > kernel32: Use new Dbg* functions instead of server calls. > + status = DbgUiDebugActiveProcess( hProc ); > + status = DbgUiStopDebugging( hProc ); > - if (self) DbgBreakPoint(); I wonder if we shouldn't use NtDbgActiveProcess, NtRemoveProcessDebug instead. A+ -- Eric Pouech

2 6

Re: MSACM: initialize some ACMSTREAMHEADER fields for the sake of native codecs
by Eric Pouech 03 Jan '06

03 Jan '06

Alex Villacís Lasso wrote: > The ACMAPP sample application from MSDN reveals this annoying bug in > playback: with a native ACM codec (such as the Ogg Vorbis one bundled > with some Japanese RPGs), builtin msacm will successfully tell the codec > to decode the first two frames of compressed audio, and then the sound > will loop on these two frames. What is really happening is that winmm is > using double-buffering, and reusing the ACMSTREAMHEADER structures for > playback, and acmStreamConvert simply passes the structures into the > codec, without clearing cb[Src|Dst]LengthUsed (here is the bug) which > was set in the previous call to acmStreamConvert on that > ACMSTREAMHEADER. The native codec *expects* these fields to be set to 0, > and refuses to decode otherwise. well, you should check who is supposed to clear those flags between msacm or winmm (I suppose wavemap). A+ -- Eric Pouech

2 2

Re: opengl: Add support for rendering on bitmaps
by Tomas Carnecky 03 Jan '06

03 Jan '06

Huw D M Davies wrote: > Huw Davies <huw(a)codeweavers.com> > Add support for rendering on bitmaps This patch breaks World of Warcraft, reverting this patch makes WoW work again. This is the error: X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 142 (GLX) Minor opcode of failed request: 13 (X_GLXCreateGLXPixmap) Serial number of failed request: 410 Current serial number in output stream: 411 tom

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel December 2005