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

Re: [programs/regedit] Use Favorit* instead of Favourit*
by Robert Shearman 01 Mar '05

01 Mar '05

Paul Vriens wrote: >Hi, > >Our regedit displays Favourites in the menu. This patch changes that to >use Favorites. The patch also changes the variables with FAVOURITE in >the name. The reasoning is: > >a. Windows uses Favorite(s) all over the place. >b. We do too. > >That's the only reasoning and not if either one is better (UK/US etc..) > >No functional changes btw. > >Changelog > Change Favourite(s) into Favorite(s) > > Fair enough for strings in the English, US resources, as long as the strings in the English, Neutral resources are still spelt correctly. > Change variables containing FAVOURITE into FAVORITE > > Why do this? Rob

2 1

Crash in Polar Precision Performance Software
by Ron Jensen 28 Feb '05

28 Feb '05

Hello, This trace is from Polar's Precision Performance Software http://www.codeweavers.com/site/compatibility/browse/name?app_id=681 running on CVS wine. This crash happens with CVS wine, and wine I compiled from http://ftp.codeweavers.com/pub/crossover/office/source/office-src-4.1.0.tgz It does not happen with the precompiled binaries in CXOffice's Loki installer. Can someone give me a clue as to were to start looking to fix this? Thanks. /*******/ wineuser$wine 'C:\Program Files\Polar\Polar 32.exe' fixme:gdi:Escape16 unknown/unsupported 16-bit escape c03 (56,0x403815de,0x40381626 fixme:gdi:Escape16 unknown/unsupported 16-bit escape c03 (56,0x403815de,0x40381626 wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0xa84c73e0 in 32-bit code (0x00415809). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:00415809 ESP:4069e63c EBP:4069e6c4 EFLAGS:00010282( - 00 - RIS1) EAX:00000000 EBX:4082f8d4 ECX:a84c73e0 EDX:000004e7 ESI:4069f3f0 EDI:00020040 Stack dump: 0x4069e63c: 00414e23 4069f3f0 000004e7 00020040 0x4069e64c: 4069f3f0 4069e6c4 4082f8d4 004144c9 0x4069e65c: 00020040 4069f3f0 000004e7 0052c3ec 0x4069e66c: 00020040 00000638 00020040 000000a0 0x4069e67c: 00020040 408517a8 4069e6c4 4082f8d4 0x4069e68c: 403d6a28 403d6980 00000000 4007aa04 Backtrace: =>1 0x00415809 in polar 32 (+0x15809) (0x4069e6c4) 2 0x407ae6c0 WINPROC_CallWndProc+0x70(msg=0x4e, wParam=0x0, lParam=0x4069edf0) [/home/wineuser/src/wine/dlls/user/../../windows/winproc.c:419] in user32 (0x4069e700) 3 0x407b393e CallWindowProcA+0xfe(func=0x408517a8, hwnd=0x20040, msg=0x4e, wParam=0x0, lParam=0x4069edf0) [/home/wineuser/src/wine/dlls/user/../../windows/winproc.c:2940] in user32 (0x4069e72c) 4 0x4078ff36 DefDlgProcA(hwnd=0x20040, msg=0x4e, wParam=0x0, lParam=0x4069edf0) [/home/wineuser/src/wine/dlls/user/../../windows/defdlg.c:453] in user32 (0x4069e75c) 5 0x407ae277 WINPROC_wrapper+0x17 in user32 (0x4069e780) 6 0x407ae6c0 WINPROC_CallWndProc+0x70(msg=0x4e, wParam=0x0, lParam=0x4069edf0) [/home/wineuser/src/wine/dlls/user/../../windows/winproc.c:419] in user32 (0x4069e7bc) 7 0x407b3be4 CallWindowProcW+0x184(func=0x4085145a, hwnd=0x20040, msg=0x4e, wParam=0x0, lParam=0x4069edf0) [/home/wineuser/src/wine/dlls/user/../../windows/winproc.c:3053] in user32 (0x4069eca0) 8 0x407e1d13 call_window_proc+0xc3(wparam=0x0, lparam=0x4069edf0, unicode=0x1, same_thread=0x1) [/home/wineuser/src/wine/dlls/user/message.c:1475] in user32 (0x4069ed00) 9 0x407e1eef SendMessageTimeoutW+0x14f(hwnd=0x20040, msg=0x4e, wparam=0x0, lparam=0x4069edf0, flags=0x0, timeout=0xffffffff, res_ptr=0x4069ed80) [/home/wineuser/src/wine/dlls/user/message.c:1989] in user32 (0x4069ed5c) 10 0x407e1f35 SendMessageW(hwnd=0x20040, msg=0x4e, wparam=0x0, lparam=0x4069edf0) [/home/wineuser/src/wine/dlls/user/message.c:2070] in user32 (0x4069ed88) 11 0x406eee3b PROPSHEET_SetCurSel(skipdir=0x1, hpage=0x403e2cd0) [/home/wineuser/src/wine/dlls/comctl32/propsheet.c:2102] in comctl32 (0x4069ee0c) 12 0x406f26c4 PROPSHEET_DialogProc(hwnd=0x4002e, uMsg=0x110, wParam=0x0, lParam=0x403e2328) [/home/wineuser/src/wine/dlls/comctl32/propsheet.c:3379] in comctl32 (0x4069f3f0) 13 0x407ae277 WINPROC_wrapper in user32 (0x4069f414) 14 0x407ae6c0 WINPROC_CallWndProc(msg=0x110, wParam=0x0, lParam=0x403e2328) [/home/wineuser/src/wine/dlls/user/../../windows/winproc.c:419] in user32 (0x4069f450) 15 0x407b393e CallWindowProcA+0xfe(func=0x40851794, hwnd=0x4002e, msg=0x110, wParam=0x0, lParam=0x403e2328) [/home/wineuser/src/wine/dlls/user/../../windows/winproc.c:2940] in user32 (0x4069f47c) 16 0x4078ff36 DefDlgProcA(hwnd=0x4002e, msg=0x110, wParam=0x0, lParam=0x403e2328) [/home/wineuser/src/wine/dlls/user/../../windows/defdlg.c:453] in user32 (0x4069f4ac) 17 0x407ae277 WINPROC_wrapper+0x17 in user32 (0x4069f4d0) 18 0x407ae6c0 WINPROC_CallWndProc+0x70(msg=0x110, wParam=0x0, lParam=0x403e2328) [/home/wineuser/src/wine/dlls/user/../../windows/winproc.c:419] in user32 (0x4069f50c) 19 0x407b3be4 CallWindowProcW+0x184(func=0x4085145a, hwnd=0x4002e, msg=0x110, wParam=0x0, lParam=0x403e2328) [/home/wineuser/src/wine/dlls/user/../../windows/winproc.c:3053] in user32 (0x4069f9f0) 20 0x407e1d13 call_window_proc+0xc3(wparam=0x0, lparam=0x403e2328, unicode=0x1, same_thread=0x1) [/home/wineuser/src/wine/dlls/user/message.c:1475] in user32 (0x4069fa50) 21 0x407e1eef SendMessageTimeoutW+0x14f(hwnd=0x4002e, msg=0x110, wparam=0x0, lparam=0x403e2328, flags=0x0, timeout=0xffffffff, res_ptr=0x4069fad0) [/home/wineuser/src/wine/dlls/user/message.c:1989] in user32 (0x4069faac) 22 0x407e1f35 SendMessageW(hwnd=0x4002e, msg=0x110, wparam=0x0, lparam=0x403e2328) [/home/wineuser/src/wine/dlls/user/message.c:2070] in user32 (0x4069fad8) 23 0x4079427e DIALOG_CreateIndirect(owner=0x1004e, dlgProc=0x406f1780, param=0x403e2328, unicode=0x0, modal=0x1) [/home/wineuser/src/wine/dlls/user/../../windows/dialog.c:667] in user32 (0x4069fbe4) 24 0x407946d9 DialogBoxIndirectParamAorW+0x39(hInstance=0x400000, template=0x403e17a8, owner=0x1004e, dlgProc=0x406f1780, param=0x403e2328, flags=0x2) [/home/wineuser/src/wine/dlls/user/../../windows/dialog.c:841] in user32 (0x4069fc08) 25 0x4079476b DialogBoxIndirectParamA(hInstance=0x400000, template=0x403e17a8, owner=0x1004e, dlgProc=0x406f1780, param=0x403e2328) [/home/wineuser/src/wine/dlls/user/../../windows/dialog.c:852] in user32 (0x4069fc2c) 26 0x406edb53 PROPSHEET_CreateDialog [/home/wineuser/src/wine/dlls/comctl32/propsheet.c:729] in comctl32 (0x4069fc5c) 27 0x406f0961 PropertySheetA+0x2d1(lppsh=0x4069fca4) [/home/wineuser/src/wine/dlls/comctl32/propsheet.c:2794] in comctl32 (0x4069fc80) 28 0x00414354 in polar 32 (+0x14354) (0x00000111) 29 0x00000000 (0x00000000) 0x00415809: cmpl %edx,0x0(%ecx) Wine-dbg>quit WineDbg terminated on pid 0x8

2 2

Help with winebuild/winegcc
by Ivan Leo Puoti 28 Feb '05

28 Feb '05

Hello, I'm trying to get a program in the programs/ directory to export symbols, I've added -shared path/to/spec/spec.c to the linker command, but I now get a segmentation fault at startup. Can someone knowledgeable about winegcc/winebuild give me a suggestion/solution? I'm really stuck because of this and can't get on with safedisc support. Ivan.

1 0

Re: Implements OleLoadPicturePath
by Robert Shearman 28 Feb '05

28 Feb '05

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 28 Feb '05

28 Feb '05

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 28 Feb '05

28 Feb '05

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 28 Feb '05

28 Feb '05

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 28 Feb '05

28 Feb '05

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 28 Feb '05

28 Feb '05

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 28 Feb '05

28 Feb '05

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