April 2005 - Wine-devel - list.winehq.org

Copy Protection
by Dustin Navea 24 Apr '05

24 Apr '05

Guys, bug 2895 got me thinkin.. If we only support a handful of games that use copy protection, shouldnt we file a bug in Bugzilla and append that to 1434 (Get games working perfectly)? That way we can attach any copy protection related bugs to this metabug? If you are agreeable to to that, I will go ahead and file it. Dustin

2 1

Re: Some fixes for filtergraph.c
by Christian Costa 24 Apr '05

24 Apr '05

Hi Maarten, Maarten Lankhorst wrote: > This doesn't fix everything, just theroutines i called.. some other > similar functions aren't fixed because filtergraph.c is really THAT > leaky..b mostly with reference counts.. Yes, Indeed. :-) Here are some comments : > >------------------------------------------------------------------------ > >--- wine-20050310/dlls/quartz/filtergraph.c 2005-03-02 11:12:12.000000000 +0100 >+++ wine/dlls/quartz/filtergraph.c 2005-04-24 00:50:30.000000000 +0200 >@@ -556,8 +556,7 @@ > IPin_QueryDirection(ppin, &pindir); > if (pindir == PINDIR_OUTPUT) > i++; >- else >- IPin_Release(ppin); >+ IPin_Release(ppin); > } > *pppins = CoTaskMemAlloc(sizeof(IPin*)*i); > /* Retrieve output pins */ >@@ -650,6 +649,7 @@ > IPin** ppins; > IPin* ppinfilter; > IBaseFilter* pfilter = NULL; >+ BOOL HaveEnumPin = FALSE; > > Why don't you just set ppinfilter to NULL and do "if (ppinfilter) IPin_Release(ppinfilter);" at the end ? > hr = GetFilterInfo(pMoniker, &clsid, &var); > IMoniker_Release(pMoniker); >@@ -677,6 +677,7 @@ > ERR("Enumpins (%lx)\n", hr); > goto error; > } >+ > hr = IEnumPins_Next(penumpins, 1, &ppinfilter, &pin); > if (FAILED(hr)) { > ERR("Next (%lx)\n", hr); >@@ -687,6 +688,7 @@ > goto error; > } > IEnumPins_Release(penumpins); >+ HaveEnumPin = TRUE; > > See above. > hr = IPin_Connect(ppinOut, ppinfilter, NULL); > if (FAILED(hr)) { >@@ -703,17 +705,21 @@ > TRACE("pins to consider: %ld\n", nb); > for(i = 0; i < nb; i++) { > TRACE("Processing pin %d\n", i); >- hr = IGraphBuilder_Connect(iface, ppins[0], ppinIn); >+ hr = IGraphBuilder_Connect(iface, ppins[i], ppinIn); > if (FAILED(hr)) { >- TRACE("Cannot render pin %p (%lx)\n", ppinfilter, hr); >- return hr; >+ TRACE("Cannot render pin %p (%lx)\n", ppinfilter, hr); > } >+ IPin_Release(ppins[i]); >+ if (SUCCEEDED(hr)) break; > This is not correct, you must connect all pins, not just the first that succeeds. > } > CoTaskMemFree(ppins); >+ IBaseFilter_Release(pfilter); >+ IPin_Release(ppinfilter); >+ break; > } >- break; > > error: >+ if (HaveEnumPin) IPin_Release(ppinfilter); > See above. > if (pfilter) { > IGraphBuilder_RemoveFilter(iface, pfilter); > IBaseFilter_Release(pfilter); >@@ -1175,13 +1181,16 @@ > ULONG nb; > ULONG i; > PIN_INFO PinInfo; >+ BOOL HavePinInfo = FALSE; > > TRACE("%p %p %lld\n", pGraph, pOutputPin, tStart); > > hr = IPin_ConnectedTo(pOutputPin, &pInputPin); > >- if (SUCCEEDED(hr)) >+ if (SUCCEEDED(hr)) { >+ HavePinInfo = TRUE; > hr = IPin_QueryPinInfo(pInputPin, &PinInfo); >+ } > > Personally, I would set PinIno.pFilter to NULL on failure and do if (PinIno.pFilter) release... at the end. But it's just a matter of taste. > if (SUCCEEDED(hr)) > hr = GetInternalConnections(PinInfo.pFilter, pInputPin, &ppPins, &nb); >@@ -1202,6 +1211,7 @@ > * FIXME: We should prevent exploring from a pin more than once. This can happens when > * several input pins are connected to the same output (a MUX for instance). */ > ExploreGraph(pGraph, ppPins[i], tStart); >+ IPin_Release(ppPins[i]); > } > > CoTaskMemFree(ppPins); >@@ -1210,6 +1220,7 @@ > IBaseFilter_Run(PinInfo.pFilter, tStart); > } > >+ if (HavePinInfo) IBaseFilter_Release(PinInfo.pFilter); > return hr; > } > >@@ -1255,9 +1266,11 @@ > IPin_QueryDirection(pPin, &dir); > if (dir == PINDIR_INPUT) > { >+ IPin_Release(pPin); > source = FALSE; > break; > } >+ IPin_Release(pPin); > That would be simplier to do a single call to IPinRelease after IPin_QueryDirection. > } > if (source == TRUE) > { >@@ -1267,6 +1280,7 @@ > { > /* Explore the graph downstream from this pin */ > ExploreGraph(This, pPin, 0); >+ IPin_Release(pPin); > } > IBaseFilter_Run(pfilter, 0); > } > > Nice patch, BTW! :-) Bye, Christian

1 0

Re: WoW, er Wine on Windows--Re: Still more fun?
by Steven Edwards 24 Apr '05

24 Apr '05

--- Augustus Saunders <augustus.saunders(a)verilogix.net> wrote: > I appreciate any feedback anybody has. Thanks- It wont work for DirectX. Wine directX structures and implementation is incompatible with Windows currently. Normal Win32 dlls work fine. Thanks Steven __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [AppDB] Version 1.00 of Warcraft III added by Christopher Morgan
by Jesse Allen 24 Apr '05

24 Apr '05

On 4/23/05, AppDB <appdb(a)winehq.org> wrote: > > Version 1.00 of Warcraft III added by Christopher Morgan > ------------------------------------------------------- > http://appdb.winehq.org/appview.php?versionId=3051 > This version has been submitted by Ben Klein. > > Best regards. > The AppDB team > http://www.winehq.org/ > > If you don't want to receive any other e-mail, please change your preferences: > http://appdb.winehq.org/preferences.php > > Hmmm. Should we be avoiding duplicate information? I already maintain a howto listed under "1.00+". In it I already cover, one running the game, including NoCD patches (though I encourage running official exe's and show how it's done) and second the issues with game movies. What this new note does not cover is running under opengl, working multiplayer and battle.net modes, winver settings to use, differentiation of wine versions, and miscellenous bugs. This new note may be a little misleading because Warcraft 3 uses D3D8 so Oliver's patch is not required, but it may be an improvement, I don't know. I typically run the game in opengl. There are other instances of duplicate information in the Appdb, perhaps we need to clean this up. But it is enormous work. I have a hard time just keeping my howto up to date. Jesse

2 1

Re: Installing Mozilla
by Juan Lang 23 Apr '05

23 Apr '05

--- James Hawkins <truiken(a)gmail.com> wrote: > Just because Mozilla is passing a bad memory address doesn't mean > it's a bug in Mozilla. For example Mozilla could have requested > some information from wine and we gave them the bad memory address. While that's certainly possible in general, that doesn't appear to be the case here. The bad pointer is the destination address of WideCharToMultiByte, not the source. Typically this will some buffer or other internal to Mozilla. I'm not claiming there isn't a bug in Wine. But I think the immediate thing we're seeing is a bug in Mozilla (likely triggered by a bug in Wine.) The nls trace might be interesting, because the source pointer appears to be valid. So, what string are they trying to translate? An error message perhaps? That might point to the cause of the problem. --Juan __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

4 6

Re: Installing Mozilla
by Juan Lang 23 Apr '05

23 Apr '05

--- Dustin Navea <speeddymon(a)gmail.com> wrote: > Perhaps they are thinking along the lines of the whole string being for > example "GMT -06:00 Central Time" ? In which case they wouldnt want to > convert just the GMT as it would product the wrong result. Apples and oranges. By "converting," I mean "WideCharToMultiByte," that is, character conversion from Unicode to ANSI. Converting more of the string doesn't help. The correct value in this case would be "CDT", and they wouldn't produce that. See their code. I agree with you a bug (and patch) ought to be filed against Mozilla. I may someday, but in the meanwhile, feel free. --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: Installing Mozilla
by Juan Lang 23 Apr '05

23 Apr '05

--- Alexandre Julliard <julliard(a)winehq.org> wrote: > Actually, judging from the pointer values I get on my XP box the > buffers seem to be 64 chars long. Okay, changing patch to match. > Still, I'm not sure why Mozilla feels the need to overwrite them, that > doesn't seem right. No, it doesn't, although their comments explain the motivation: on some versions of Windows NT, the value is incorrectly set for some time zones. Nonetheless the code is doing the wrong thing: it's converting an entire string, e.g. "GMT Standard Time", rather than the time zone portion alone ("GMT"). --Juan __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/

2 1

Re: ole32: fix for big-endian machines
by Alexandre Julliard 23 Apr '05

23 Apr '05

Juan Lang <juan_lang(a)yahoo.com> writes: > > void StorageUtl_ReadWord(const BYTE* buffer, ULONG offset, WORD* value) > { > - memcpy(value, buffer+offset, sizeof(WORD)); > + *value = le16toh(*(WORD *)(buffer+offset)); > } Why are you removing the memcpy? Are the offsets guaranteed to always be properly aligned? > +#ifdef WORDS_BIGENDIAN > + > +/* FIXME: more-optimal versions may be in <byteswap.h>, <sys/bswap.h>, or > + * <sys/endian.h>. Use config checks to find 'em. No, you don't want config checks, what you want to use here is RtlUshortByteSwap/RtlUlongByteSwap. -- Alexandre Julliard julliard(a)winehq.org

1 0

windows file dialogs with unix file path
by Michael Lin 23 Apr '05

23 Apr '05

Hi all, Back in Nov 2004, there was a brief discussion about extending the Windows file dialogs to allow browsing the Unix file system. Does anyone know if this have been implemented yet? If not, any suggestions on how to implement it? I am porting a windows application to linux using winelib, and using unix file path rather than window file path would be desired. Thanks, Michael

10 16

Re: windows file dialogs with unix file path
by Steven Edwards 23 Apr '05

23 Apr '05

Hi, --- Francois Gouget <fgouget(a)free.fr> wrote: > Hmm, I feel like I've seen that before. Where??? Windows is supposed to be able to be able to handle anything for a drive letter now. I have seen the Euro symbol used for a drive letter. It would be more inituitive to the user to have unix:/ rather than Z: but I don't think GetLogicalDriveStrings() can handle this http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/… so you would need to use RtlDosFilenameToNtFilename or whatever it was called and do some magic with the object manager such as pointing to \\.\unix\ and maybe add "unix:" to the list of built-in device names (like LPTx, AUX, NUL, etc.). Then you might be able to hack a dialog to point to the device name. Thanks Steven __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0