wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: [DSOUND] little patch
by Robert Reif 15 Mar '05

15 Mar '05

Raphael wrote: >Hi > >Changelog: > - try to have better match caps with hw caps so games can active more hw >support > >Regards, >Raphael > > > >- This->lock.DebugInfo->Spare[1] = 0; >+ /*This->lock.DebugInfo->Spare[1] = 0;*/ > DeleteCriticalSection(&(This->lock)); > > You have to zero this out or DeleteCriticalSection will try to delete that static memory. >+ if (pDS->drvcaps.dwFlags | DSCAPS_PRIMARYMONO) pDS->pwfx->nChannels = 1; >+ if (pDS->drvcaps.dwFlags | DSCAPS_PRIMARY16BIT) pDS->pwfx->wBitsPerSample = 16; >+ pDS->pwfx->nBlockAlign = pDS->pwfx->wBitsPerSample * pDS->pwfx->nChannels / 8; >+ pDS->pwfx->nAvgBytesPerSec = pDS->pwfx->nSamplesPerSec * pDS->pwfx->nBlockAlign; >+ > You can't do this and be compatible with windows. > >+#ifndef __WINE_DSOUND_PRIVATE_H >+#define __WINE_DSOUND_PRIVATE_H > You can't include this more than once because there is only one .h file so it's not really necessary. >+#define WINE_SET_CS_NAME(cs, name) (cs)->DebugInfo->Spare[1] = (DWORD) name >+#define WINE_GET_CS_NAME(cs) (const char*) (cs)->lock.DebugInfo->Spare[1] > > This is a wine specific trick and should probably be put somewhere global so all users can be consistent. The name should have DEBUG in it somewhere.

3 5

Re: wine/ misc/registry.c documentation/samples/co ...
by Dimitrie O. Paun 15 Mar '05

15 Mar '05

On Mon, Mar 14, 2005 at 11:18:40AM -0600, Alexandre Julliard wrote: > Log message: > Get rid of the remaining registry configuration parameters. Any plans on getting the global registry back? -- Dimi.

2 1

Problems with VirtualAlloc/Lock
by MIchael Ost 15 Mar '05

15 Mar '05

There are major differences in the handling of virtual memory in Wine vs WinXP that are causing problems for my winelib application. Can someone provide background and/or workarounds for these issues? As near as I can tell the main differences are: * VirtualLock does nothing in Wine * Wine makes no distinction between MEM_RESERVE and MEM_COMMIT * Wine has no implementation of Windows' process working sets * Wine limits MEM_RESERVE to 1GB, but WinXP goes up to 2GB The above problems seem relatively harmless on systems with < 1GB RAM. But when our units go greater than 1GB we are seeing spectacular crash-and-burn failures. The code-only DLLs we are running on such systems are crashing at a stage when I suspect they are attempting to lock RAM. I suspect that they are confused by the report from GlobalMemoryStatus that more than 1GB of RAM is installed, but that they are only able to VirtualLock up to 1GB. And in this unexpected situation, they are crashing. Further, these DLLs are audio processing plugins. The apparent fact that VirtualLock doesn't _actually_ lock memory into RAM for real time processing is a disaster for our system, in that it causes audio glitches when a page fault is handled. But that is not a problem which crashes the system. Any suggestions on what to do? Is there any pending work on this area out there? I've attached a little table that describes what I found. It shows the differences in how Wine and WinXP handle memory related calls. I have also attached a simple program which can be run to see these differences. Thanks for any help... mo

4 4

Re: combo - implement GetComboBoxInfo
by Dimitrie O. Paun 15 Mar '05

15 Mar '05

On Mon, Mar 14, 2005 at 08:02:00PM -0800, Steven Edwards wrote: > - FIXME("\n"); > - return FALSE; > + LPHEADCOMBO lphc = (LPHEADCOMBO)GetWindowLongA( hwndCombo, 0 ); Please use GetWindowLongW(), the combo box is fully Unicode. > + pcbi->hwndCombo = hwndCombo; > + pcbi->hwndList = lphc->hWndLBox; > + pcbi->hwndItem = lphc->hWndEdit; > + pcbi->rcItem = lphc->textRect; > + pcbi->rcButton = lphc->buttonRect; > + pcbi->stateButton = (DWORD) lphc->wState; Fancy formatting... Bit yucky, no? -- Dimi.

2 1

Re: combo - implement GetComboBoxInfo
by Dmitry Timoshkov 15 Mar '05

15 Mar '05

"Steven Edwards" <steven_ed4153(a)yahoo.com> wrote: > BOOL WINAPI GetComboBoxInfo(HWND hwndCombo, /* [in] handle to combo box */ > PCOMBOBOXINFO pcbi /* [in/out] combo box information */) > { > - FIXME("\n"); > - return FALSE; > + LPHEADCOMBO lphc = (LPHEADCOMBO)GetWindowLongA( hwndCombo, 0 ); > + > + pcbi->hwndCombo = hwndCombo; > + pcbi->hwndList = lphc->hWndLBox; > + pcbi->hwndItem = lphc->hWndEdit; > + pcbi->rcItem = lphc->textRect; > + pcbi->rcButton = lphc->buttonRect; > + pcbi->stateButton = (DWORD) lphc->wState; > > + return TRUE; > } Is it possible to do a check for lphc being NULL and keep indentation/spacing similar to the rest of the file? Also (DWORD) cast should not be needed. -- Dmitry.

1 0

Re: combo - implement GetComboBoxInfo
by Steven Edwards 15 Mar '05

15 Mar '05

--- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > Please use GetWindowLongW(), the combo box is fully Unicode. OK I will hack it for him. This guy is new to C programing and I should have caught that. He has a bunch of VB apps that he uses this function in. > > + pcbi->hwndCombo = hwndCombo; > > + pcbi->hwndList = lphc->hWndLBox; > > + pcbi->hwndItem = lphc->hWndEdit; > > + pcbi->rcItem = lphc->textRect; > > + pcbi->rcButton = lphc->buttonRect; > > + pcbi->stateButton = (DWORD) lphc->wState; > > Fancy formatting... Bit yucky, no? Argh. Welcome to the Visual Studio 2005 Beta1, It even fscks your formatting in all sorta nice new ways. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

Re: MSN Webcam patch
by Jasper van Veghel 15 Mar '05

15 Mar '05

I have to be off somewhere in a few minutes (hence me being up this early), so I'll make this quick ;-) I wrote a couple of patches for webcam support too a while back, and gave these to some people who were asking for them, so I thought I'd share them here now, to also provide some input on it - mind you that I haven't worked on this for a while now, so it's not really as fresh in my memory anymore, but with this rece- nt interest in it I guess I'll start looking into it again too. Of course MSN still crashes after it's signed in .. but that's beside the point here, really now ;-) Would be nice to get the webcam preview stuff working tho, and make some headway with V4L and Wine along the way. Some of the things that you've changed I've changed, but aren't in the patches below - I really should document what I change as I go along ;-) Most of the major changes are there though. I also got stuck at qcap, but ended up simply using a native DLL for that. Again, I was really just tinkering along, seeing how far I could go without having to implement some major interface, using both native and builtin DLLs. Anyway, I'll see if I can find some time tomorrow to look back into it; I did have a lot of fun hacking on Wine, and indespite of my inexperience regarding DirectX, I'll try to contribute back some more useful patches, hopefully ulti- mately getting that webcam support working. Kind regards, Jasper ----- Forwarded message from Jasper van Veghel <vanveghel(a)home.nl> ----- Date: Sat, 15 Jan 2005 14:18:47 +0100 From: Jasper van Veghel <vanveghel(a)home.nl> To: xerox_xerox2000(a)yahoo.co.uk, lgvlenders(a)yahoo.co.uk Subject: Re: video4linux - wine Hey Luis, Robbert, It's been a few weeks ago since I've worked on this stuff; I wrote some note- worthy patches and some hacks to get MSN working; I'll let you decide what's what ;-) In dlls/wininet/ I made the following two changes; The first is to get it to connect to MSN (not camera-related), as it tries to send text over SSL for some reason.. not sure if this is necessary (anymore) though, with rsabase and all: --- netconnection.c.old 2005-01-15 13:46:46.000000000 +0100 +++ netconnection.c 2004-12-14 22:38:19.000000000 +0100 @@ -104,7 +104,7 @@ void NETCON_init(WININET_NETCONNECTION *connection, BOOL useSSL) { - connection->useSSL = useSSL; + connection->useSSL = /*useSSL*/0; connection->socketFD = -1; if (connection->useSSL) { Note the date on those files by the way; they were taken from CVS around 12/14/04, so it's not a complete diff to the recent CVS. This one takes care of an unknown / undocumented optionId in InternetSetOptionAW that MSN uses in dlls/wininet/: --- internet.c.old 2005-01-15 13:55:56.000000000 +0100 +++ internet.c 2004-12-14 17:29:42.000000000 +0100 @@ -1962,6 +1962,9 @@ case INTERNET_OPTION_CONNECTED_STATE: FIXME("Option INTERNET_OPTION_CONNECTED_STATE: STUB\n"); break; + case 87: + FIXME("Undocumented option 87: STUB\n"); + break; default: FIXME("Option %ld STUB\n",dwOption); INTERNET_SetLastError(ERROR_INVALID_PARAMETER); Of more interest might be this change to dlls/devenum/createdevenum.c: --- createdevenum.c.old 2005-01-15 14:02:24.000000000 +0100 +++ createdevenum.c 2004-12-27 22:07:27.000000000 +0100 @@ -117,7 +117,8 @@ if (IsEqualGUID(clsidDeviceClass, &CLSID_AudioRendererCategory) || IsEqualGUID(clsidDeviceClass, &CLSID_AudioInputDeviceCategory) || - IsEqualGUID(clsidDeviceClass, &CLSID_MidiRendererCategory)) + IsEqualGUID(clsidDeviceClass, &CLSID_MidiRendererCategory) || + IsEqualGUID(clsidDeviceClass, &CLSID_VideoInputDeviceCategory)) { hbasekey = HKEY_CURRENT_USER; strcpyW(wszRegKey, wszActiveMovieKey); @@ -142,7 +143,8 @@ { if (IsEqualGUID(clsidDeviceClass, &CLSID_AudioRendererCategory) || IsEqualGUID(clsidDeviceClass, &CLSID_AudioInputDeviceCategory) || - IsEqualGUID(clsidDeviceClass, &CLSID_MidiRendererCategory)) + IsEqualGUID(clsidDeviceClass, &CLSID_MidiRendererCategory) || + IsEqualGUID(clsidDeviceClass, &CLSID_VideoInputDeviceCategory)) { HRESULT hr = DEVENUM_CreateSpecialCategories(); if (FAILED(hr)) @@ -411,6 +413,55 @@ CoTaskMemFree(pTypes); } } + + res = DEVENUM_CreateAMCategoryKey(&CLSID_VideoInputDeviceCategory); + if (SUCCEEDED(res)) { /* can register device(s) in this category */ + for (i = 0; i < 10; i++) { // the index can range from 0 thru 9 + WCHAR szDeviceName[80], szDeviceVersion[80]; + + if (capGetDriverDescriptionW ((WORD) i, + szDeviceName, sizeof (szDeviceName), + szDeviceVersion, sizeof (szDeviceVersion))) { + IMoniker * pMoniker = NULL; + + TRACE("\nSuccess !\n"); + + rfp2.nMediaTypes = 1; + pTypes = CoTaskMemAlloc(rfp2.nMediaTypes * + sizeof(REGPINTYPES)); + if (!pTypes) { + IFilterMapper2_Release(pMapper); + + return E_OUTOFMEMORY; + } + + /* FIXME: Not sure if these are correct */ + pTypes[0].clsMajorType = &MEDIATYPE_Video; + pTypes[0].clsMinorType = &MEDIASUBTYPE_RGB24; + + rfp2.lpMediaType = pTypes; + + res = IFilterMapper2_RegisterFilter(pMapper, + // &CLSID_VideoRenderer, + &CLSID_VfwCapture, + szDeviceName, + &pMoniker, + &CLSID_VideoInputDeviceCategory, + szDeviceName, + &rf2); + + /* FIXME: do additional stuff with IMoniker here, depending on what RegisterFilter does */ + + if (pMoniker) + IMoniker_Release(pMoniker); + + if (i == iDefaultDevice) + FIXME("Default device\n"); + + CoTaskMemFree(pTypes); + } + } + } } if (pMapper) And a small addition to devenum_private.h: --- devenum_private.h.old 2005-01-15 14:06:39.000000000 +0100 +++ devenum_private.h 2004-12-26 22:01:19.000000000 +0100 @@ -26,6 +26,7 @@ #include "windef.h" #include "winbase.h" +#include "wingdi.h" #include "winuser.h" #include "winreg.h" #include "winerror.h" @@ -38,6 +39,7 @@ #include "olectl.h" #include "wine/unicode.h" #include "uuids.h" +#include "vfw.h" /********************************************************************** * Dll lifetime tracking declaration for devenum.dll And the Makefile (dlls/devenum/Makefile.in): --- Makefile.in.old 2005-01-15 14:11:31.000000000 +0100 +++ Makefile.in 2005-01-15 14:13:36.000000000 +0100 @@ -3,7 +3,7 @@ SRCDIR = @srcdir@ VPATH = @srcdir@ MODULE = devenum.dll -IMPORTS = ole32 oleaut32 winmm user32 advapi32 kernel32 +IMPORTS = ole32 oleaut32 winmm avicap32 user32 advapi32 kernel32 EXTRALIBS = -lstrmiids -luuid C_SRCS = \ And so we add some to capGetDriverDescrptionAW aswell (dlls/avicap32/); I just added some static labels, not really getting these anywhere yet: --- avicap32_main.c.old 2005-01-15 14:15:43.000000000 +0100 +++ avicap32_main.c 2004-12-27 22:21:22.000000000 +0100 @@ -69,11 +69,22 @@ BOOL VFWAPI capGetDriverDescriptionA(WORD wDriverIndex, LPSTR lpszName, INT cbName, LPSTR lpszVer, INT cbVer) { - FIXME("(%d, %p, %d, %p, %d) stub!\n", wDriverIndex, lpszName, cbName, + FIXME("stub: (%d, %p, %d, %p, %d) stub!\n", wDriverIndex, lpszName, cbName, lpszVer, cbVer); - return FALSE; + + // FIXME: Make use of Video4Linux here + + strncpy (lpszName, "Logitech QuickCam Pro 4000", cbName); + strncpy (lpszVer, "Wine Video4Linux Driver", cbVer); + + return TRUE; } +WCHAR x1[] = {'L','o','g','i','t','e','c','h',' ','Q','u','i','c','k','c','a', + 'm',' ','P','r','o',' ','4','0','0','0',0}, + x2[] = {'W','i','n','e',' ','V','i','d','e','o','4','L','i','n','u','x', + ' ','d','r','i','v','e','r',0}; + /*********************************************************************** * capGetDriverDescriptionW (AVICAP32.@) */ @@ -82,5 +93,11 @@ { FIXME("(%d, %p, %d, %p, %d) stub!\n", wDriverIndex, lpszName, cbName, lpszVer, cbVer); - return FALSE; + + // FIXME: Make use of Video4Linux here + + lstrcpynW (lpszName, x1, cbName); + lstrcpynW (lpszVer, x2, cbVer); + + return TRUE; } And the dlls/avicap32/Makefile.in changes for the strcpy stuff: --- Makefile.in.old 2005-01-15 14:15:34.000000000 +0100 +++ Makefile.in 2004-12-26 22:55:13.000000000 +0100 @@ -3,7 +3,7 @@ SRCDIR = @srcdir@ VPATH = @srcdir@ MODULE = avicap32.dll -IMPORTS = ntdll +IMPORTS = unicows ntdll C_SRCS = avicap32_main.c Next up is dlls/quartz, which seemed to handle the DirectShow filter thingies; first off there's include/config.idl: --- control.idl.old 2005-01-15 15:07:23.000000000 +0100 +++ control.idl 2004-12-27 04:25:25.000000000 +0100 @@ -26,6 +26,7 @@ interface IBasicAudio; interface IBasicVideo; interface IVideoWindow; +interface IAMStreamConfig; interface IMediaEvent; interface IMediaEventEx; @@ -123,6 +124,22 @@ HRESULT IsCursorHidden( [out] long *CursorHidden ); } +/***************************************************************************** + * IAMStreamConfig interface + */ +[ + object, + uuid(c6e13340-30ac-11d0-a18c-00a0c9118956), + pointer_default(unique) +] +interface IAMStreamConfig : IUnknown +{ + HRESULT SetFormat( [in] AM_MEDIA_TYPE *pmt); + HRESULT GetFormat( [in] AM_MEDIA_TYPE **pmt); + HRESULT GetNumberOfCapabilities( [out] int *piCount, [out] int *piSize); + HRESULT GetStreamCaps( [in] int iIndex, [out] AM_MEDIA_TYPE **pmt, + [out] BYTE *pSCC); +} /***************************************************************************** * IBasicVideo interface And of course the generated interface from this, added to videorenderer.c, plus some partial implementation stuff (if someone could finish this, plus add an implementation for IKsPin, they'd probably be well on their way (provided that is that it's actually coupled to a capturing device, rather then have bogus data in it as I've done here)) --- videorenderer.c.old 2005-01-15 14:39:24.000000000 +0100 +++ videorenderer.c 2004-12-27 21:15:01.000000000 +0100 @@ -48,12 +48,14 @@ static IBasicVideoVtbl IBasicVideo_VTable; static IVideoWindowVtbl IVideoWindow_VTable; static const IPinVtbl VideoRenderer_InputPin_Vtbl; +static IAMStreamConfigVtbl IAMStreamConfig_VTable; typedef struct VideoRendererImpl { const IBaseFilterVtbl * lpVtbl; IBasicVideoVtbl * IBasicVideo_vtbl; IVideoWindowVtbl * IVideoWindow_vtbl; + IAMStreamConfigVtbl * IAMStreamConfig_vtbl; ULONG refCount; CRITICAL_SECTION csFilter; @@ -327,6 +329,7 @@ pVideoRenderer->lpVtbl = &VideoRenderer_Vtbl; pVideoRenderer->IBasicVideo_vtbl = &IBasicVideo_VTable; pVideoRenderer->IVideoWindow_vtbl = &IVideoWindow_VTable; + pVideoRenderer->IAMStreamConfig_vtbl = &IAMStreamConfig_VTable; pVideoRenderer->refCount = 1; InitializeCriticalSection(&pVideoRenderer->csFilter); @@ -378,6 +381,8 @@ *ppv = (LPVOID)&(This->IBasicVideo_vtbl); else if (IsEqualIID(riid, &IID_IVideoWindow)) *ppv = (LPVOID)&(This->IVideoWindow_vtbl); + else if (IsEqualIID(riid, &IID_IAMStreamConfig)) + *ppv = (LPVOID)&(This->IAMStreamConfig_vtbl); if (*ppv) { @@ -1556,3 +1561,172 @@ Videowindow_HideCursor, Videowindow_IsCursorHidden }; + + +/*** IAMStreamConfig methods ***/ +static HRESULT WINAPI AMStreamConfig_QueryInterface(IAMStreamConfig *iface, + REFIID riid, + LPVOID*ppvObj) { + ICOM_THIS_MULTI(VideoRendererImpl, IAMStreamConfig_vtbl, iface); + + TRACE("(%p/%p)->(%s (%p), %p)\n", This, iface, debugstr_guid(riid), riid, ppvObj); + + // return AMStreamConfig_QueryInterface((IUnknown*)This, riid, ppvObj); + return S_OK; +} + +static ULONG WINAPI AMStreamConfig_AddRef(IAMStreamConfig *iface) { + ICOM_THIS_MULTI(VideoRendererImpl, IAMStreamConfig_vtbl, iface); + + TRACE("(%p/%p)->()\n", This, iface); + + // return AMStreamConfig_AddRef((IUnknown*)This); + return S_OK; +} + +static ULONG WINAPI AMStreamConfig_Release(IAMStreamConfig *iface) { + ICOM_THIS_MULTI(VideoRendererImpl, IAMStreamConfig_vtbl, iface); + + TRACE("(%p/%p)->()\n", This, iface); + + // return AMStreamConfig_Release((IUnknown*)This); + return S_OK; +} + +static HRESULT WINAPI AMStreamConfig_SetFormat(IAMStreamConfig *iface, + AM_MEDIA_TYPE *pmt) { + ICOM_THIS_MULTI(VideoRendererImpl, IAMStreamConfig_vtbl, iface); + + TRACE("(%p/%p): stub !!\n", This, iface); + + return S_OK; +} + +static HRESULT WINAPI AMStreamConfig_GetFormat(IAMStreamConfig *iface, + AM_MEDIA_TYPE **pmt) { + ICOM_THIS_MULTI(VideoRendererImpl, IAMStreamConfig_vtbl, iface); + + TRACE("(%p/%p): stub !!\n", This, iface); + + return S_OK; +} + +typedef struct _VIDEO_STREAM_CONFIG_CAPS { + GUID guid; + ULONG VideoStandard; + SIZE InputSize; + SIZE MinCroppingSize; + SIZE MaxCroppingSize; + int CropGranularityX; + int CropGranularityY; + int CropAlignX; + int CropAlignY; + SIZE MinOutputSize; + SIZE MaxOutputSize; + int OutputGranularityX; + int OutputGranularityY; + int StretchTapsX; + int StretchTapsY; + int ShrinkTapsX; + int ShrinkTapsY; + LONGLONG MinFrameInterval; + LONGLONG MaxFrameInterval; + LONG MinBitsPerSecond; + LONG MaxBitsPerSecond; +} VIDEO_STREAM_CONFIG_CAPS; + +static HRESULT WINAPI AMStreamConfig_GetNumberOfCapabilities(IAMStreamConfig *iface, + int *piCount, + int *piSize) { + ICOM_THIS_MULTI(VideoRendererImpl, IAMStreamConfig_vtbl, iface); + + TRACE("((%p/%p): %p %p): semi-stub !!\n", This, iface, piCount, piSize); + + *piCount = 1; + *piSize = sizeof(VIDEO_STREAM_CONFIG_CAPS); + + return S_OK; +} + +static HRESULT WINAPI AMStreamConfig_GetStreamCaps(IAMStreamConfig *iface, + int iIndex, + AM_MEDIA_TYPE **pmt, + BYTE *pSCC) { + ICOM_THIS_MULTI(VideoRendererImpl, IAMStreamConfig_vtbl, iface); + VIDEOINFOHEADER *pvi; + VIDEO_STREAM_CONFIG_CAPS *vsc; + + TRACE("((%p/%p) %d %p %p): semi-stub !!\n", This, iface, iIndex, pmt, pSCC); + + // FIXME: Get actual stream information in here (IEnumMediaTypes ?) + + pmt[0] = CoTaskMemAlloc(sizeof (AM_MEDIA_TYPE)); + memcpy (&pmt[0]->formattype, &FORMAT_VideoInfo, sizeof (GUID)); + memcpy (&pmt[0]->majortype, &MEDIATYPE_Video, sizeof (GUID)); + memcpy (&pmt[0]->subtype, &MEDIASUBTYPE_RGB24, sizeof (GUID)); + pmt[0]->bTemporalCompression = 0; + pmt[0]->bFixedSizeSamples = 1; + pmt[0]->lSampleSize = 1; + + // FIXME: The stuff below is just there so it contains something + + pmt[0]->cbFormat = sizeof(VIDEOINFOHEADER); + pmt[0]->pbFormat = CoTaskMemAlloc(pmt[0]->cbFormat); + ZeroMemory(pmt[0]->pbFormat, pmt[0]->cbFormat); + pvi = (VIDEOINFOHEADER *)pmt[0]->pbFormat; + pvi->rcSource.right = 640; pvi->rcSource.bottom = 480; + pvi->rcTarget.right = 640; pvi->rcTarget.bottom = 480; + pvi->dwBitRate = 10; + pvi->dwBitErrorRate = 0; + pvi->AvgTimePerFrame = (LONGLONG)(10000000.0 / 25); // 25 is hardcoded + + // FIXME: The stuff below is just there so it contains something + + pvi->bmiHeader.biWidth = 640; + pvi->bmiHeader.biHeight = 480; + pvi->bmiHeader.biBitCount = 24; + pvi->bmiHeader.biCompression = BI_RGB; + pvi->bmiHeader.biSizeImage = 0; + pvi->bmiHeader.biXPelsPerMeter = 640; + pvi->bmiHeader.biYPelsPerMeter = 480; + pvi->bmiHeader.biClrUsed = 0; + pvi->bmiHeader.biClrImportant = 0; + + // FIXME: Blahblahblah + + vsc = (VIDEO_STREAM_CONFIG_CAPS *)pSCC; + memcpy (&vsc->guid, &FORMAT_VideoInfo, sizeof (GUID)); + vsc->VideoStandard = 0; + vsc->InputSize.cx = 640; vsc->InputSize.cy = 480; + vsc->MinCroppingSize.cx = 320; vsc->MinCroppingSize.cy = 240; + vsc->MaxCroppingSize.cx = 640; vsc->MaxCroppingSize.cy = 480; + vsc->CropGranularityX = 10; + vsc->CropGranularityY = 10; + vsc->CropAlignX = 0; + vsc->CropAlignY = 0; + vsc->MinOutputSize.cx = 320; vsc->MinOutputSize.cy = 240; + vsc->MaxOutputSize.cx = 640; vsc->MaxOutputSize.cy = 480; + vsc->OutputGranularityX = 10; + vsc->OutputGranularityY = 10; + vsc->StretchTapsX = 1; + vsc->StretchTapsY = 1; + vsc->ShrinkTapsX = 1; + vsc->ShrinkTapsY = 1; + vsc->MinFrameInterval = (LONGLONG)(10000000.0 / 25); + vsc->MaxFrameInterval = (LONGLONG)(10000000.0 / 25); + vsc->MinBitsPerSecond = 24; + vsc->MaxBitsPerSecond = 24; + + return S_OK; +} + +static IAMStreamConfigVtbl IAMStreamConfig_VTable = +{ + AMStreamConfig_QueryInterface, + AMStreamConfig_AddRef, + AMStreamConfig_Release, + AMStreamConfig_SetFormat, + AMStreamConfig_GetFormat, + AMStreamConfig_GetNumberOfCapabilities, + AMStreamConfig_GetStreamCaps +}; As for Quartz; there's been a lot of development over the last couple of weeks on this, especially on the FilterMapper, regsvr, AVI stuff, videorenderer, etc., so that aswell as future development might prove to be quite useful in getting this to work. Anyway, that's pretty much all there is; I wrote some other hacks to various DLLs, but eventually ended up using native DLLs instead as the hacking proved too extensive (sorry to say, my goal at that point was getting my webcam to work under MSN with Wine, not to add anything useful to Wine itself (though it would have been a nice side-effect)) Hopefully the patches were of some use to you, and perhaps someone can get V4L/VFW working under WINE. I, for one, would cer- tainly appreciate it :-) Best Regards, Jasper Robbert Xerox wrote: > Hi, i was wondering if you could post your > hacks/patches you talk about in the message (involving > this webcam/MSN messenger etc. stuff) either to the > wine developement mailinglist or to me. I would be > very gratefull as i really would like to have a look > at it, to see if i could get any further. Thanks in > advance, Robbert > > > > > > ___________________________________________________________ > ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com > ----- End forwarded message -----

1 0

Re: Re: [DMUSIC/DINPUT] includes fixes
by fenix＠club-internet.fr 14 Mar '05

14 Mar '05

4 4

Automatic installation rev-eng utility
by Shachar Shemesh 14 Mar '05

14 Mar '05

Hi all, I said this in a reply in one of the threads (the one about Windows registry), and got zero reply. I'm bringing the subject up again here. Back in 1996 (and until around 2000) I was project manager for a project called "GTFormat". This was a project used by the late Packard Bell, as well as NEC in Japan, to put the programs bundled with the machines on the hard disks shipped out to customers. The tools consist of a tool that understands what the original installation did, a database to do offline conflict resolution and other stuff, and a front end to perform a (silent) installation of the result. I have written most of the code in the last part of this project, and as I said before, managed the entire thing. We also had a tool the generated files for the last part directly from the first part, without going through the database. Now, the tool was written when I was an employee of the company that produced them (G.Tek Technologies, today called gteko), but I believe that given enough persuasion I can get their approval to either freely distribute or actually open source the detection and the installation tool. I believe most of the distinguishing value of the tool as far as Gteko is concerned is in the database, which is not relevant for Wine in any way. The tool is written mostly in C++ for Visual Studio 6. It may require pulling out a single proprietary library (compression), but should not pose a problem (zlib does a wonderful job, after all). The question, therefor, is this. Should I try? The tool has proven itself over a long period of time, and is fairly reliable (at least was back at the time). It CAN solve some of our installer related problems. Your opinions are welcome. So, what say you? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html

2 2

Re: make mlang_test.exe loadable on NT 4.0 [resend, 3nd time]
by Alexandre Julliard 14 Mar '05

14 Mar '05

Stefan Leichter <Stefan.Leichter(a)camLine.com> writes: > Hi Alexandre, > > you have now ignore this patch three times :-( is anything wrong with it? or > does "wine-patches" have a hole ? There must be a hole somewhere yes, it's the first time I ever see that patch. Maybe my spam filter doesn't like you <g> -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [X11DRV] Fix X11 Device list leak
by Raphael 14 Mar '05

14 Mar '05

Hi, > Thanks for submitting this patch. > These are exactly the fixes I was about to submit! Nothing :) > Your patch should should have a major impact on users of applications > which use the wintab library: They should all start to function to some > degree. i hope so, waiting for users report now :) > Apologies for not commenting on patch/ submitting a fix earlier.... > A major knee operation has put me out of action for the last few weeks. :( Have a good recovery > P.S. Please don't expect timely responses to mails for at least > another week. > I'll try my best to respond, but can't promise anything. > Regards, Raphael

1 0

Re: richedit patches by Phil Krylov
by Phil Krylov 14 Mar '05

14 Mar '05

On Mon, 14 Mar 2005 19:31:25 +0100 Krzysztof Foltman <kfoltman(a)portal.onet.pl> wrote: > > ChangeLog: > > Initial implementation of EM_STREAMOUT and RTF writer. > > Nice to see this functionality implemented (I really didn't want to > implement it myself). Very good code too. Thanks. Thanks :) > The new function ME_FindItemAtOffset isn't really necessary, you can > achieve exactly the same thing with ME_RunOfsFromCharOfs (and I should > have used it in ME_GetTextW instead of reimplementing the same > functionality). I'm going to get rid of it later. Oh sorry, I haven't noticed that it already exists. > Now when both EM_STREAMIN and EM_STREAMOUT work, I can start > implementing the rest of the clipboard code. The RTF reader still has to be teached Unicode. Currently most of my existing .rtf documents are totally garbled. -- Ph.

1 0

Re: [patch] x86: fix ESP corruption CPU bug
by Stas Sergeev 14 Mar '05

14 Mar '05

Hi, Linus Torvalds wrote: > Btw, Stas, one thing I'd really like to see is even a partial list of > anything that actually cares about this. Ie, if there is some known > Windows app where Wine works better or something like that, just adding I am not using Wine too much, but I've found this: http://cvs.winehq.org/cvsweb/~checkout~/wine/dlls/winedos/int31.c?rev=1.41&… --- /* due to a flaw in some CPUs (at least mine), it is best to mark stack segments as 32-bit if they can be used in 32-bit code. Otherwise, these CPUs may not set the high word of esp during a ring transition (from kernel code) to the 16-bit stack, and this causes trouble if executing 32-bit code using this stack. */ --- I added win-devel to CC, maybe people there can tell if that patch has any value for them or not. The reference to the original patch: http://www.uwsg.iu.edu/hypermail/linux/kernel/0503.1/1794.html Dosemu looks a little better on that, the whole chapter of the docs is dedicated to that problem: http://dosemu.sourceforge.net/docs/EMUfailure/t1.html#AEN55 There you can find a (relatively small) list of the programs that are affected, but I personally have the old Microsoft linker that crashes, and a few more DOS games. > Another way of saying the same thing: I absolutely hate seeing patches > that fix some theoretical issue that no Linux apps will ever care about. No, it is not theoretical, but it is mainly about a DOS games and an MS linker, as for me. The things I'd like to get working, but the ones you may not care too much about:) The particular game I want to get working, is "Master of Orion 2" for DOS. > So I'd like to have a bit more of a case for this patch, since I know what > the case against it is ;) Yep, and the informational leak it closes, looks also rather minor. So it is only a matter of how do you care about the dosemu and the DOS games under linux. Considering the amount of the dosemu-related code in vm86.c, I guess you care:) And uhm, adding the list of the DOS games to the comments of the Linux kernel code, doesn't sound like a good idea to me:)

6 7

Re: shlapi: Fixes for UrlIsW and UrlIsA
by Mike McCormack 14 Mar '05

14 Mar '05

Troy Rollo wrote: > Testing under Windows shows that UrlIsW and UrlIsA should: Would you be able to write a conformance test using what you've found, to make sure it doesn't break again? Even just posting the test program to wine-patches so somebody could create a conformance test out of it would be great... Mike

2 1

richedit patches by Phil Krylov
by Krzysztof Foltman 14 Mar '05

14 Mar '05

> ChangeLog: > Initial implementation of EM_STREAMOUT and RTF writer. Nice to see this functionality implemented (I really didn't want to implement it myself). Very good code too. Thanks. IMHO the patch can be applied without changes. The new function ME_FindItemAtOffset isn't really necessary, you can achieve exactly the same thing with ME_RunOfsFromCharOfs (and I should have used it in ME_GetTextW instead of reimplementing the same functionality). I'm going to get rid of it later. Now when both EM_STREAMIN and EM_STREAMOUT work, I can start implementing the rest of the clipboard code. > Added "generator" RTF destination handling. > Added missing PFA_JUSTIFY definition to richedit.h. Thanks for the fixes, I really didn't know how to get rid of the \generator. Maybe it will help me figure out how to ignore the rest of the RTF junk that I can't use anyway (\pgdsctbl and others). Krzysztof

3 3

Let's fix Steam!
by Scott Ritchie 14 Mar '05

14 Mar '05

Steam has had a serious problem for quite some time, failing with a strange debug assertion error popup at the dreaded 27% mark. What's interesting, however, is that Steam works perfectly in Crossover 4.1 - since I don't think Steam is supported, this is not due to a special hack, and the failure in Steam therefore represents a serious regression in Wine. This, quite simply, will be a really cool app to get working again. Plus, we'll need it to try out Half Life 2 once you awesome Direct3D boys finish up your work :) So, where do we go about this? The installer demonstrating the error can be downloaded easily from http://www.steampowered.com/ - however, I'm not sure if it's plausible to run a regression analysis since there are no patches available against the direct crossover version of Wine. At this point, I'm not even sure which file has broken, although I do know that it's one we've had problems with in the past based off of IRC conversations. If anyone could follow up with more info, particularly about the specifics of the error, I'm sure we'd all appreciate it greatly. Thanks, Scott Ritchie

3 11

Re: Ptrace problem on amd64? (Was: Re: Warcraft III can't find cdrom)
by Mike Hearn 14 Mar '05

14 Mar '05

T.J. Zeeman wrote: >>>Warcraft still complains about the CD-rom being MIA though :( I'll see >>>if I can dig up a few hints from the log this weekend. >> >>Make sure your kernel hsa the ptrace regression fixes in. > > > I guess you meant the problems refered to in WWN250 > (http://www.winehq.com/?issue=250). I checked and the patch there is > only for i386. I ported those to the x86_64 files (see attachments) and > tried again to no avail. > > I also tried the test app as posted by Linus Torvalds here: > http://www.winehq.com/hypermail/wine-devel/2004/11/0551.html > When trying that on amd64 with the ptrace patches it does not even want > to compile (not completely surprising). In the chroot it segfaults. > A strace showed the following: > > x5556c000 > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or > directory) > open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or > directory) > open("/etc/ld.so.cache", O_RDONLY) = 3 > fstat64(3, {st_mode=S_IFREG|0644, st_size=32850, ...}) = 0 > old_mmap(NULL, 32850, PROT_READ, MAP_PRIVATE, 3, 0) = 0x5556d000 > close(3) = 0 > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or > directory) > open("/lib/tls/libc.so.6", O_RDONLY) = 3 > read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360Y\1"..., > 512) = 512 > fstat64(3, {st_mode=S_IFREG|0644, st_size=1253924, ...}) = 0 > old_mmap(NULL, 1260140, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = > 0x55576000 > old_mmap(0x5569f000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, > 3, 0x129000) = 0x5569f000 > old_mmap(0x556a7000, 10860, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED| > MAP_ANONYMOUS, -1, 0) = 0x556a7000 > close(3) = 0 > old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, > -1, 0) = 0x556aa000 > set_thread_area({entry_number:-1 -> 11, base_addr:0x556aa2a0, > limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, > limit_in_pages:1, seg_not_present:0, useable:1}) = 0 > munmap(0x5556d000, 32850) = 0 > rt_sigaction(SIGTRAP, {0x8048438, [TRAP], SA_RESTART}, {SIG_DFL}, 8) = 0 > mprotect(0x8048000, 4096, PROT_READ|PROT_WRITE) = 0 > --- SIGSEGV (Segmentation fault) @ 0 (0) --- > +++ killed by SIGSEGV +++ > > > I haven't been this deep into low level code in a long time (and that > was 8086 asm simulated on a sparc), but I thought this would work and > not segfault. Anybody around here that can comment on that? Or should I > take this to another forum to further investigate? If so, where would > you suggest I take it? I'm not sure, probably lkml would be best but I'm not subscribed to that. I'll CC wine-devel and maybe somebody there can help. I'd recommend pinging Linus and asking about whether the ptrace regressions still affect x86-64. thanks -mike > regards, > Thomas > > > > > ------------------------------------------------------------------------ > > --- /usr/src/kernel-source-2.6.10/arch/x86_64/kernel/ptrace.c 2004-12-24 22:34:30.000000000 +0100 > +++ ptrace.c 2005-03-01 20:32:29.713639136 +0100 > @@ -79,6 +79,28 @@ > return 0; > } > > +static void set_singlestep(struct task_struct *child) > +{ > + long eflags; > + > + set_tsk_thread_flag(child, TIF_SINGLESTEP); > + eflags = get_stack_long(child, EFL_OFFSET); > + put_stack_long(child, EFL_OFFSET, eflags | TRAP_FLAG); > + child->ptrace |= PT_DTRACE; > +} > + > +static void clear_singlestep(struct task_struct *child) > +{ > + if (child->ptrace & PT_DTRACE) { > + long eflags; > + > + clear_tsk_thread_flag(child, TIF_SINGLESTEP); > + eflags = get_stack_long(child, EFL_OFFSET); > + put_stack_long(child, EFL_OFFSET, eflags & ~TRAP_FLAG); > + child->ptrace &= ~PT_DTRACE; > + } > +} > + > /* > * Called by kernel/ptrace.c when detaching.. > * > @@ -86,11 +108,12 @@ > */ > void ptrace_disable(struct task_struct *child) > { > - long tmp; > +/* long tmp; > > clear_tsk_thread_flag(child, TIF_SINGLESTEP); > tmp = get_stack_long(child, EFL_OFFSET) & ~TRAP_FLAG; > - put_stack_long(child, EFL_OFFSET, tmp); > + put_stack_long(child, EFL_OFFSET, tmp); */ > + clear_singlestep(child); > } > > static int putreg(struct task_struct *child, > @@ -338,8 +361,6 @@ > break; > case PTRACE_SYSCALL: /* continue and stop at next (return from) syscall */ > case PTRACE_CONT: { /* restart after signal. */ > - long tmp; > - > ret = -EIO; > if ((unsigned long) data > _NSIG) > break; > @@ -347,12 +368,9 @@ > set_tsk_thread_flag(child,TIF_SYSCALL_TRACE); > else > clear_tsk_thread_flag(child,TIF_SYSCALL_TRACE); > - clear_tsk_thread_flag(child, TIF_SINGLESTEP); > child->exit_code = data; > /* make sure the single step bit is not set. */ > - tmp = get_stack_long(child, EFL_OFFSET); > - tmp &= ~TRAP_FLAG; > - put_stack_long(child, EFL_OFFSET,tmp); > + clear_singlestep(child); > wake_up_process(child); > ret = 0; > break; > @@ -394,34 +412,23 @@ > * exit. > */ > case PTRACE_KILL: { > - long tmp; > - > ret = 0; > if (child->exit_state == EXIT_ZOMBIE) /* already dead */ > break; > clear_tsk_thread_flag(child, TIF_SINGLESTEP); > child->exit_code = SIGKILL; > /* make sure the single step bit is not set. */ > - tmp = get_stack_long(child, EFL_OFFSET) & ~TRAP_FLAG; > - put_stack_long(child, EFL_OFFSET, tmp); > + clear_singlestep(child); > wake_up_process(child); > break; > } > > case PTRACE_SINGLESTEP: { /* set the trap flag. */ > - long tmp; > - > ret = -EIO; > if ((unsigned long) data > _NSIG) > break; > clear_tsk_thread_flag(child,TIF_SYSCALL_TRACE); > - if ((child->ptrace & PT_DTRACE) == 0) { > - /* Spurious delayed TF traps may occur */ > - child->ptrace |= PT_DTRACE; > - } > - tmp = get_stack_long(child, EFL_OFFSET) | TRAP_FLAG; > - put_stack_long(child, EFL_OFFSET, tmp); > - set_tsk_thread_flag(child, TIF_SINGLESTEP); > + set_singlestep(child); > child->exit_code = data; > /* give it a chance to run. */ > wake_up_process(child); > > > ------------------------------------------------------------------------ > > --- /usr/src/kernel-source-2.6.10/arch/x86_64/kernel/signal.c 2004-12-24 22:35:23.000000000 +0100 > +++ signal.c 2005-03-01 20:33:11.425298000 +0100 > @@ -205,8 +205,14 @@ > err |= __put_user(me->thread.trap_no, &sc->trapno); > err |= __put_user(me->thread.error_code, &sc->err); > err |= __put_user(regs->rip, &sc->rip); > + > + /* > + * Iff TF was set because the program is being single-stepped by a > + * debugger, don't save that information on the signal stack.. We > + * don't want debugging to change state. > + */ > eflags = regs->eflags; > - if (current->ptrace & PT_PTRACED) { > + if (current->ptrace & PT_DTRACE) { > eflags &= ~TF_MASK; > } > err |= __put_user(eflags, &sc->eflags); > @@ -324,12 +330,16 @@ > regs->rsp = (unsigned long)frame; > > set_fs(USER_DS); > + /* > + * Clear TF when entering the signal handler, but > + * notify any tracer that was single-stepping it. > + * The tracer may want to single-step inside the > + * handler too. > + */ > if (regs->eflags & TF_MASK) { > - if ((current->ptrace & (PT_PTRACED | PT_DTRACE)) == (PT_PTRACED | PT_DTRACE)) { > + regs->eflags &= ~TF_MASK; > + if (current->ptrace & PT_DTRACE) > ptrace_notify(SIGTRAP); > - } else { > - regs->eflags &= ~TF_MASK; > - } > } > > #ifdef DEBUG_SIG

6 14

Re: STI, device drivers and stuff
by Steven Edwards 14 Mar '05

14 Mar '05

Hi, --- "Dimitrie O. Paun" <dpaun(a)rogers.com> wrote: > > 2. STI has kernel mode components to deal USB / SCSI / > > serial / parallel ports. Is there any attempt to bring > > kernel mode support into Wine (ReactOS/Wine merger?) > > any time soon? If not, should I implement USB support > > using libusb in user-space? > > Wine is purely user-space, so yes, use libusb I guess. CrossOver is using libusb for the iPod stuff. There is little chance of sharing much of the hardware support with ReactOS however the higher level stuff is being shared such as setupapi. Having a wineserver thread or something that acts like the umpnpmgr on Windows would allow us to share a bit more code as well. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

1 0

DOS interrupts in Wine
by Sam Lauber 14 Mar '05

14 Mar '05

Does Wine correctly implement all the DOS Services and interrupts? Samuel Lauber -- _____________________________________________________________ Web-based SMS services available at http://www.operamail.com. >From your mailbox to local or overseas cell phones. Powered by Outblaze

3 2

Re: MSI: add property IDs for MSI summary information
by Juan Lang 14 Mar '05

14 Mar '05

--- Mike McCormack <mike(a)codeweavers.com> wrote: > Yes, it's really in MsiDefs.h from the Windows Platform SDK. Weird. > As far as I can tell, MSI also reimplements the property set storage > code, as it makes no calls to the ole storage implementation of > IPropertySetStorage. Perhaps there is some subtle difference between > the two implementations? Or maybe they did that because > IPropertySetStorage isn't available on earlier OLE implemenations? More likely the former, though I wouldn't hazard a guess as to why. MS allows you to reimplement these, they just provide a default impl. It's been around for quite a while, though, the best description I've found is from 1993-1995, well before MSI: http://msdn.microsoft.com/library/default.asp?url=/archive/en-us/dnarolegen… --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: MSI: add property IDs for MSI summary information
by Juan Lang 14 Mar '05

14 Mar '05

Hi Mike, > +#define PID_DICTIONARY 0 > +#define PID_CODEPAGE 1 > +#define PID_TITLE 2 Is it really like this in the PSDK? Some of these are already defined in propidl.idl. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Zuma
by Juan Pablo Sousa 14 Mar '05

14 Mar '05

Hi, I'm trying to make the game Zuma work you can get the demo from: http://www.popcap.com/launchpage.php?theGame=zuma i've tried setting version to both win98 and winxp, in both cases I get very similar results I don't know where to start, the last line gives me the idea it's even chrashing the debugger, any ideas? here are the last lines running with +relay: 0009:Ret ntdll.RtlAcquirePebLock() retval=00000000 ret=77b18896 0009:Call ntdll.RtlUnicodeStringToAnsiString(7792fa0c,77eff920,00000001) ret=77b188bd 0009:Ret ntdll.RtlUnicodeStringToAnsiString() retval=00000000 ret=77b188bd 0009:Call ntdll.RtlReleasePebLock() ret=77b188d4 0009:Ret ntdll.RtlReleasePebLock() retval=00000000 ret=77b188d4 0009:Call ntdll.RtlEnterCriticalSection(77bde3c0) ret=77b27ed0 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=77b27ed0 0009:Call ntdll.RtlLeaveCriticalSection(77bde3c0) ret=77b27f00 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=77b27f00 0009:Call ntdll.RtlEnterCriticalSection(77bde3c0) ret=77b27ed0 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=77b27ed0 0009:Call ntdll.RtlLeaveCriticalSection(77bde3c0) ret=77b27f00 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=77b27f00 0009:Call ntdll.NtCreateEvent(77bf0974,001f0003,00000000,00000001,00000000) ret=77b5ffb7 0009:Ret ntdll.NtCreateEvent() retval=00000000 ret=77b5ffb7 0009:Ret PE DLL (proc=0x77afdef0,module=0x77af0000 L"kernel32.dll",reason=PROCESS_ATTACH,res=0x1) retval=1 0009:Ret ntdll.LdrInitializeThunk() retval=00000000 ret=77b44b6b 0009:Call ntdll.RtlImageNtHeader(00400000) ret=77b44b79 0009:Ret ntdll.RtlImageNtHeader() retval=004000f8 ret=77b44b79 0009:Starting process L"C:\\Program Files\\PopCap Games\\Zuma Deluxe\\Zuma.exe" (entryproc=0x856000) wine_dbg_vprintf: debugstr buffer overflow (contents: '0009:Call kernel32.VxDCall0(0086e000,0000000a,00857cf4 "\x8b\\$\x0c\xeb\x03\xeb\xfc\xeb\xeb\x01\xeb\xff\x8b\xb0",7792ff38 L"\ffff\ffff\de98\77af\96b0\77b1\7928\77bc",00856030,77b44ba2,77eff6c0 "",00000009,77eff04c,00856000,ffffffff (invalid),77afde98 L"\25ff\f4e4\77bc\f689\25ff\f4e8\77bc\f689\25ff\f4ec\77bc\f689\25ff\f4f0\77bc\f689\25ff\f4f4\77bc\f689\25ff\f4f8\77bc\f689\25ff\f4fc\77bc\f689\25ff\f500\77bc\f689\25ff\f504\77bc\f689\25ff\f508\77bc\f689\25ff\f50c\77bc\f689\8955\53e5\ec83\e814\81d8\fffe\c381\9a2c\000c\7d83\010c\3175\bb83\6e5c\0001\7501\8b28"...,77b196b0,77bc7928,00000000,00000000,7792fff4,7792ff28,77b44b1a,00000001,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,77bc7928,00000000,00000000,00000000,b7fb6dd1,00000000,Exception frame is not in st') err:seh:EXC_DefaultHandling Exception frame is not in stack limits => unable to dispatch exception.

1 0

[advpack] Implement RegisterOCX and stub out DelNodeRunDLL32
by Matthew Mastracci 14 Mar '05

14 Mar '05

This patch helps the IE6 installer get past the DLL registration stage. The DelNodeRunDLL32 function is stubbed out, but RegisterOCX will correctly register a COM DLL by calling its DllRegisterServer function. ChangeLog: * dlls/advpack/advpack.c Matthew Mastracci <mmastrac(a)canada.com> Implement RegisterOCX Stub for DelNodeRunDLL32 Index: dlls/advpack/advpack.c =================================================================== RCS file: /home/wine/wine/dlls/advpack/advpack.c,v retrieving revision 1.7 diff -u -r1.7 advpack.c --- dlls/advpack/advpack.c 20 Jan 2005 20:03:13 -0000 1.7 +++ dlls/advpack/advpack.c 14 Mar 2005 07:35:54 -0000 @@ -32,6 +32,8 @@ WINE_DEFAULT_DEBUG_CHANNEL(advpack); +typedef HRESULT (*DLLREGISTER) (void); + /*********************************************************************** * DllMain (ADVPACK.@) @@ -172,3 +174,60 @@ return S_OK; } + +/*********************************************************************** + * RegisterOCX (ADVPACK.@) + */ +void WINAPI RegisterOCX( HWND hWnd, HINSTANCE hInst, LPCSTR cmdline, INT show ) +{ + WCHAR wszBuff[MAX_PATH]; + WCHAR* pwcComma = &wszBuff[0]; + HMODULE hm; + DLLREGISTER pfnRegister; + HRESULT hr; + + TRACE("(%s)\n", cmdline); + + MultiByteToWideChar(CP_ACP, 0, cmdline, strlen(cmdline), wszBuff, MAX_PATH); + while (!(*pwcComma == ',' ) && *pwcComma) + { + pwcComma++; + } + *pwcComma = '\0'; + + TRACE("Parsed DLL name (%s)\n", debugstr_w(wszBuff)); + + hm = LoadLibraryExW(wszBuff, 0, LOAD_WITH_ALTERED_SEARCH_PATH); + if (!hm) + { + ERR("Couldn't load DLL: %s\n", debugstr_w(wszBuff)); + return; + } + + pfnRegister = (DLLREGISTER)GetProcAddress(hm, "DllRegisterServer"); + if (pfnRegister == NULL) + { + ERR("DllRegisterServer entry point not found\n"); + } + else + { + hr = pfnRegister(); + if (hr != S_OK) + { + ERR("DllRegisterServer entry point returned %08lx\n", hr); + } + } + + TRACE("Successfully registered OCX\n"); + + FreeLibrary(hm); +} + +/*********************************************************************** + * DelNodeRunDLL32 (ADVPACK.@) + */ +void WINAPI DelNodeRunDLL32( HWND hWnd, HINSTANCE hInst, LPCSTR cmdline, INT show ) +{ + FIXME("(%s) FIXME: stub\n", cmdline); +} + Index: dlls/advpack/advpack.spec =================================================================== RCS file: /home/wine/wine/dlls/advpack/advpack.spec,v retrieving revision 1.5 diff -u -r1.5 advpack.spec --- dlls/advpack/advpack.spec 20 Jan 2005 20:03:13 -0000 1.5 +++ dlls/advpack/advpack.spec 14 Mar 2005 07:35:54 -0000 @@ -2,7 +2,7 @@ @ stub AdvInstallFile @ stub CloseINFEngine @ stub DelNode -@ stub DelNodeRunDLL32 +@ stdcall DelNodeRunDLL32(ptr ptr str long) @ stdcall DllMain(long long ptr) @ stdcall DoInfInstall(ptr) @ stub ExecuteCab @@ -23,10 +23,11 @@ @ stub RegRestoreAll @ stub RegSaveRestore @ stub RegSaveRestoreOnINF -@ stub RegisterOCX +@ stdcall RegisterOCX(ptr ptr str long) @ stub RunSetupCommand @ stub SetPerUserSecValues @ stub TranslateInfString @ stub TranslateInfStringEx @ stub UserInstStubWrapper @ stub UserUnInstStubWrapper

2 3

Window style problem with Steam
by Stefan Dösinger 14 Mar '05

14 Mar '05

Hello! I had a look at the "no keyboard problem" with Steam. A little reseach showed that Steam creates its main Window with WS_SYSMENU set but WS_CAPTION not set. MSDN says that WS_CAPTION must be set if WS_SYSMENU is used: WS_SYSMENU Creates a window that has a window menu on its title bar. The WS_CAPTION style must also be specified. (from http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winu…) If I check for this case in WIN_CreateWindowEx and set WS_CAPTION, the Window is controlled by KWM and I can type in the Steam window. But KWM draws the normal Window boarder and it overlaps the rest of the Window and confuses the mouse. Furthermore the menu of the systray applet has a Caption. The solution I've found is to set the WS_EX_APPWINDOW flag in cs->dwExStyle. In this case Steam behaves as I'd expect it. But is this a correct solution? Any suggestions? Stefan

1 0

Scrollkeeper, the documentation, XML, and the way forward
by Scott Ritchie 14 Mar '05

14 Mar '05

I wanted the Wine documentation to appear on the nice help menus, like other standard apps. I learned that the way to do this is to write an OMF file for each document, which scrollkeeper can then look at to find the metadata about where the document is and how to index it and such. The trouble is, Scrollkeeper and the Gnome help menus no longer support SGML, as XML is the current new and hip thing. The Wine documentation is in SGML. There are quite a few reasons to move forward. The Wine documentation is also a bit separate (requiring its own compiling, for example) from the main code, and this should change. This link: http://scrollkeeper.sourceforge.net/documentation/scrollkeeper_example2_man… has some good information about how Wine should look to play well with Scrollkeeper and modern distros. I propose we attack this in phases, and create the following plan of attack: 1) Create a new directory for all XML documentation at wine/doc. This will also bring us to be more standard. 2) When we convert old SGML documents to XML and move them there, we write an OMF file for them then and there (I'll do it if you like). We also make sure the build process is aware of this stuff and is installing the xml and omf files in the right place so scrollkeeper can find them when it runs after build time. 3) We follow the steps at the above link to add scrollkeeper into the configure scripts after we convert the first document to XML. I vote for the Wine User Guide, since I'm working on it. 4) We inform the packagers once scrollkeeper is working in a release, as there are sometimes little tricks for it (one for rpms is on the page) So, beyond that, the first step seems pretty simple: convert the sgml stuff into xml format and put it into the new doc folder. Can someone point me to some good tools to do this? Thanks, Scott Ritchie

6 8

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