wine-devel

wine-devel@winehq.org

10 participants
84459 discussions

Building DLLs and other Qs
by Peter Riocreux 23 Jul '04

23 Jul '04

Before I get onto my questions I would just like to say: This mail is not intended to start a flame war ---------------------------------------------- It is intended in a spirit of understanding what is the current status. First the quick question - I want to install a built-from-CVS wine on multiple Fedora Core 1 machines. I can't find a spec file anywhere to make an RPM with - should I just pinch one from a FC1 Wine package, or is anyone maintaining a set of package-build scripts (RPM, dpkg, etc.)? Now the more complicated and possibly flame-inducing question. While looking round the source tree for a spec file I noticed that all the WINE DLLs seem to end up as .dll.so files. I assume this is because the native platform's gcc can't build a real DLL, so it is wrapped up as a .so and wine (the binary) loads them as such and them does a connect-the-dots exercise to make it look to the application as if it loaded a real DLL. My understanding is that a cross-compiled gcc would build real DLLs, and as wine is able to load them when given them, would there be any advantage to building them with a cross-compiling toolchain if one were available. I am thinking here of perhaps some kind of loading speed improvement (unlikely to be significant if any) or maybe some perverse custom installer that looks for specifically named files in specific places on the filesystem it sees. If there is no advantage, could the converse be true - that there would be some benefit to wrapping native DLLs in a .so shell for speed improvement - perhaps analysing the DLL on load is very hard work and if this were done once and the result saved as a .so ..... Peter

3 2

Re: COM outproc & CFProxy unhandled interface for IRunnableObject
by Jeroen Janssen 23 Jul '04

23 Jul '04

> From: Mike Hearn <mike(a)navi.cx> >> Maybe my 'real' problem is that based upon the logging, I also see a >> CFProxy Unhandled interface for the first interface that the client is >> trying to access (but I need to know more about how COM/wine deals with >> this). > > Are you sure you're using COM right? I have also written an outproc > server test and it works OK - at least I've been able to marshal a Hello > World RPC across. Well, it seems to work ok on Windows, so there must be something 'ok' about it. Also, I did not write the application myself. I'm just trying to get it run under wine. I am not sure, but there seems to be a difference in the outproc handling of the CoCreateInstance call? This goes ok: hr = CoCreateInstance(CLSID_Component1, NULL, clsctx, IID_IX, (void**)&pIX) ; However this seems to go wrong?: hr = CoCreateInstance(CLSID_Component1, NULL, clsctx, __uuidof(IUnknown), (void**)&pIUnknown); hr = pIUnknown->QueryInterface(IID_IX, (void **)&pIX); Summary: If you perform a CoCreateInstance for IUnknown (outproc), you get back the classfactory instead of the proxy to the object itself? Maybe you can check this behaviour? (I don't know exactly if this is indeed what seems to wrong or that I might have made a mistake with the simple test program). > Me and Rob are starting to scrape together a plan, I think, and as part of > working on other apps we're fixing bits as we go, but it's a long long > road we have ahead of us. Any help would certainly be welcome. Well, I'm trying get this application running with wine, I don't know what else I might walk into, but I surely hope to do some contributions to wine in the process. --- Jeroen Janssen

3 2

building COM client/server with proxy using winelib & widl?
by Jeroen Janssen 23 Jul '04

23 Jul '04

Hello, I was wondering whether there is a wine COM client/server application that makes use of winelib & widl (to generate a proxy/stub dll). Apparently I'm missing some #defines in wine's rpcproxy.h in order to be able build the proxy/stub dll? For instance: PROXYFILE_LIST_START PROXYFILE_LIST_END REFERENCE_PROXY_FILE It seems that these defines are present in the rpcproxy.h included with MinGW? I googled for it and found http://www.cs.up.ac.za/courses/EPE210/software/MinGW-1.1/include/rpcproxy.h On a side note can widl generate proxy/stub code yet? --- Jeroen Janssen

2 1

about wine dsound
by Magnus Olsen 23 Jul '04

23 Jul '04

HI My name are Magnus Olsen (call GreatLord at reactos channel) I am one of reactos devlooper I we are now trying get the sound working in reactos. I did start to port over wine dsound and find out it did have it own api layer, to get dsound guid, and other stuff. I did rewrite to thuse part to get it working under windows. Yes wine dsound with some modifaction are now working in windows. we need now do some modifaction to wine winmm get it windows / reactos compatible. the GetDeviceID in Dsound get the value from the windows / reactos system register now. and it works under windows 2k / XP write a api layer betwin dsound api call to WaveInMessage and WaveOutMessage DRV_QUERYDSOUNDGUID 100% support for windows and reactos) DRV_QUERYDSOUNDDESC 80% support for windows and reactos need to figut how to get some data from windows api) DRV_QUERYDSOUNDIFACE 0% force dsound to software emulation mode until I or some else fix it for windows or reactos

1 0

Re: Check Server Version From Client Dlls
by Andreas Mohr 23 Jul '04

23 Jul '04

Hi, On Thu, Jul 22, 2004 at 02:59:47PM +0100, Robert Shearman wrote: > > Changelog: > Check server version from x11drv, kernel32 and user32 to prevent > mismatches of installed dlls. Slight overkill, I'd say. Why not do: if (!wine_server_check_version( "x11drv", SERVER_PROTOCOL_VERSION )) ... if (ver != SERVER_PROTOCOL_VERSION) MESSAGE( "Error: server version mismatch.\n" "Your %s binary was not upgraded correctly\n" "or the wrong wineserver is still running.\n", dll_name ); return (ver == SERVER_PROTOCOL_VERSION); Greetings, Andreas Mohr

3 5

Re: PATCH: controls/menu.c case ranges
by Alexandre Julliard 22 Jul '04

22 Jul '04

Marcus Meissner <marcus(a)jet.franken.de> writes: > Another try on fixing the case range problems (WORD is unsigned, > HBMMENU_CALLBACK is -1, so out of range of the switch). I think this is revealing a deeper problem with that code, the magic value check should be done against the whole handle, not just the low word. -- Alexandre Julliard julliard(a)winehq.org

2 1

too many functions in msvcrt20.dll?
by Chipzz 22 Jul '04

22 Jul '04

I was looking at porting a small subset of msvcrt80.dll, and so I took a look at msvcrt20.dll. I first used a disassembler to get a list of the functions in the native windows dll, ran a script over that, and then ran another script over msvcrt20.spec. Much to my surprise, the wine implementation has more(!!) functions than the native dll. So, I was wondering, this screws up the index of these functions in the list, right? Does that index actually matter? The diff between the 2 files is attached. With kr, Chipzz AKA Jan Van Buggenhout -- ------------------------------------------------------------------------ UNIX isn't dead - It just smells funny Chipzz(a)ULYSSIS.Org ------------------------------------------------------------------------ "Baldric, you wouldn't recognize a subtle plan if it painted itself pur- ple and danced naked on a harpsicord singing 'subtle plans are here a- gain'."

2 1

daily wine cvs source snapshots?
by Jeroen Janssen 22 Jul '04

22 Jul '04

Hello, I was wondering since: 1) wine uses CVS (and not svn with httpwebdav) and 2) CVS doesn't go through the firewall at my work (and possible also not for other people) Would it be possible to have daily cvs snapshots (cvs export) of the wine HEAD tree? This makes tracking the latest HEAD possible for people that can't use CVS to access the repository. I know that the CVS repository itself is available, but that sounds a bit overkill to me. best regards, Jeroen Janssen

3 3

Re: devenum
by Marcelo Duarte 22 Jul '04

22 Jul '04

Ivan Leo Puoti wrote: > English resources moved to En.rc, language neutral resources moved to Xx.rc, > and italian resources added in It.rc > Licence: LGPL > > Ivan. Ivan, Why you do not leave the neutral resources in the main archive? Greetings, Marcelo

1 0

COM outproc & CFProxy unhandled interface for IRunnableObject
by Jeroen Janssen 22 Jul '04

22 Jul '04

Hello, I'm trying to run 2 programs: 1) is a COM server program 2) is a COM client program Now, program 2) tries to access a COM component from 1) (outproc). It seems some marshalling is being done, but eventually I get: fixme:ole:CFProxy_QueryInterface Unhandled interface: {00000126-0000-0000-c000-000000000046} This interface seems to be IRunnableObject. Now I'm not exactly sure how this is supposed to work, or even if this is the reason why my test currently fails. I can provide more logging/info if I know what exactly to provide. Note that I tried a small outproc client/server test that seems to go ok without this error, so the 'basic' outproc mechanism seems to work ok. Can someone provide more information on how wine deals with Outproc COM? On a side note, what are the main differences in COM implementation between wine and winex (if I understand correctly, Transgaming rewrote the COM implemenation for winex in order to better support the InstallShield installer?). Best regards, Jeroen Janssen

3 3

tests: safe MAPI init
by Ferenc Wagner 22 Jul '04

22 Jul '04

Hi (and sorry for the broken post), the mapi32 tests call scInitMapiUtil, which pops up an alert box saying something like (translating it) "Your default mailer application isn't capable of this operation, please ensure that Outlook is configured as the default mailer." This brings the tests to a halt, and even after clicking OK one gets 65536 failures bumping the logs above 5 MB. As a side note, most of the mapi tests are very careful about calling every function through a pointer acquired by GetProcAddr(), still the test executable is linked with -lmapi32. Does it make any sense? From winetest's perspective it isn't worth much, if a test can't run it's skipped altogether. Does it take care about different mapi versions? There are no recent reports on test.winehq.org/data, so something is obviously wrong. I'd be interested in hearing about people running Chris' winrash service. What happens if you run winetest directly? Don't forget to supply you tag with the -t option! Basically, winetest's own message boxes are OK, system message boxes are a problem. Thanks, Feri.

2 4

tests: safe MAPI init
by Ferenc Wagner 22 Jul '04

22 Jul '04

Hi, the mapi32 tests call scInitMapiUtil, which pops up an alert box

1 0

Serial port patch in 20040716
by Scott Snell 22 Jul '04

22 Jul '04

I installed 20040716 from an rpm and although most of it worked very well I had issues with the serial port. It would send out some characters at the start but I couldnt read any characters. After reading the thread "General serial communications issues" I found Eric Pouech's patch. I downloaded the source for 20040716 and applied the patch. I had to add #define for FD_FLAG_AVIALABLE in several files to get the project to compile. Unfortunately it doesnt solve my problem. Is there a particular version of the source I should apply the patch to? Does anyone have a patch for 20040716 source? Am I missing something fundamental with setting up serial ports? ta scott.

1 0

Localization status
by Marcelo Duarte 22 Jul '04

22 Jul '04

Hi, I modified a tool that Vincent Béron made and thus we can have the status of the translation of some languages. Case somebody wants that I add others I inform me. We can see that some languages are well complete, as the Portuguese ;) file:///home/mduarte/wine/tools/trans_html/index.html <cid:part1.03040507.04030402@bol.com.br>

1 0

Localization status
by DTM Informática 22 Jul '04

22 Jul '04

1 0

Re: Avoid BadMatch Error
by Alexandre Julliard 22 Jul '04

22 Jul '04

Philip Dicke <Philip.Dicke(a)raytheon.com> writes: > Sometimes, when converting from a disabled pixmap for an icon in > x11drv/bitblt.c, an area is requested using XGetImage that is larger then > the actual drawable. This causes a X BadMatch error and wine immediately > exits. The submitted patch avoids this error by checking the size of the > requested area and the size of the drawable in BITBLT_GetSrcArea. That should not happen, the drawable size must have been taken into account when computing visRectSrc already. You'll need to find out why visRectSrc doesn't contain the proper size in your case. -- Alexandre Julliard julliard(a)winehq.org

1 0

pthread_mutex in a winelib dll called from a win32 application
by Shachar Shemesh 22 Jul '04

22 Jul '04

Hi all, Are there any restrictions in synchronizing wine generated threads (generated through the win32 api) using the pthreads library native calls? I have an app that is experiencing extremely slow performance (operation takes 17 seconds on native windows, over 3 minutes on Wine). One idea for solving this problem was to switch some of the synchronization operations over to native pthreads (it's using wine as part of a migration to Linux process). The problem is that when I try to call pthread_mutex_init, pthread_mutex_lock and friends, I get quite a few deadlocks, and even when not deadlocking, it still takes over 42 seconds. When doing the same without the mutexes (I'm locking write access to a pipe - I'm not sure it's even necessary, and it is working without the lock too), wine performs at 21-26 seconds. I don't think that obtaining a posix mutex should have such harsh effect on performance. Is it at all ok to try and synchronize threads created with "CreateThread" using posix constructs? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

5 7

crash in menu.c
by Dan Timis 21 Jul '04

21 Jul '04

One of the third party Windows software that we support is crashing when clicking on a popup menu that has separators. The author of the software send us a snippet of his code. It looks something like this: MENUITEMINFO mi; ZeroMemory(&mi, sizeof(mi)); mi.cbSize = sizeof(mi); mi.fType = MFT_SEPARATOR; InsertMenuItem(hMenu, index++, TRUE, &mi); The problem is obviously that mi.fMask does not have the MIIM_TYPE bit set. This code "works" on Windows; it draws a separator like the programmer intended, but not like the API would suggest this should work. I'm not sure what should be wine's behavior, but I don't think it should crash. The crash in wine happens when MENU_InitTracking calls MENU_ShowPopup, which in turn calls MENU_CalcItemSize: trace:menu:MENU_CalcItemSize dc=0x11ac owner=0x10025 (3,56) trace:menu:do_debug_print_menuitem MENU_CalcItemSize: menuitem: { ID=0x4, State=grey, Text=L"Save Preset As..." } trace:menu:MENU_CalcItemSize (3,56)-(148,74) trace:menu:MENU_CalcItemSize dc=0x11ac owner=0x10025 (3,74) trace:menu:do_debug_print_menuitem MENU_CalcItemSize: menuitem: { ID=0x0, Text=Null } wine: Unhandled exception (thread 0009), starting debugger... ... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x40de985c). ... 0x40de985c (MENU_CalcItemSize+0x13c [menu.c] in USER32.DLL): repne scasw^I%es:(%edi) Earlier, I get this trace: trace:menu:do_debug_print_menuitem MENU_SetItemInfo_common from: { ID=0x0, Text=Null } trace:menu:do_debug_print_menuitem SetMenuItemInfo_common to : { ID=0x4, State=grey, Text=L"Save Preset As..." } trace:menu:do_debug_print_menuitem MENU_SetItemInfo_common from: { ID=0x0, Text=Null } trace:menu:do_debug_print_menuitem SetMenuItemInfo_common to : { ID=0x0, Text=Null } I don't understand how this "from" and "to" works, but the ID of the menu item after "Save Preset As..." should be 0x5. I have a wine version from 2004-04-08. The author of the Windows software will fix the problem in his code and that should stop the crash, but maybe someone should fix this in wine too. Thanks, Dan Timis Muse Research, Inc.

1 0

Re: cleanup a->w cross calls in advapi32/crypt.c
by Alexandre Julliard 21 Jul '04

21 Jul '04

James Hawkins <truiken(a)gmail.com> writes: > - PCSTR KEYSTR = "Software\\Microsoft\\Cryptography\\Defaults\\Provider\\"; > - PSTR keyname; > + PCWSTR KEYSTR = (PCWSTR)"Software\\Microsoft\\Cryptography\\Defaults\\Provider\\"; > + PWSTR keyname; This is wrong, you need to declare Unicode strings, not typecast ASCII ones. -- Alexandre Julliard julliard(a)winehq.org

1 0

Problems with wizard code in COMCTL32
by Filip Navara 21 Jul '04

21 Jul '04

Hi, I took a quick look at the property sheet code in COMCTL32 in order to get the Mozilla Firefox setup working. The attached patch fixes some of the bugs, but the code is too messy for me to understand and fix the other problems: - Line ~1532. When PSH_USEHBMWATERMARK or PSH_USEHBMHEADER is set, the property sheet header is modified and the watermark/header bitmap is loaded using CreateMappedBitmap and injected into the hbmWatermark/hbmHeader field of the global property sheet info structure. This is done for every page in the property sheet. Since the names and bitmaps are stored as union at the same place in memory, on the second page the bitmap is already loaded and the original name is already lost, but the PSH_USEHBM* flag is still set and so the code tries to load the bitmap again passing the bitmap handle instead of the resource ID. I think the code for loading the watermark and header bitmaps should be moved to some other initialization routine, because AFAIK these bitmaps are identical for the whole wizard and not different on per page basis. - The watermark bitmap is displayed under the "dialog" with the controls on the property sheet. The "dialog" itself isn't transparent and so most of the watermark bitmap isn't visible. I thought that setting the window class background color of the "dialog" with controls would solve that, but it seems that the native version of COMCTL32 (from Windows XP) subclasses it. - Caption of the wizard window is never set. If anyone wants to look at these problems it would be great. Regards, Filip Changelog: - Properly calculate caption length when converting multi-byte string to wide character one. - Wizard contents shouldn't be moved by the size of watermark bitmap. - Fix PSH_WIZARD97_[NEW/OLD] checks. - Blit the watermark even if PSH_USEHBMWATERMARK flag isn't set and blit only the part that fits into the dialog. - Fix CreateMappedBitmap for palette-less bitmaps. Index: comctl32/propsheet.c =================================================================== --- comctl32/propsheet.c (revision 1) +++ comctl32/propsheet.c (working copy) @@ -173,7 +173,7 @@ static BOOL PROPSHEET_RemovePage(HWND hwndDlg, int index, HPROPSHEETPAGE hpage); -static void PROPSHEET_CleanUp(); +static void PROPSHEET_CleanUp(HWND hwndDlg); static int PROPSHEET_GetPageIndex(HPROPSHEETPAGE hpage, PropSheetInfo* psInfo); static void PROPSHEET_SetWizButtons(HWND hwndDlg, DWORD dwFlags); static PADDING_INFO PROPSHEET_GetPaddingInfoWizard(HWND hwndDlg, const PropSheetInfo* psInfo); @@ -308,10 +308,9 @@ { if (HIWORD(lppsh->pszCaption)) { - int len = strlen(lppsh->pszCaption); + int len = MultiByteToWideChar(CP_ACP, 0, lppsh->pszCaption, -1, NULL, 0); psInfo->ppshheader.pszCaption = HeapAlloc( GetProcessHeap(), 0, (len+1)*sizeof (WCHAR) ); MultiByteToWideChar(CP_ACP, 0, lppsh->pszCaption, -1, (LPWSTR) psInfo->ppshheader.pszCaption, len+1); - /* strcpy( (char *)psInfo->ppshheader.pszCaption, lppsh->pszCaption ); */ } } psInfo->nPages = lppsh->nPages; @@ -361,7 +360,7 @@ psInfo->ppshheader.pszCaption = NULL; else { - if (!(lppsh->dwFlags & INTRNL_ANY_WIZARD) && HIWORD(lppsh->pszCaption)) + if (HIWORD(lppsh->pszCaption)) { int len = strlenW(lppsh->pszCaption); psInfo->ppshheader.pszCaption = HeapAlloc( GetProcessHeap(), 0, (len+1)*sizeof(WCHAR) ); @@ -1511,7 +1510,6 @@ psInfo->proppage[index].hwndPage = hwndPage; if (psInfo->ppshheader.dwFlags & INTRNL_ANY_WIZARD) { - int offsetx = 0; int offsety = 0; HWND hwndChild; RECT r; @@ -1532,11 +1530,10 @@ pageWidth, pageHeight, padding.x, padding.y); /* If there is a watermark, offset the dialog items */ - if ( (psInfo->ppshheader.dwFlags & (PSH_WATERMARK | PSH_WIZARD97_NEW | PSH_WIZARD97_OLD)) && + if ( (psInfo->ppshheader.dwFlags & (PSH_WIZARD97_NEW | PSH_WIZARD97_OLD)) && + (psInfo->ppshheader.dwFlags & PSH_WATERMARK) && ((index == 0) || (index == psInfo->nPages - 1)) ) { - BITMAP bm; - /* if PSH_USEHBMWATERMARK is not set, load the resource from pszbmWatermark and put the HBITMAP in hbmWatermark. Thus all the rest of the code always considers hbmWatermark as valid. */ @@ -1545,13 +1542,10 @@ ((PropSheetInfo *)psInfo)->ppshheader.u4.hbmWatermark = CreateMappedBitmap(ppshpage->hInstance, (INT)psInfo->ppshheader.u4.pszbmWatermark, 0, NULL, 0); } - - /* Compute the offset x */ - GetObjectA(psInfo->ppshheader.u4.hbmWatermark, sizeof(BITMAP), (LPVOID)&bm); - offsetx = bm.bmWidth; } - if (psInfo->ppshheader.dwFlags & (PSH_HEADER | PSH_WIZARD97_NEW | PSH_WIZARD97_OLD)) + if (psInfo->ppshheader.dwFlags & (PSH_WIZARD97_NEW | PSH_WIZARD97_OLD) && + psInfo->ppshheader.dwFlags & PSH_HEADER) { /* Same behavior as for watermarks */ if (!(psInfo->ppshheader.dwFlags & PSH_USEHBMHEADER)) @@ -1567,21 +1561,10 @@ offsety = (ppshpage->dwFlags & PSP_HIDEHEADER)?0:r.bottom + 1; } - hwndChild = GetWindow(hwndPage, GW_CHILD); - while((offsetx!=0) && (hwndChild)) { - GetWindowRect(hwndChild, &r); - MapWindowPoints(0, hwndPage, (LPPOINT)&r, 2); - OffsetRect(&r, -offsetx, 0); - SetWindowPos(hwndChild, 0, r.left, r.top, - 0, 0, SWP_NOSIZE | SWP_NOZORDER); - - hwndChild = GetWindow(hwndChild, GW_HWNDNEXT); - } - SetWindowPos(hwndPage, HWND_TOP, - rc.left + padding.x/2 + offsetx, + rc.left + padding.x/2, rc.top + padding.y/2 + offsety, - pageWidth - offsetx, pageHeight - offsety, 0); + pageWidth, pageHeight - offsety, 0); } else { /* @@ -2926,7 +2909,8 @@ hOldPal = SelectPalette(hdc, psInfo->ppshheader.hplWatermark, FALSE); if ( (!(ppshpage->dwFlags & PSP_HIDEHEADER)) && - (psInfo->ppshheader.dwFlags & (PSH_WIZARD97_NEW | PSH_HEADER)) ) + (psInfo->ppshheader.dwFlags & (PSH_WIZARD97_OLD | PSH_WIZARD97_NEW)) && + (psInfo->ppshheader.dwFlags & PSH_HEADER) ) { RECT rzone; HWND hwndLineHeader = GetDlgItem(hwnd, IDC_SUNKEN_LINEHEADER); @@ -2982,35 +2966,33 @@ } if ( ((psInfo->active_page == 0) || (psInfo->active_page == psInfo->nPages - 1)) && - (psInfo->ppshheader.dwFlags & (PSH_WIZARD97_NEW | PSH_WATERMARK)) ) + (psInfo->ppshheader.dwFlags & (PSH_WIZARD97_OLD | PSH_WIZARD97_NEW)) && + (psInfo->ppshheader.dwFlags & PSH_WATERMARK) ) { - if (psInfo->ppshheader.dwFlags & PSH_USEHBMWATERMARK ) - { - HWND hwndLine = GetDlgItem(hwnd, IDC_SUNKEN_LINE); + HWND hwndLine = GetDlgItem(hwnd, IDC_SUNKEN_LINE); - GetClientRect(hwndLine, &r); - MapWindowPoints(hwndLine, hwnd, (LPPOINT) &r, 2); + GetClientRect(hwndLine, &r); + MapWindowPoints(hwndLine, hwnd, (LPPOINT) &r, 2); - GetObjectA(psInfo->ppshheader.u4.hbmWatermark, sizeof(BITMAP), (LPVOID)&bm); - hbmp = SelectObject(hdcSrc, psInfo->ppshheader.u4.hbmWatermark); + GetObjectA(psInfo->ppshheader.u4.hbmWatermark, sizeof(BITMAP), (LPVOID)&bm); + hbmp = SelectObject(hdcSrc, psInfo->ppshheader.u4.hbmWatermark); - BitBlt(hdc, 0, offsety, bm.bmWidth, bm.bmHeight, - hdcSrc, 0, 0, SRCCOPY); + BitBlt(hdc, 0, offsety, min(bm.bmWidth, r.right), + min(bm.bmHeight, r.bottom), hdcSrc, 0, 0, SRCCOPY); - /* If the bitmap is not big enough, fill the remaining area - with the color of pixel (0,0) of bitmap - see MSDN */ - if (r.top > bm.bmHeight) { - r.bottom = r.top - 1; - r.top = bm.bmHeight; - r.left = 0; - r.right = bm.bmWidth; - hbr = CreateSolidBrush(GetPixel(hdcSrc, 0, 0)); - FillRect(hdc, &r, hbr); - DeleteObject(hbr); - } - - SelectObject(hdcSrc, hbmp); + /* If the bitmap is not big enough, fill the remaining area + with the color of pixel (0,0) of bitmap - see MSDN */ + if (r.top > bm.bmHeight) { + r.bottom = r.top - 1; + r.top = bm.bmHeight; + r.left = 0; + r.right = bm.bmWidth; + hbr = CreateSolidBrush(GetPixel(hdcSrc, 0, 0)); + FillRect(hdc, &r, hbr); + DeleteObject(hbr); } + + SelectObject(hdcSrc, hbmp); } if (psInfo->ppshheader.dwFlags & PSH_USEHPLWATERMARK) Index: comctl32/commctrl.c =================================================================== --- comctl32/commctrl.c (revision 1) +++ comctl32/commctrl.c (working copy) @@ -862,7 +862,12 @@ if (lpBitmap == NULL) return 0; - nColorTableSize = (1 << lpBitmap->biBitCount); + if (lpBitmap->biSize >= sizeof(BITMAPINFOHEADER) && lpBitmap->biClrUsed) + nColorTableSize = lpBitmap->biClrUsed; + else if (lpBitmap->biBitCount <= 8) + nColorTableSize = (1 << lpBitmap->biBitCount); + else + nColorTableSize = 0; nSize = lpBitmap->biSize + nColorTableSize * sizeof(RGBQUAD); lpBitmapInfo = (LPBITMAPINFOHEADER)GlobalAlloc (GMEM_FIXED, nSize); if (lpBitmapInfo == NULL) @@ -899,7 +904,7 @@ HDC hdcDst = CreateCompatibleDC (hdcScreen); HBITMAP hbmOld = SelectObject (hdcDst, hbm); LPBYTE lpBits = (LPBYTE)(lpBitmap + 1); - lpBits += (1 << (lpBitmapInfo->biBitCount)) * sizeof(RGBQUAD); + lpBits += nColorTableSize * sizeof(RGBQUAD); StretchDIBits (hdcDst, 0, 0, nWidth, nHeight, 0, 0, nWidth, nHeight, lpBits, (LPBITMAPINFO)lpBitmapInfo, DIB_RGB_COLORS, SRCCOPY);

1 0

RFC: API db
by David Miller 21 Jul '04

21 Jul '04

Hello, This is a request for comments relating to the API database at http://winedb.pavely.net. The backend database has been redesigned to improve database performance and produce more accurate results. It currently contains import/export and ordinal data for various windows versions as well as WINE. What I would like is some feedback from the WINE development community about what you would like to see in a front-end to the database. This could range from suggestions on presenting data in an easy-to-understand manner to adding additional data to the database. Current suggestions include the following: 1. Cross reference and compare windows versions and dll versions 2. List exports and imports for a given dll 3. create dependency tree for dlls 4. Determine which APIs are used by specific applications 5. Determine most used / least used APIs and dlls (pinpoint what functionality is important for many apps) 6. Compare ordinals across windows versions (helps determine when WINE should / should not export by ordinal)

2 1

Valgrind/Wine
by Zach Gorman 21 Jul '04

21 Jul '04

The latest build of valgrind that supports wine is now 8 months stale, and it doesn't seem to work on the wine head. Adam Gundy did some great work on this, and it would be a shame to see it go to waste. Is anyone out there able to pick up the torch on this? Zach

1 0

MFC and RtlpWaitForCriticalSection
by jake＠mail.nnov.ru 21 Jul '04

21 Jul '04

Hello, I.m trying to compile MFC with Winelib. I switched off some code in MFC ( richedit, oledb etc ) and have it a draft version compiled/linked but when trying to use it in a simple console or GUI app I have a .err: ntdll:RtlpWaitForCriticalSection section 0x78034120 "?" wait timed out in thread... message on start and the app hangs. Wine ( 04-2004 ) displays this message on LoadLibrary(MFC) in a generated wrapper code. I also compiled the similar .truncated. MFC version on win32 and all works ok there, at least for my simple apps. I.d really appreciate any hints how to debug it and why it may happen. Thanks -- Eugene

1 0

Fix DirectSound's primary buffer Volume and Pan handling
by Francois Gouget 21 Jul '04

21 Jul '04

Currently the way DirectSound handles Volume and Pan is wrong: * whenever a primary buffer is created (e.g. in DirectSoundCreate()) we initialize an internal variable that sets the volume to the max and pan to the center. * we also call IDsDriverBuffer_SetVolumePan() or waveOutSetVolume() to set the system volume to that value. On my machine this has the same effect as amixer set PCM 100% * we ignore changes in the volume or balance made outside of DirectSound. So if the user does: amixer set PCM 50% And then the application calls GetVolume() it will still get 0 (i.e. max volume) This is not what happens on Windows. On Windows primary buffers don't have their internal volume. Instead SetVolume()/SetPan() and GetVolume()/GetPan() query directly the underlying volume. I hacked the dsound.c test to verify this. Basically, now it does the following: * it calls GetVolume() and GetPan() and prints the results * it sleeps for 20 seconds * during these 20 seconds, start Windows' mixer control, and change the 'Wave Sound' (translated from French) volume and/or balance. * the test then calls GetVolume() and GetPan() and prints the results again Running the test we can see that the second time DierctSound returns the new volume: dsound.c:771:Primary volume=-566 pan=0 dsound.c:776:Primary volume=-566 pan=0 --- the test sleeps here while we change the volume --- dsound.c:782:Primary volume=-1438 pan=0 I attached the dsound.c test patch so this can be cross-checked. You will note that I also played with the secondary buffers to check the effect changing the volume on a secondary buffer would have on the system volume: it has none but Wine already does the right thing (a bit surprisingly). (for secondary buffers SetVolume() has a call to IDsDriverBuffer_SetVolumePan() but that branch is not taken so we do a DSOUND_ForceRemix() instead. I'm not sure if we should ever go through this IDsDriverBuffer_SetVolumePan() branch) I also patched DirectSound to fix the problem. The one thing that bothers me is that I did not find the equivalent of an IDsDriverBuffer_GetVolumePan(). I.e. we can use the driver to set the volume but not to query it. That's pretty strange. I wonder how DirectSound gets the system volume on Windows. In Wine what I did is simply use waveOutGetVolume() on dsound->hwo. Then I pass this through DSOUND_AmpFactorToVolPan() to convert these 'AmpFactors' into the regular Vol/Pan used by DirectSound. Comment and improvement suggestions welcome. If nobody objects I'll submit this to wine-patches tomorrow. -- Francois Gouget fgouget(a)codeweavers.com Index: dlls/dsound/tests/dsound.c =================================================================== RCS file: /var/cvs/wine/dlls/dsound/tests/dsound.c,v retrieving revision 1.30 diff -u -r1.30 dsound.c --- dlls/dsound/tests/dsound.c 21 Jul 2004 03:23:13 -0000 1.30 +++ dlls/dsound/tests/dsound.c 21 Jul 2004 12:27:48 -0000 @@ -745,11 +745,11 @@ primary=NULL; ZeroMemory(&bufdesc, sizeof(bufdesc)); bufdesc.dwSize=sizeof(bufdesc); - bufdesc.dwFlags=DSBCAPS_PRIMARYBUFFER|DSBCAPS_CTRLVOLUME; + bufdesc.dwFlags=DSBCAPS_PRIMARYBUFFER|DSBCAPS_CTRLVOLUME|DSBCAPS_CTRLPAN; rc=IDirectSound_CreateSoundBuffer(dso,&bufdesc,&primary,NULL); ok(rc==DS_OK && primary!=NULL,"CreateSoundBuffer failed to create a primary buffer: 0x%lx\n",rc); if (rc==DS_OK && primary!=NULL) { - LONG vol; + LONG vol,pan; /* Try to create a second primary buffer */ /* DSOUND: Error: The primary buffer already exists. Any changes made to the buffer description will be ignored. */ @@ -765,7 +765,21 @@ ok(rc!=DS_OK,"IDirectSound_DuplicateSoundBuffer primary buffer should have failed 0x%lx\n",rc); rc=IDirectSoundBuffer_GetVolume(primary,&vol); - ok(rc==DS_OK,"GetVolume failed: 0x%lx\n",rc); + ok(rc==DS_OK,"Primary GetVolume failed: %s\n",DXGetErrorString9(rc)); + rc=IDirectSoundBuffer_GetPan(primary,&pan); + ok(rc==DS_OK,"Primary GetPan failed: %s\n",DXGetErrorString9(rc)); + trace("Primary volume=%ld pan=%ld\n",vol,pan); + rc=IDirectSoundBuffer_SetVolume(primary,vol); + ok(rc==DS_OK,"Primary SetVolume failed: %s\n",DXGetErrorString9(rc)); + rc=IDirectSoundBuffer_SetPan(primary,pan); + ok(rc==DS_OK,"Primary SetPan failed: %s\n",DXGetErrorString9(rc)); + trace("Primary volume=%ld pan=%ld\n",vol,pan); + Sleep(20000); + rc=IDirectSoundBuffer_GetVolume(primary,&vol); + ok(rc==DS_OK,"Primary GetVolume failed: %s\n",DXGetErrorString9(rc)); + rc=IDirectSoundBuffer_GetPan(primary,&pan); + ok(rc==DS_OK,"Primary GetPan failed: %s\n",DXGetErrorString9(rc)); + trace("Primary volume=%ld pan=%ld\n",vol,pan); if (winetest_interactive) { @@ -828,7 +842,7 @@ ZeroMemory(&bufdesc, sizeof(bufdesc)); bufdesc.dwSize=sizeof(bufdesc); - bufdesc.dwFlags=DSBCAPS_PRIMARYBUFFER; + bufdesc.dwFlags=DSBCAPS_PRIMARYBUFFER|DSBCAPS_CTRLVOLUME|DSBCAPS_CTRLPAN; rc=IDirectSound_CreateSoundBuffer(dso,&bufdesc,&primary,NULL); ok(rc==DS_OK && primary!=NULL,"CreateSoundBuffer failed to create a primary buffer 0x%lx\n", rc); @@ -838,7 +852,7 @@ secondary=NULL; ZeroMemory(&bufdesc, sizeof(bufdesc)); bufdesc.dwSize=sizeof(bufdesc); - bufdesc.dwFlags=DSBCAPS_GETCURRENTPOSITION2; + bufdesc.dwFlags=DSBCAPS_GETCURRENTPOSITION2|DSBCAPS_CTRLVOLUME|DSBCAPS_CTRLPAN; bufdesc.dwBufferBytes=wfx.nAvgBytesPerSec*BUFFER_LEN/1000; bufdesc.lpwfxFormat=&wfx; trace(" Testing a secondary buffer at %ldx%dx%d\n", @@ -847,6 +861,27 @@ ok(rc==DS_OK && secondary!=NULL,"CreateSoundBuffer failed to create a secondary buffer 0x%lx\n",rc); if (rc==DS_OK && secondary!=NULL) { + LONG vol,pan; + + rc=IDirectSoundBuffer_GetVolume(secondary,&vol); + ok(rc==DS_OK,"GetVolume(secondary) failed: %s\n",DXGetErrorString9(rc)); + rc=IDirectSoundBuffer_GetPan(secondary,&pan); + ok(rc==DS_OK,"GetPan(secondary) failed: %s\n",DXGetErrorString9(rc)); + trace("Secondary volume=%ld pan=%ld\n",vol,pan); + vol=-1800; + rc=IDirectSoundBuffer_SetVolume(secondary,vol); + ok(rc==DS_OK,"SetVolume(secondary) failed: %s\n",DXGetErrorString9(rc)); + rc=IDirectSoundBuffer_GetVolume(secondary,&vol); + ok(rc==DS_OK,"GetVolume(secondary) failed: %s\n",DXGetErrorString9(rc)); + rc=IDirectSoundBuffer_GetPan(secondary,&pan); + ok(rc==DS_OK,"GetPan(secondary) failed: %s\n",DXGetErrorString9(rc)); + trace("Secondary volume=%ld pan=%ld\n",vol,pan); + rc=IDirectSoundBuffer_GetVolume(primary,&vol); + ok(rc==DS_OK,"Primary GetVolume failed: %s\n",DXGetErrorString9(rc)); + rc=IDirectSoundBuffer_GetPan(primary,&pan); + ok(rc==DS_OK,"Primary GetPan failed: %s\n",DXGetErrorString9(rc)); + trace("Primary volume=%ld pan=%ld\n",vol,pan); + test_buffer(dso,secondary,0,FALSE,0,FALSE,0,winetest_interactive,1.0,0,NULL,0,0); ref=IDirectSoundBuffer_Release(secondary); Index: dlls/dsound/dsound.c =================================================================== RCS file: /var/cvs/wine/dlls/dsound/dsound.c,v retrieving revision 1.6 diff -u -r1.6 dsound.c --- dlls/dsound/dsound.c 19 Jul 2004 20:06:22 -0000 1.6 +++ dlls/dsound/dsound.c 21 Jul 2004 09:34:19 -0000 @@ -892,10 +892,6 @@ pDS->drvcaps.dwPrimaryBuffers = 1; } - pDS->volpan.lVolume = 0; - pDS->volpan.lPan = 0; - DSOUND_RecalcVolPan(&(pDS->volpan)); - InitializeCriticalSection(&(pDS->mixlock)); RtlInitializeResource(&(pDS->lock)); Index: dlls/dsound/dsound_private.h =================================================================== RCS file: /var/cvs/wine/dlls/dsound/dsound_private.h,v retrieving revision 1.19 diff -u -r1.19 dsound_private.h --- dlls/dsound/dsound_private.h 21 Jul 2004 03:23:13 -0000 1.19 +++ dlls/dsound/dsound_private.h 21 Jul 2004 12:27:47 -0000 @@ -91,7 +91,6 @@ IDirectSoundBufferImpl** buffers; RTL_RWLOCK lock; CRITICAL_SECTION mixlock; - DSVOLUMEPAN volpan; PrimaryBufferImpl* primary; DSBUFFERDESC dsbd; DWORD speaker_config; @@ -450,6 +449,7 @@ extern IClassFactoryImpl DSOUND_FULLDUPLEX_CF; void DSOUND_RecalcVolPan(PDSVOLUMEPAN volpan); +void DSOUND_AmpFactorToVolPan(PDSVOLUMEPAN volpan); void DSOUND_RecalcFormat(IDirectSoundBufferImpl *dsb); /* primary.c */ Index: dlls/dsound/mixer.c =================================================================== RCS file: /var/cvs/wine/dlls/dsound/mixer.c,v retrieving revision 1.20 diff -u -r1.20 mixer.c --- dlls/dsound/mixer.c 12 Jan 2004 21:02:22 -0000 1.20 +++ dlls/dsound/mixer.c 21 Jul 2004 11:21:55 -0000 @@ -20,6 +20,7 @@ */ #include "config.h" +#define _GNU_SOURCE /* for round() in math.h */ #include <assert.h> #include <stdarg.h> #include <stdio.h> @@ -54,6 +55,7 @@ double temp; TRACE("(%p)\n",volpan); + TRACE("Vol=%ld Pan=%ld\n", volpan->lVolume, volpan->lPan); /* the AmpFactors are expressed in 16.16 fixed point */ volpan->dwVolAmpFactor = (ULONG) (pow(2.0, volpan->lVolume / 600.0) * 0xffff); /* FIXME: dwPan{Left|Right}AmpFactor */ @@ -67,6 +69,39 @@ TRACE("left = %lx, right = %lx\n", volpan->dwTotalLeftAmpFactor, volpan->dwTotalRightAmpFactor); } +void DSOUND_AmpFactorToVolPan(PDSVOLUMEPAN volpan) +{ + double left,right; + TRACE("(%p)\n",volpan); + + TRACE("left=%lx, right=%lx\n",volpan->dwTotalLeftAmpFactor,volpan->dwTotalRightAmpFactor); + if (volpan->dwTotalLeftAmpFactor==0) + left=-10000; + else + left=600 * log(((double)volpan->dwTotalLeftAmpFactor) / 0xffff) / log(2); + if (volpan->dwTotalRightAmpFactor==0) + right=-10000; + else + right=600 * log(((double)volpan->dwTotalRightAmpFactor) / 0xffff) / log(2); + if (left<right) + { + volpan->lVolume=round(right); + volpan->dwVolAmpFactor=volpan->dwTotalRightAmpFactor; + } + else + { + volpan->lVolume=round(left); + volpan->dwVolAmpFactor=volpan->dwTotalLeftAmpFactor; + } + if (volpan->lVolume < -10000) + volpan->lVolume=-10000; + volpan->lPan=round(right-left); + if (volpan->lPan < -10000) + volpan->lPan=-10000; + + TRACE("Vol=%ld Pan=%ld\n", volpan->lVolume, volpan->lPan); +} + void DSOUND_RecalcFormat(IDirectSoundBufferImpl *dsb) { DWORD sw; Index: dlls/dsound/primary.c =================================================================== RCS file: /var/cvs/wine/dlls/dsound/primary.c,v retrieving revision 1.25 diff -u -r1.25 primary.c --- dlls/dsound/primary.c 13 Jul 2004 23:35:09 -0000 1.25 +++ dlls/dsound/primary.c 21 Jul 2004 11:06:06 -0000 @@ -74,8 +74,6 @@ HRESULT err = DS_OK; TRACE("(%p)\n",This); - DSOUND_RecalcVolPan(&(This->volpan)); - /* are we using waveOut stuff? */ if (!This->driver) { LPBYTE newbuf; @@ -135,11 +133,6 @@ } if ((err == DS_OK) && (merr != DS_OK)) err = merr; - - if (!err) { - DWORD vol = (This->volpan.dwTotalLeftAmpFactor & 0xffff) | (This->volpan.dwTotalRightAmpFactor << 16); - err = mmErr(waveOutSetVolume(This->hwo, vol)); - } } else { if (!This->hwbuf) { err = IDsDriver_CreateSoundBuffer(This->driver,&(This->wfx), @@ -154,7 +147,6 @@ if (dsound->state == STATE_PLAYING) dsound->state = STATE_STARTING; else if (dsound->state == STATE_STOPPING) dsound->state = STATE_STOPPED; } - err = IDsDriverBuffer_SetVolumePan(This->hwbuf, &(This->volpan)); } return err; @@ -458,7 +450,8 @@ ) { ICOM_THIS(PrimaryBufferImpl,iface); IDirectSoundImpl* dsound = This->dsound; - LONG oldVol; + DWORD ampfactors; + DSVOLUMEPAN volpan; TRACE("(%p,%ld)\n",This,vol); @@ -475,24 +468,26 @@ /* **** */ EnterCriticalSection(&(dsound->mixlock)); - oldVol = dsound->volpan.lVolume; - dsound->volpan.lVolume = vol; - DSOUND_RecalcVolPan(&dsound->volpan); - - if (vol != oldVol) { - if (dsound->hwbuf) { - HRESULT hres; - hres = IDsDriverBuffer_SetVolumePan(dsound->hwbuf, &(dsound->volpan)); - if (hres != DS_OK) { - LeaveCriticalSection(&(dsound->mixlock)); - WARN("IDsDriverBuffer_SetVolumePan failed\n"); - return hres; - } - } else { - DWORD vol = (dsound->volpan.dwTotalLeftAmpFactor & 0xffff) | (dsound->volpan.dwTotalRightAmpFactor << 16); - waveOutSetVolume(dsound->hwo, vol); - } - } + waveOutGetVolume(dsound->hwo, &ampfactors); + volpan.dwTotalLeftAmpFactor=ampfactors & 0xffff; + volpan.dwTotalRightAmpFactor=ampfactors >> 16; + DSOUND_AmpFactorToVolPan(&volpan); + if (vol != volpan.lVolume) { + volpan.lVolume=vol; + DSOUND_RecalcVolPan(&volpan); + if (dsound->hwbuf) { + HRESULT hres; + hres = IDsDriverBuffer_SetVolumePan(dsound->hwbuf, &volpan); + if (hres != DS_OK) { + LeaveCriticalSection(&(dsound->mixlock)); + WARN("IDsDriverBuffer_SetVolumePan failed\n"); + return hres; + } + } else { + ampfactors = (volpan.dwTotalLeftAmpFactor & 0xffff) | (volpan.dwTotalRightAmpFactor << 16); + waveOutSetVolume(dsound->hwo, ampfactors); + } + } LeaveCriticalSection(&(dsound->mixlock)); /* **** */ @@ -504,6 +499,8 @@ LPDIRECTSOUNDBUFFER8 iface,LPLONG vol ) { ICOM_THIS(PrimaryBufferImpl,iface); + DWORD ampfactors; + DSVOLUMEPAN volpan; TRACE("(%p,%p)\n",This,vol); if (!(This->dsound->dsbd.dwFlags & DSBCAPS_CTRLVOLUME)) { @@ -516,7 +513,11 @@ return DSERR_INVALIDPARAM; } - *vol = This->dsound->volpan.lVolume; + waveOutGetVolume(dsound->hwo, &ampfactors); + volpan.dwTotalLeftAmpFactor=ampfactors & 0xffff; + volpan.dwTotalRightAmpFactor=ampfactors >> 16; + DSOUND_AmpFactorToVolPan(&volpan); + *vol = volpan.lVolume; return DS_OK; } @@ -769,7 +770,8 @@ ) { ICOM_THIS(PrimaryBufferImpl,iface); IDirectSoundImpl* dsound = This->dsound; - LONG oldPan; + DWORD ampfactors; + DSVOLUMEPAN volpan; TRACE("(%p,%ld)\n",This,pan); @@ -786,25 +788,27 @@ /* **** */ EnterCriticalSection(&(dsound->mixlock)); - oldPan = dsound->volpan.lPan; - dsound->volpan.lPan = pan; - DSOUND_RecalcVolPan(&dsound->volpan); - - if (pan != oldPan) { - if (dsound->hwbuf) { - HRESULT hres; - hres = IDsDriverBuffer_SetVolumePan(dsound->hwbuf, &(dsound->volpan)); - if (hres != DS_OK) { - LeaveCriticalSection(&(dsound->mixlock)); - WARN("IDsDriverBuffer_SetVolumePan failed\n"); - return hres; - } - } - else { - DWORD vol = (dsound->volpan.dwTotalLeftAmpFactor & 0xffff) | (dsound->volpan.dwTotalRightAmpFactor << 16); - waveOutSetVolume(dsound->hwo, vol); - } - } + waveOutGetVolume(dsound->hwo, &ampfactors); + volpan.dwTotalLeftAmpFactor=ampfactors & 0xffff; + volpan.dwTotalRightAmpFactor=ampfactors >> 16; + DSOUND_AmpFactorToVolPan(&volpan); + if (pan != volpan.lPan) { + volpan.lPan=pan; + DSOUND_RecalcVolPan(&volpan); + if (dsound->hwbuf) { + HRESULT hres; + hres = IDsDriverBuffer_SetVolumePan(dsound->hwbuf, &volpan); + if (hres != DS_OK) { + LeaveCriticalSection(&(dsound->mixlock)); + WARN("IDsDriverBuffer_SetVolumePan failed\n"); + return hres; + } + } + else { + ampfactors = (volpan.dwTotalLeftAmpFactor & 0xffff) | (volpan.dwTotalRightAmpFactor << 16); + waveOutSetVolume(dsound->hwo, ampfactors); + } + } LeaveCriticalSection(&(dsound->mixlock)); /* **** */ @@ -816,6 +820,8 @@ LPDIRECTSOUNDBUFFER8 iface,LPLONG pan ) { ICOM_THIS(PrimaryBufferImpl,iface); + DWORD ampfactors; + DSVOLUMEPAN volpan; TRACE("(%p,%p)\n",This,pan); if (!(This->dsound->dsbd.dwFlags & DSBCAPS_CTRLPAN)) { @@ -828,8 +834,11 @@ return DSERR_INVALIDPARAM; } - *pan = This->dsound->volpan.lPan; - + waveOutGetVolume(dsound->hwo, &ampfactors); + volpan.dwTotalLeftAmpFactor=ampfactors & 0xffff; + volpan.dwTotalRightAmpFactor=ampfactors >> 16; + DSOUND_AmpFactorToVolPan(&volpan); + *pan = volpan.lPan; return DS_OK; }

1 0

Serial port problem in 200407016
by jeremy＠fantasticfamily.net 21 Jul '04

21 Jul '04

I seem to be having trouble communicating with my serial device. I have a Garming Rino GPS connected on /dev/ttyS0 using Mandrake 10.0, wine build 200407016. I read on 6/14/04 that some serial port issues were solved. permissons on /dev/ttyS0 are set correct and I've used setserial to make the baud rate 9600. In MapSource v2.01, I've set it to com1, 9600 as well. The program runs great under wine, but the is the error I get when I try to transfer maps to the unit (from WINEDEBUG=+comm,+file, +ntdll): <clip> trace:file:GetOverlappedResult (0x6c 0x406cee6c 0x406cdfe0 0) trace:comm:ClearCommError handle 0x6c cbInQue = 0 cbOutQue = 0 trace:file:CreateFileW L"C:\\windows\\win.ini" GENERIC_READ FILE_SHARE_READ attributes 0x80 trace:file:RtlDosPathNameToNtPathName_U (L"C:\\windows\\win.ini",0x406cade8,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"C:\\windows\\win.ini" 520 0x406cab68 (nil)) trace:ntdll:NtCreateFile handle=0x406caddc access=80000000 name=L"\\??\\C:\\windows\\win.ini" objattr=00000040 root=(nil) sec=(nil) io=0x406cade0 alloc_size=(nil) attr=00000080 sharing=00000001 disp=1 options=00000050 ea=(nil).0x00000000 trace:file:wine_nt_to_unix_file_name L"\\??\\C:\\windows\\win.ini" -> "/root/.wine/dosdevices/c:/windows/win.ini" trace:file:CreateFileW returning 0x64 trace:ntdll:NtQueryInformationFile (0x64,0x406cadd8,0x406cade0,0x00000024,0x00000004) trace:file:CreateFileW L"C:\\windows\\win.ini" GENERIC_READ FILE_SHARE_READ OPEN_EXISTING attributes 0x80 trace:file:RtlDosPathNameToNtPathName_U (L"C:\\windows\\win.ini",0x406cad7c,(nil),(nil)) trace:file:RtlGetFullPathName_U (L"C:\\windows\\win.ini" 520 0x406caafc (nil)) trace:ntdll:NtCreateFile handle=0x406cad70 access=80000000 name=L"\\??\\C:\\windows\\win.ini" objattr=00000040 root=(nil) sec=(nil) io=0x406cad74 alloc_size=(nil) </clip> Any Ideas? If you need more output from debug, I'd be happy to get it. Thanks in advance! Jeremy

2 1

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