February 2008 - Wine-devel - list.winehq.org

Re: WineD3D: request alpha in backbuffer mode, to work correctly with multiple opengl pixel formats
by Stefan Dösinger 22 Feb '08

22 Feb '08

Am Freitag, 22. Februar 2008 23:31:43 schrieb Roderick Colenbrander: > Hi, > > In the default backbuffer based renderer in WineD3D the front and > backbuffer share the same pixel format while D3D itself decouples them. A > lot of applications use alpha on the backbuffer, so make sure we have > alpha. This change is needed because the single pixel format which we had > before always had alpha. > + /* In case of ORM_BACKBUFFER, make sure to request an alpha component for X4R4G4B4/X8R8G8B8 as we might need it for the backbuffer. */ It would be for offscreen buffers, not the back buffer. I'm sorry for the confusion in the earlier mail

1 0

Re: 1/2 WGL: remove the pixel format limitation (!)
by Stefan Dösinger 22 Feb '08

22 Feb '08

Am Freitag, 22. Februar 2008 21:16:23 schrieb Roderick Colenbrander: > WineD3D has some small issues due to this change but those should be > investigated by Stefan, Chris, me and others. The code should get a lot of > testing as soon as possible. We discussed this on IRC. The problem is that we're still defaulting to back buffer / aux buffer offscreen rendering, and thus offscreen targets are bound to use the same format as the back buffer. In the D3D9 test this means that the backbuffer is X8R8G8B8, and the onscreen target is A8R8G8B8. The alpha is missing with this patch(used to be always there), so the test fails. The proper fix is to switch to FBOs for onscreen rendering whereever possible(FBO support still has problems that prevent that though), and on cards without FBOs try to use A8R8G8B8 instead of X8R8G8B8 for the backbuffer, and similarly for X1R5G5B5 and X4R4G4B4.

1 1

Re: [Wine] Windows Kernel & Executive implementation
by Volodymyr Shcherbyna 22 Feb '08

22 Feb '08

Unfortunately, that code just do stubs, and it is not actually executed in kernel mode. -- with best regards, Volodymyr 2008/2/22, Dan Kegel <dank(a)kegel.com>: > > On Fri, Feb 22, 2008 at 3:02 AM, Volodymyr Shcherbyna > <v_scherbina(a)mvps.org> wrote: > > > I discovered that WineHQ project does not have support for drivers (am > I > > wrong?). In other words, quite a big amount of applications will fail > to > > function properly, because many of them are using helper device drivers > to > > get some extended functionality. I can just mention RegMon, FileMon, > TDIMom, > > and others. > > > I know very little about this, but my impression is that > Wine supports a limited set of NT os kernel APIs already. > The initial support was added by this patch: > http://www.winehq.org/pipermail/wine-cvs/2007-May/032546.html > The current set of supported calls can be seen here: > http://source.winehq.org/source/dlls/ntoskrnl.exe/ntoskrnl.c > > Feel free to implement more, or file enhancement requests > describing what nt os apis a popular app needs. > > - Dan >

1 0

Re: msi: MsiMergeDatabaseA/W stub
by James Hawkins 22 Feb '08

22 Feb '08

On Thu, Feb 21, 2008 at 2:26 PM, Johan Dahlin <jdahlin(a)async.com.br> wrote: > Add stubs for MsiMergeDatabaseA/W, used by WiX's msi validation. > > diff --git a/dlls/msi/database.c b/dlls/msi/database.c > index 425486e..e74db8f 100644 > --- a/dlls/msi/database.c > +++ b/dlls/msi/database.c > @@ -1119,3 +1119,22 @@ HRESULT create_msi_remote_database( IUnknown *pOuter, LPVOID *ppObj ) > > return S_OK; > } > + > +UINT WINAPI MsiDatabaseMergeW( MSIHANDLE hDatabase, > + MSIHANDLE hDatabaseMerge, > + LPCWSTR szTableName ) > +{ > + FIXME("(%ld %ld %s): stub!\n", hDatabase, hDatabaseMerge, > + debugstr_w(szTableName)); > + return ERROR_SUCCESS; > +} > + > +UINT WINAPI MsiDatabaseMergeA( MSIHANDLE hDatabase, > + MSIHANDLE hDatabaseMerge, > + LPCSTR szTableName ) > +{ > + FIXME("(%ld %ld %s): stub!\n", hDatabase, hDatabaseMerge, > + szTableName); > + > + return ERROR_SUCCESS; > +} > Please use the same style as the rest of the file (4 space indentation). The A version should be before the W version. -- James Hawkins

2 2

Re: [1/2] user32:scroll: Added some tests for scrollbar [try2]
by Anatoly Lyutin 22 Feb '08

22 Feb '08

Alexandre Julliard wrote: > The tests fail: > > ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p > user32_test.exe.so scroll.c && touch scroll.ok > scroll.c:56: Test failed: The scrollbar window should be disabled. > scroll.c:122: Test failed: The ShowScrollBar() should failed. > Yes! These tests must be failed in WINE, but it passes clear in Win XP. I just want to show you some incorrect behavior of scrollbar in WINE. Should I mark these tests as "todo_wine"? -- Best regards Anatoly Lyutin.

2 2

Re: [2/3] qmgr: Implement IUnkown interface for IBackgroundCopyJob.
by Alexandre Julliard 22 Feb '08

22 Feb '08

Dan Hipschman <dsh(a)linux.ucla.edu> writes: > +static ULONG WINAPI BITS_IBackgroundCopyJob_AddRef(IBackgroundCopyJob* iface) > +{ > + ICOM_THIS_MULTI(BackgroundCopyJobImpl, lpVtbl, iface); > + return InterlockedIncrement(&This->ref); > +} There's no reason to use something like ICOM_THIS_MULTI with a single interface. And if you really do have multiple interfaces, please use an inline function instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Printing images
by Alexander Demakin 22 Feb '08

22 Feb '08

Hi all, I have some troubles with printing. BitBlt returns error when calling it for printer context due to implementation of PSDRV_SelectBitmap(). Does anybody know how to implement this function? Where can i find any documentation about it? Implementation of SelectBitmap() in EMFDRV and MFDRV just returns 0. Is it correct? Please, share your ideas. Thanks in advance, Demakin Alexander.

1 0

gdiplus: negative stride from dipCreateBitmapFromFile
by bill lam 22 Feb '08

22 Feb '08

WHen I read a jpeg file of size about 600x400 pixels using gdiplus like this, GdipCreateBitmapFromFile fn BMP GdipGetImageWidth BMP w GdipGetImageHeight BMP h rt=. 0 0, w, h GdipBitmapLockBits BMP rt ImageLockModeRead PixelFormat32bppARGB DATA 'w h s f p r'=. DATA the member stride inside bitmapdata is negative, and its data buffer cannot be read successfully. when using native gdiplus that stride is positive, and it work ok. wine said itself cannot handle negitive stride yet so why itself create a bitmap wih negative stride in GdipCreateBitmapFromFile?

1 0

Re: New dll. Wbemprox.dll
by Alistair Leslie-Hughes 22 Feb '08

22 Feb '08

Ivan Sinitsin wrote: > This patch add new library to the project wine. Name of the library > is - "wbemprox.dll".This library is a part of WMI technology. Now there four > interfaces are described - "IWbemLocator, IWbemServices, > IEnumWbemClassObject, IWbemClassObject". Almost all methods are stubs. > This library is used with some programs like "1C", to get some information > about system. > > static struct regsvr_interface const interface_list[] = { >+ { &IID_IWbemLocator, >+ "IWbemLocator", >+ NULL, >+ 1, /*ÞÉÓÌÏ ÍÅÔÏÄÏ×*/ Comment should be in English. >#define _WIN32_WINNT 0x0600 > >#ifndef __wbemprox_PRIVATE_H__ Defining _WIN32_WINNT doesn't seem right. This patches is large, try breaking it up. Best Regards Alistair Leslie-Hughes

1 0

Fun Project: Add dialogs to builtin IE
by Steven Edwards 22 Feb '08

22 Feb '08

Hi, I submitted a proof of concept patch for this a week or so back that added a simple file->exit menu to the builtin Internet Explorer. I've spoken with Jacek a bit about it and it seems shdocvw.dll is the correct place to implement the UI layout if we are targeting IE versions less the 7. There seems to be a plugin interface the GUI uses for browser extensions but if a first pass I don't think we really need to support it. Unfortuntly due to time constraints I am not going to be able to work on this project so if there is anyone out there that wants to contribute with a simple fun project, please feel free to add menus, dialogs and the address bar. I'll try to help as best I can but I expect to be tied up for some time to come. Thanks Steven -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

1 0