- Wine-Devel - list.winehq.org

Re: Implements OleLoadPicturePath
by Robert Shearman Feb. 28, 2005

Feb. 28, 2005

Maxime Bellengé wrote: >Hello, here is an implementation of OleLoadPicturePath. >The filename can be either a local file or an url. >In case of a url, I needed a user-agent for wininet. I put a dummy value >as I didn't find a default wine value. Is there a default value >somewhere for the whole project ? > >a+ > >Max > >ChangeLog: > * Implements OleLoadPicturePath > > > >------------------------------------------------------------------------ > >Index: wine/dlls/oleaut32/olepicture.c >=================================================================== >RCS file: /home/wine/wine/dlls/oleaut32/olepicture.c,v >retrieving revision 1.55 >diff -u -r1.55 olepicture.c >--- wine/dlls/oleaut32/olepicture.c 25 Feb 2005 14:07:57 -0000 1.55 >+++ wine/dlls/oleaut32/olepicture.c 27 Feb 2005 10:51:43 -0000 >@@ -71,7 +71,9 @@ > #include "olectl.h" > #include "oleauto.h" > #include "connpt.h" >+#include "wininet.h" > #include "wine/debug.h" >+#include "wine/unicode.h" > > #include "wine/wingdi16.h" > #include "cursoricon.h" >@@ -1998,11 +2000,122 @@ > DWORD dwReserved, OLE_COLOR clrReserved, REFIID riid, > LPVOID *ppvRet ) > { >- FIXME("(%s,%p,%ld,%08lx,%s,%p): stub\n", >+ static const WCHAR file[] = { 'f','i','l','e',':','/','/',0 }; >+ static const WCHAR name[] = { 'w','i','n','e','-','a','g','e','n','t',0}; >+ IPicture *ipicture; >+ HANDLE hFile; >+ DWORD dwFileSize; >+ HGLOBAL hGlobal = NULL; >+ DWORD dwBytesRead = 0; >+ IStream *stream; >+ BOOL bRead; >+ IPersistStream *pStream; >+ HRESULT hRes; >+ >+ TRACE("(%s,%p,%ld,%08lx,%s,%p): stub\n", > debugstr_w(szURLorPath), punkCaller, dwReserved, clrReserved, > debugstr_guid(riid), ppvRet); > >- return E_NOTIMPL; >+ if (!ppvRet) return E_POINTER; >+ >+ if (strncmpW(szURLorPath, file, 7) == 0) { >+ szURLorPath += 7; >+ >+ hFile = CreateFileW(szURLorPath, GENERIC_READ, 0, NULL, OPEN_EXISTING, >+ 0, NULL); >+ if (hFile == INVALID_HANDLE_VALUE) >+ return E_UNEXPECTED; >+ >+ dwFileSize = GetFileSize(hFile, NULL); >+ if (dwFileSize != INVALID_FILE_SIZE ) >+ { >+ hGlobal = GlobalAlloc(GMEM_FIXED,dwFileSize); >+ if ( hGlobal) >+ { >+ bRead = ReadFile(hFile, hGlobal, dwFileSize, &dwBytesRead, NULL); >+ if (!bRead) >+ { >+ GlobalFree(hGlobal); >+ hGlobal = 0; >+ } >+ } >+ } >+ CloseHandle(hFile); >+ } else { >+ HINTERNET hInternet; >+ BOOL res = FALSE; >+ >+ hInternet = InternetOpenW(name, INTERNET_OPEN_TYPE_PRECONFIG, NULL, >+ NULL, 0); >+ if (hInternet) >+ { >+ HINTERNET hFile; >+ hFile = InternetOpenUrlW(hInternet, szURLorPath, NULL, -1L, >+ INTERNET_FLAG_RESYNCHRONIZE, (DWORD_PTR)NULL); >+ if (hFile) >+ { >+ DWORD total = 4096; >+ DWORD nbRead; >+ >+ hGlobal = GlobalAlloc(GMEM_FIXED, 4096); >+ if (hGlobal) >+ { >+ do { >+ res = InternetReadFile(hFile, hGlobal, 4096, &nbRead); >+ if (res && (nbRead>0)) >+ { >+ HGLOBAL hNewGlobal; >+ hNewGlobal = GlobalReAlloc(hGlobal, total+4096, 0); >+ if (!hNewGlobal) >+ { >+ res = FALSE; >+ break; >+ } >+ } >+ } while (res && (nbRead>0)); >+ } >+ } >+ >+ InternetCloseHandle(hInternet); >+ } >+ if (!res) >+ { >+ GlobalFree(hGlobal); >+ } >+ } >+ >+ if (!hGlobal) >+ return E_UNEXPECTED; >+ >+ hRes = CreateStreamOnHGlobal(hGlobal, TRUE, &stream); >+ if (FAILED(hRes)) >+ { >+ if (stream != NULL) IStream_Release(stream); > > A valid stream will not be returned on failure, so no need for the extra check here. >+ GlobalFree(hGlobal); >+ return hRes; >+ } >+ >+ hRes = CoCreateInstance(&CLSID_StdPicture, punkCaller, CLSCTX_INPROC_SERVER, >+ &IID_IPicture, (LPVOID*)&ipicture); >+ if (hRes != S_OK) { > > Lack of cleanup code here. >+ return hRes; >+ } >+ >+ hRes = IPicture_QueryInterface(ipicture, &IID_IPersistStream, (LPVOID*)&pStream); >+ if (hRes) { >+ IPicture_Release(ipicture); > > And here. >+ return hRes; >+ } >+ >+ IPersistStream_Load(pStream, stream); > > You should probably check the return value from this function as it is kinda vital to the function you are implementing. >+ IPersistStream_Release(pStream); >+ IStream_Release(stream); >+ hRes = IPicture_QueryInterface(ipicture,riid,ppvRet); >+ if (hRes) >+ FIXME("Failed to get interface %s from IPicture.\n",debugstr_guid(riid)); >+ >+ IPicture_Release(ipicture); >+ return hRes; > } > > /******************************************************************************* > > >Index: wine/dlls/oleaut32/Makefile.in >=================================================================== >RCS file: /home/wine/wine/dlls/oleaut32/Makefile.in,v >retrieving revision 1.57 >diff -u -r1.57 Makefile.in >--- wine/dlls/oleaut32/Makefile.in 27 Oct 2004 00:47:53 -0000 1.57 >+++ wine/dlls/oleaut32/Makefile.in 27 Feb 2005 10:52:08 -0000 >@@ -4,7 +4,7 @@ > SRCDIR = @srcdir@ > VPATH = @srcdir@ > MODULE = oleaut32.dll >-IMPORTS = ole32 rpcrt4 user32 gdi32 advapi32 kernel32 ntdll >+IMPORTS = ole32 rpcrt4 user32 gdi32 advapi32 kernel32 ntdll wininet > DELAYIMPORTS = comctl32 > EXTRALIBS = $(LIBUNICODE) -luuid > > I don't think oleaut32 should be importing from wininet for just the implementation of OleLoadPicturePath. It surprises me that there is not already an implementation of IStream for URLs that can be re-used. If there is no alternative, I think we should just make wininet a delayed import. Rob

2 1

Re: [QUARTZ] Handle End Of Stream notifications
by Robert Shearman Feb. 28, 2005

Feb. 28, 2005

Christian Costa wrote: >Index: dlls/quartz/dsoundrender.c >=================================================================== >RCS file: /home/wine/wine/dlls/quartz/dsoundrender.c,v >retrieving revision 1.6 >diff -u -r1.6 dsoundrender.c >--- dlls/quartz/dsoundrender.c 6 Jan 2005 19:36:47 -0000 1.6 >+++ dlls/quartz/dsoundrender.c 27 Feb 2005 20:48:17 -0000 >@@ -550,8 +550,8 @@ > > static HRESULT WINAPI DSoundRender_JoinFilterGraph(IBaseFilter * iface, IFilterGraph *pGraph, LPCWSTR pName) > { >- HRESULT hr; > DSoundRenderImpl *This = (DSoundRenderImpl *)iface; >+ HRESULT hr = S_OK; > > TRACE("(%p/%p)->(%p, %s)\n", This, iface, pGraph, debugstr_w(pName)); > >@@ -563,7 +563,14 @@ > *This->filterInfo.achName = '\0'; > This->filterInfo.pGraph = pGraph; /* NOTE: do NOT increase ref. count */ > >- hr = IFilterGraph_QueryInterface(pGraph, &IID_IMediaEventSink, (LPVOID*)&This->pEventSink); >+ This->pEventSink = NULL; >+ if (pGraph) >+ { >+ /* Cache IMediaEventSink interface w/o increasing filtergraph refcount */ > > I appreciate that this works perfectly fine at the moment, but these kind of assumptions can lead to difficult to track memory corruptions, so it would be best to avoid caching the object here and querying for it when it's needed. >+ hr = IFilterGraph_QueryInterface(pGraph, &IID_IMediaEventSink, (LPVOID*)&This->pEventSink); >+ if (SUCCEEDED(hr)) >+ IMediaEventSink_Release(This->pEventSink); >+ } > } > LeaveCriticalSection(&This->csFilter); > > Rob

1 0

[SOLVED] Re: Picasa2- works great, one font issue
by Matthew Mastracci Feb. 28, 2005

Feb. 28, 2005

Okay - I checked out the latest Wine from CVS and it seems to be fixed. I think this patch was the one that fixed it: revision 1.82 date: 2005/02/25 13:59:22; author: julliard; state: Exp; lines: +9 -9 TANABE Hiroshi <hirokun_dayomon(a)infoseek.to> wrote: Remove (buf && !buflen) checking. Fixed outline rendering with GGO_GRAY?_BITMAP option. Improved fixed-pitch fonts detection. Here's some screenshots from the program while running: http://www.grack.com/news/Picasa2underWine.html Note that clicking the "email" button in Picasa will crash it - probably the MAPI stubs that cause it: err:mapi:MAPILogon Stub fixme:seh:EXC_RtlRaiseException call (from 0x53e297) to unimplemented function mapi32.dll.MAPISendMail Thanks, Matt. Matthew Mastracci wrote: > I tried out the latest Picasa2 (picasa2-setup-1884.exe) on a whim > against the Wine 20050111 package and it works great. There don't > seem to be any major functionality issues and the app is very > responsive - it almost feels like a native gnome app. > > The one visual issue with the program is that certain fonts within the > program seem to be blitted incorrectly: > > http://www.grack.com/news/Picasa2underWine.html > > It appears that Picasa 2 might ship with some pre-computed > alpha-blended fonts in the form of ".ytf" files in the runtime > directory. When I move these fonts out of the way, all the fonts > (including those fonts used to create the > Import/Slideshow/Timeline/etc. buttons) within the program appear > screwed up like the album-title fonts do when those files are > present. Note that after copying the generated .ytf files from a > Windows '98 installation, all of the characters within Picasa are > rendered perfectly. > > Where might I start looking for the problem? I think it has something > to do with drawing to backbuffer that eventually gets flushed to disk, > since copying the cached font files from a standard Windows install > seems to fix the problem. WINEDEBUG=+gdi doesn't yield much, but I > think WINEDEBUG=+bitmap or WINEDEBUG=+font is where I'm supposed to be > looking. > > Matt. >

2 1

OpenGL _client regression with ATI.
by Oliver Stieber Feb. 28, 2005

Feb. 28, 2005

Hi, after the whole _client, _window changes for VisualID's DirectX started displaying a bit of garbage at the top of the screen, which I toughed was because the window frames weren't taken into account in the view-port. This is sort of what's happening but it's worse. When I'm using ATI's driver, the viewport comes up as the whole screen, so as I move the window from the top left of my desktop so the clipping changes. It also affects non-DirectX stuff, e.g. with a desktop set in ~/.wine/config some windows come up centred as if the whole screen is taken into account and not just the desktop view, and sometimes a window that should be a given size resizes to the whole screen. With mesa the openGL problems don't appear. I haven't had any problems with any other openGL applications so I can only assume that it's a problem in wine. Send instant messages to your online friends http://uk.messenger.yahoo.com

1 0

Patch 16316 causes regression in Irfan View
by Ron Jensen Feb. 28, 2005

Feb. 28, 2005

Patch 16316 causes regression in Irfan View. When I attempt to put Irfan View ( http://appdb.winehq.org/appview.php?appId=163 ) into slide show mode (Menu: File -> Slideshow, add some files and Play) Irfan View locks up and needs a control-c at the console to kill it. I will investigate further tomorrow... ChangeSet ID: 16316 CVSROOT: /opt/cvs-commit Module name: wine Changes by: julliard(a)wine.codeweavers.com 2005/02/24 13:42:08 Modified files: dlls/user : painting.c Log message: Repaint the non-client area to work around broken WM_PAINT handlers also when doing a synchronous update with RDW_UPDATENOW. Patch: http://cvs.winehq.org/patch.py?id=16316 Old revision New revision Changes Path 1.19 1.20 +19 -3 wine/dlls/user/painting.c ________________________________________________________________________

1 0

dsound questions
by Jeremy White Feb. 28, 2005

Feb. 28, 2005

Okay, So I'm trying to clean up dsound before I make it run properly in different scheduling conditions, and I'm having a heck of a time with it; hoping for some advice/thoughts. First, I encountered two glitches in dsound/mixer.c that appear to be bugs, but I do not understand the code well enough to be sure. The attached diff addresses both. Case 1: In the first case, in DSOUND_MixOne, we compute a 'probably_valid_to' based on the 'write_pos', which seems quite wrong; I believe the logic should be testing whether or not there is sufficient data in the mixing buffer, not whether or not there is sufficient room in the buffer overall. Case 2: In DSOUND_PerformMix, I found that on my sound card, I frequently hit cases where 'inq' (afaict, amount mixed but yet to be played) was higher than the computed value of 'maxq' (maximum amount we're supposed to write). At best, the calculations for 'maxq' need to be corrected, and perhaps coupled directly to the code that limits the data. At worst, I suspect the entire block of code could be removed, but I know way too little to be sure. Then, to my great joy, I found two separate apparent OSS bugs on two different systems. In one, the result of DSP_GETOPTR would temporarily 'go backwards' when doing mmaped transfers; in the other, my laptop would just stop reading data out of an mmapped buffer, for no apparent reason. Questions: 1) Is there a good set of OSS test programs (particularly for mmap) I could/should use to simply validate that my system is rational wrt OSS? 2) Are the performance gains from DMA mmap really worthwhile? I wonder if mmap mode is buggy and if we wouldn't be better off swtiching to a pure 'write' approach. I'd appreciate any thoughts/feedback/wacks with a clue bat. Cheers, Jeremy

2 3

Wine cabinet.dll FDI Conformace Test Patch
by Rizwan Kassim Feb. 28, 2005

Feb. 28, 2005

Folks, Aleksandr Liber and I have put together a set of tests for cabinet.dll. Before we submit them to wine-patches, can anyone offer any critiques/input? We plan to submit in a day or two. We're 4th+ year undergraduate students at the UCLA Computer Science program. We're among a group of students doing conformance tests as part of a software engineering course - more info can be found at http://www.geekymedia.com/wine Any advice you can offer will be greatly appreciated! -- Thank you, Rizwan Kassim ***** Patch message follows ***** Wine cabinet.dll FDI Conformace Test Patch (gzipped) Raw files available at : http://www.geekymedia.com/viewcvs/cgi/viewcvs.cgi/group3/wine/ This patch adds tests for the cabinet dll, specifically testing the functions FDICreate, FDIDestroy, FDICopy and FDIIsCabinet. As the FCI functions are still marked TODO in wine, they haven't been tested. The package is self containing, allowing additional cabinet features to be tested by preparing other cabinets in the same manner that ours were. A patch of -p1 will be needed. Changelog:' * configure.ac added dlls/cabinet/tests/Makefile to be generated * dlls/cabinet/Makefile.in added subdirectory reference * dlls/cabinet/tests/Makefile.in standard Makefile.in for tests * dlls/cabinet/tests/cabinet_fdi.c actual test code for FDICreate, FDIDestroy, FDIIsCabinet, FDICopy * dlls/cabinet/tests/data.h contains hex representations of the two test cabinets * dlls/cabinet/tests/tvfs.h * dlls/cabinet/tests/tvfs.c Trivial Virtual File System emulating _read, _write, _open, _lseek and _close * dlls/cabinet/tests/genfiles.sh Cabinet/data.h creation script used for simple.cab and complex.cab- current tests * tools/chexify.pl converts input files to C style arrays Signed-off-by: Rizwan Kassim <rizwank(a)geekymedia.com> Signed-off-by: Dan Kegel <dank(a)kegel.com> Signed-off-by: Aleksandr Liber <aliber(a)ucla.edu>

2 1

Use of Favourite instead a Favorite in our regedit
by Paul Vriens Feb. 28, 2005

Feb. 28, 2005

Hi, while looking through some registries (via regedit) on several windows versions and Wine, I saw that we use Favourites/Favourite etc.. instead of Favorites/Favorite in our regedit implementation. Is this deliberate or should I create a patch for this? The patch will also change ID_FAVOURITES_MENU, ID_FAVOURITES_ADDTOFAVOURITES,ID_FAVOURITES_REMOVEFAVOURITE. I know it's not a functional change, but hey, one has to be busy. Cheers, Paul

1 0

Re: WIDL - Sync to ReactOS 20050227
by Steven Edwards Feb. 28, 2005

Feb. 28, 2005

--- Steven Edwards <steven_ed4153(a)yahoo.com> wrote: > Changelog: > Eric Kohl <eric.kohl(a)t-online.de> > > Server stubs are void functions. > Fix a warning in the server stub descriptor. > Support multiple interfaces per idl file. > Support explicit binding handles. > Support remaining basic types (float, double, small, wchar_t and handle_t). I forgot to rebuild my whole tree after this patch and am getting a error so hold off. steven(a)steven:/usr/src/wine/dlls/ole32# ../../tools/widl/widl -I. -I. -I../../include -I../../include -D__WINESRC__ -D_OLE32_ -DCOM_NO_WINDOWS_H -h -H dcom.h dcom.idl error: ResolveOxid() must not define a binding handle! Thanks Steven __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail

1 1

free fonts
by Brian Vincent Feb. 28, 2005

Feb. 28, 2005

The issue of fonts came up a while ago and I know some people are working on free replacements for some of the core fonts. Anyway, I stumbled on this resource tonight with a huge listing of fonts: http://cgm.cs.mcgill.ca/~luc/originalfonts.html Seems like there's got to be a few decent ones in there the authors would be willing to let us use and relicense. -Brian

1 0