- Wine-Devel - list.winehq.org

Re: MSN Webcam patch
by Jasper van Veghel March 15, 2005

March 15, 2005

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 March 14, 2005

March 14, 2005

4 4

Automatic installation rev-eng utility
by Shachar Shemesh March 14, 2005

March 14, 2005

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 March 14, 2005

March 14, 2005

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 March 14, 2005

March 14, 2005

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 March 14, 2005

March 14, 2005

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 March 14, 2005

March 14, 2005

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 March 14, 2005

March 14, 2005

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 March 14, 2005

March 14, 2005

> 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 March 14, 2005

March 14, 2005

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