wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

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

Use of Favourite instead a Favorite in our regedit
by Paul Vriens 28 Feb '05

28 Feb '05

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

28 Feb '05

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

28 Feb '05

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

Re: [PATCH] Added 2 functions to shell32
by Dmitry Timoshkov 28 Feb '05

28 Feb '05

"Gianluigi Tiesi" <sherpya(a)netfarm.it> wrote: > +BOOL WINAPI PathIsEqualOrSubFolder(LPCWSTR path1, LPCWSTR path2) > +{ > + int i; > + int len; > + if (!path1 || !path2) return FALSE; > + > + len = strlenW(path1); > + if (len > strlenW(path2)) return FALSE; > + > + for (i=0; i < len; i++) > + if (path1[i] != path2[i]) return FALSE; > + return TRUE; > +} You need to do a case insensitive comparison of paths. Also, if you could use a usual for Wine formatting style with 4 space indentation that would be very nice. -- Dmitry.

2 1

Re: comctl32 - SB_SETBORDERS
by Thomas Weidenmueller 28 Feb '05

28 Feb '05

Steven Edwards wrote: >Filip implemented this for me when I was testing Office97 under ReactOS and I never got around to >merging it to the ros tree. > > SB_SETBORDERS does not exist in current versions of NT. It might be a something from the old 3.x days. NT 5.0 and 5.1 for sure don't implement them. Even though Office tries to use them I oppose implementing it. Best Regards, Thomas

2 2

status of winetest.exe
by Stefan Leichter 28 Feb '05

28 Feb '05

Hello Paul, i have noticed that the winetest are not longer built since the middle of the week. Can you take a look if something is broken? Thanks Stefan

2 1

Re: shell32: formatting and unicodification
by Alexandre Julliard 27 Feb '05

27 Feb '05

Juan Lang <juan_lang(a)yahoo.com> writes: > Mike's formatting changes got in, so here's one of my own. > > ChangeLog: convert tabs to spaces, make indenting consistent, convert more > calls to Unicode Please don't mix formatting changes with other things, it makes it very painful to review. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: setupapi: enumerate serial ports
by Alexandre Julliard 27 Feb '05

27 Feb '05

Juan Lang <juan_lang(a)yahoo.com> writes: > + /* FIXME: it should be possible for more than four COM ports to exist, not > + * sure why we retain that limit, but winspool does too so go with it. > + */ > + for (i = 0, ret = 0; i < 4; i++) > + { > + if (SETUP_SerialPortExists(i)) > + ret++; > + } There's no reason to limit to 4 serial ports (and winspool should be fixed too). Probably the best way is to do a QueryDosDevice(NULL) which gets you a full device list and the return every COM device in that list. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Fix a race condtition in the server startup
by Bill Medland 27 Feb '05

27 Feb '05

On February 26, 2005 03:43 pm, Francois Gouget wrote: > There is a race condition in the server startup code which arises if two > I propose the following fix: > > if (lstat( name, st ) == -1) > { > if (errno != ENOENT) fatal_perror( "lstat %s", name ); > if (mkdir( name, 0700 ) == -1 && errno != EEXIST) fatal_perror( > "mkdir %s", name ); > > Using the existing directory is ok because we then check its ownership, > permissions, etc. (which we have to do anyway in case it already existed). How about simply mkdir and if the error is already existed then fine.? Unchecked, but something like: if (mkdir (name, 0700) == -1) { if (errno != EEXIST) fatal_perror ("Ensuring directory %s", name) } > > > Changelog: > > * server/request.c > > Francois Gouget <fgouget(a)codeweavers.com> > Fix a race condition in create_dir(). -- Bill Medland mailto:billmedland@mercuryspeed.com http://webhome.idirect.com/~kbmed

1 0

riched20 patch preview
by Krzysztof Foltman 27 Feb '05

27 Feb '05

I've finally managed to make my riched20 code usable (hardly) and compatible with Wine. It's probably not good enough to go to CVS, but, at least, it's something you can try out. Comments are welcome. It should work with all programs that load RICHED20.DLL directly. For programs that load RICHED32.DLL you need a native version of that DLL (which is a wrapper for RICHED20.DLL, providing compatibility with 1.0 version of the control, the most important thing it does is loading RICHED20.DLL, which registers 2.0 window classes). http://foltman.com/riched20.tar.gz http://foltman.com/richeditpatch.diff Note, that EM_STREAMIN and EM_STREAMOUT don't work, so if your program uses RTF to insert text to the control, it won't work ! WinXP WordPad doesn't work either, as it uses RICHEDIT50W window class (what I provide is RichEdit20W control, haven't tried to fake it's 5.0). Have fun! Krzysztof

1 1

Re: vartest.c - major pain in the build process
by Dmitry Timoshkov 27 Feb '05

27 Feb '05

"Krzysztof Foltman" <kfoltman(a)portal.onet.pl> wrote: > > Well, I'd argue that compilation time of full Wine tree is much longer > > than that single test. If you compile from source it's your choice. > > It's still an important percentage of the total compile time. And it's > not always possible to use binaries - particularly I'm not the best > candidate for that option, being a Wine hacker ;-) Then perhaps it's better to upgrade your hw/compiler/etc, or somehow schedule your development time to compile Wine while you are doing something else. > > Even more drastic route to go is to go and complain to gcc people, > > that's certainly not a Wine fault. > > Well, almost no other program triggers this misbehaviour, so it might be > useful to work around that bug. It's a very dubious statement. I'm certain that this is not a Wine bug since compiling that code with MSVC compiler works several times faster. > Or disable the test by default > completely. It could save hundreds of users from hours of wasted time. Ordinary users are not supposed to compile the code intented for developers only. > Looks like a pragmatic solution. It's not Wine's fault, but it's not the > user's fault either, so why punish him for gcc bugs if it's not necessary? Sure, that's why we have already compiled binaries for download. > It's a bit awkward to require everyone to upgrade a monster like gcc in > order to speed up a several minute long (10 minutes and more) > compilation of the module that has little use for most users and even > developers. Then just disable the code you don't want to compile in your tree before building Wine. Just do it locally, and not ask everybody to follow your preferences. -- Dmitry.

1 0

Problem using winelib to compile Std Lib strings
by Rob D 27 Feb '05

27 Feb '05

Ive undertaken the task of converting 2 rather large Win32 applications to run on Solaris 10. I have managed to tweak nearly all of the files so they will compile with wine after running winemaker. The files I cant seem to compile are ones that use std string. I get a few errors like the following: error: ::div has not been declared error: ::ldiv has not been declared And tons about /usr/include/pthread.h like the following: error: uintptr_t does not name a type error: caddr_t has not been declared error: caddr_t does not name a type error: pthread_attr_t was not declared in this scope The files in question have lines like the following: #include <string> using namespace std; Ive tried including various additional header files like <sys/types.h> and <dtrace/h>, with varying success, but still approx 200 errors when trying to compile these files. The error lines say they are from include/c++/3.4.2, so Im assuming that it is using the 3.4.2 compiler as opposed to the 2.95 one also installed on these machines. The development Ive been tasked with will move several people off of winblows machines and onto Solaris 10 if I can succeed, so it is even more critical in my mind to get this to work. Rob

2 1

winedbg hanging
by Alex Woods 26 Feb '05

26 Feb '05

Hello, When I try to run winedbg with the --gdb option, it simply hangs. I've tracked this down to dbg_get_debuggee_info returning false and then everything falling through to a wait(NULL). The callback that is getting passed SymEnumerateModules doesn't seem to be getting called at all. I've put traces into the SymEnumerateModules but they aren't spitting anything out. Here is the function getting called though: 0035:CALL dbghelp.SymEnumerateModules(<unknown, check return>(0x558b0000,00000002,00000040): returning 558c5de8) ret=55b1f6be 0035:RET dbghelp.SymEnumerateModules(0000003c,55b1f590,55c3f4b0) retval=00000001 ret=55b1f6be0 I'm not I believe that it is getting called, at least not the one in dbghelp/module.c. I've stuck an exit at the top of it, and it doesn't. I've noticed a SymEnumerateModules64 that is just a stub, and that's made me suspicious because I'm running a multilib compiled wine on an x86_64 platform. Also, could that be a problem, since gdb is compiled as 64-bit? I'm pretty sure I'm either being dense, or something is happening that I'm not aware of. Could someone point out which, please? ;) Cheers. -- Alex

1 1

Re: MSVCRT: Generating relay stubs for libc forwards/varargs
by Jon Griffiths 26 Feb '05

26 Feb '05

Hi Uwe, >I think it would be helpfull, if we could generate debug stubs for >these functions. Can anybody help? If you have the SDK headers, winedump in spec mode can generate this for you. Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250

2 2

MSVCRT: Generating relay stubs for libc forwards/varargs
by Uwe Bonnes 26 Feb '05

26 Feb '05

Hallo, in msvcrt a lot of functions are of type vararg (e.g. printf) or are forwards into the Linux libc (e.g. strstr) and so leave no trace in a +relay log. This makes it harder to debug. I think it would be helpfull, if we could generate debug stubs for these functions. Can anybody help? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: Relax test requirements to accomodate fuzz of msacm
by Robert Reif 26 Feb '05

26 Feb '05

Jeremy White wrote: > Robert has persuaded me that msacm on Windows does make 'fuzzy' > conversions; > an 8,000 byte buffer is up sampled to a 47,992 byte buffer instead of > the logical (and correct seeming) 48,000 byte buffer. This means that > when we go to get the position after playing the answer comes up as > 47992 instead of 48,000, which causes a winmm test failure. The real fix is to fix the wave mapper to do another conversion when the previous one is incomplete. We will have to do this anyway if we ever try to support non PCM formats.

2 3

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