wine-devel November 2004

wine-devel@winehq.org

141 participants
248 discussions

[rsaenh] compilation problem
by Fabrice Ménard 09 Nov '04

09 Nov '04

Hi, I'd like to know wich version of openssl is used for rsaenh.dll. With openssl 0.9.6g, I can't compile rsaenh because of name clashs. For example where "DES_*" is used I've got "des_*"equivalent. Moreover, I don't have for example RSAPrivateKey_dup. If it's really a version problem, I think we should check that with autoconf. regards, -- Fabrice Ménard menard.fabrice(a)wanadoo.fr

2 1

Miscellaneous UI Fixes
by William Poetra Yoga H 09 Nov '04

09 Nov '04

OK, this is the first time I'm sending a patch as plaintext (I figured out I have to use .txt as the extension, otherwise it's sent as a normal attachment). I don't know if this method of sending works correctly so please try it and let me know. This patch fixes a number of things: 1. System menu icon (fix size and position) 2. Caption buttons (fix size and position) 3. Window caption (fix bounding rectangle) 4. Menu bar (fix size) 5. Popup menu (fix distance) By the way, I have this kind of code in my patch (I wrote this code, the original one doesn't look like this): rect.right -= (GetSystemMetrics(SM_CXSIZE) - 2) + 2; Is it OK to write so? What I mean by the code is, the size of the button is (GetSystemMetrics(SM_CXSIZE) - 2), and there's a 2-pixel space to the right of the button. Or should I just write: rect.right -= GetSystemMetrics(SM_CXSIZE); Which doesn't deliver the message clearly but is simpler. I have tested the patch against theForger's tutorial (I compared the screenshots to the actual apps running on my machine) and it doesn't generate new errors, although some things aren't fixed yet: 1. Popup menu items are still a bit (one pixel) taller than those in Windows. For this one I think I really need help. 2. Caption buttons' captions are still the old ones. I'll try to fix these after this patch is committed. 3. Caption bar is still single-color. I'll fix this after this patch, because it will intersect with this patch and possibly make an unclean patch, in the end the two gets messy and never gets committed. I haven't sent this to wine-patches yet. How should I do it? I mean, should I send it all at once (the two files), or one file per message, or one file per item (of the 5 items fixed, above)? I'm not sure (I've read the docs). Reasons for sending the patch: 1. all at once: the patches are a group of related fixes (as said in the website). 2. one file per message: I don't know :-P 3. one file per item: it's one fix per patch (as said in the website) I prefer #1, but is it OK actually? Comments, Alexandre? Guys? Gals? __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com Index: dlls/user/menu.c =================================================================== RCS file: /home/wine/wine/dlls/user/menu.c,v retrieving revision 1.7 diff -u -r1.7 menu.c --- dlls/user/menu.c 19 Oct 2004 21:10:17 -0000 1.7 +++ dlls/user/menu.c 7 Nov 2004 04:47:47 -0000 @@ -978,7 +978,7 @@ { lpitem = &lppop->items[start]; orgX = maxX; - orgY = 2; + orgY = 3; maxTab = maxTabWidth = 0; @@ -1043,7 +1043,7 @@ lprect->left, lprect->top, lprect->right, lprect->bottom); lppop->Width = lprect->right - lprect->left; lppop->Height = 0; - maxY = lprect->top+1; + maxY = lprect->top; start = 0; helpPos = -1; while (start < lppop->nItems) @@ -1077,7 +1077,7 @@ while (start < i) lppop->items[start++].rect.bottom = maxY; } - lprect->bottom = maxY; + lprect->bottom = maxY + 1; lppop->Height = lprect->bottom - lprect->top; /* Flush right all items between the MF_RIGHTJUSTIFY and */ @@ -1431,7 +1431,7 @@ lppop = MENU_GetMenu( hMenu ); if (lppop == NULL || lprect == NULL) { - return GetSystemMetrics(SM_CYMENU); + return GetSystemMetrics(SM_CYMENU) + 1; } if (suppress_draw) @@ -1441,8 +1441,6 @@ if (lppop->Height == 0) MENU_MenuBarCalcSize(hDC, lprect, lppop, hwnd); - lprect->bottom = lprect->top + lppop->Height; - if (hfontOld) SelectObject( hDC, hfontOld); return lppop->Height; } @@ -3765,7 +3763,7 @@ lppop = MENU_GetMenu( hMenu ); if (lppop == NULL || lprect == NULL) { - retvalue = GetSystemMetrics(SM_CYMENU); + retvalue = GetSystemMetrics(SM_CYMENU) + 1; goto END; } @@ -3776,17 +3774,17 @@ if (lppop->Height == 0) MENU_MenuBarCalcSize(hDC, lprect, lppop, hwnd); - lprect->bottom = lprect->top + lppop->Height; - FillRect(hDC, lprect, GetSysColorBrush(COLOR_MENU) ); +#if 0 SelectObject( hDC, SYSCOLOR_GetPen(COLOR_3DFACE)); MoveToEx( hDC, lprect->left, lprect->bottom, NULL ); LineTo( hDC, lprect->right, lprect->bottom ); +#endif if (lppop->nItems == 0) { - retvalue = GetSystemMetrics(SM_CYMENU); + retvalue = GetSystemMetrics(SM_CYMENU) + 1; goto END; } Index: windows/nonclient.c =================================================================== RCS file: /home/wine/wine/windows/nonclient.c,v retrieving revision 1.126 diff -u -r1.126 nonclient.c --- windows/nonclient.c 19 Oct 2004 22:54:24 -0000 1.126 +++ windows/nonclient.c 7 Nov 2004 04:56:16 -0000 @@ -400,7 +400,7 @@ winRect->top += MENU_GetMenuBarHeight( hwnd, winRect->right - winRect->left, - -tmpRect.left, -tmpRect.top ) + 1; + -tmpRect.left, -tmpRect.top ); } SetRect(&tmpRect, 0, 0, 0, 0); @@ -655,9 +655,9 @@ { RECT rect; NC_GetInsideRect( hwnd, &rect ); - DrawIconEx (hdc, rect.left + 1, rect.top + 1, hIcon, - GetSystemMetrics(SM_CXSIZE) - 1, - GetSystemMetrics(SM_CYSIZE) - 1, 0, 0, DI_NORMAL); + DrawIconEx (hdc, rect.left + 2, rect.top + 1, hIcon, + GetSystemMetrics(SM_CXSMICON), + GetSystemMetrics(SM_CYSMICON), 0, 0, DI_NORMAL); } return (hIcon != 0); } @@ -682,21 +682,21 @@ /* A tool window has a smaller Close button */ if (GetWindowLongA( hwnd, GWL_EXSTYLE ) & WS_EX_TOOLWINDOW) { - INT iBmpHeight = 11; /* Windows does not use SM_CXSMSIZE and SM_CYSMSIZE */ - INT iBmpWidth = 11; /* it uses 11x11 for the close button in tool window */ - INT iCaptionHeight = GetSystemMetrics(SM_CYSMCAPTION); + INT iCaptionHeight = GetSystemMetrics(SM_CYSMCAPTION) - 1; + INT iBmpHeight = iCaptionHeight - 4; + INT iBmpWidth = iCaptionHeight - 5; - rect.top = rect.top + (iCaptionHeight - 1 - iBmpHeight) / 2; - rect.left = rect.right - (iCaptionHeight + 1 + iBmpWidth) / 2; + rect.top += 2; + rect.right -= 2; rect.bottom = rect.top + iBmpHeight; - rect.right = rect.left + iBmpWidth; + rect.left = rect.right - iBmpWidth; } else { - rect.left = rect.right - GetSystemMetrics(SM_CXSIZE) - 1; - rect.bottom = rect.top + GetSystemMetrics(SM_CYSIZE) - 1; rect.top += 2; rect.right -= 2; + rect.bottom = rect.top + (GetSystemMetrics(SM_CYSIZE) - 4); + rect.left = rect.right - (GetSystemMetrics(SM_CXSIZE) - 2); } DrawFrameControl( hdc, &rect, DFC_CAPTION, (DFCS_CAPTIONCLOSE | @@ -722,12 +722,12 @@ flags = IsZoomed(hwnd) ? DFCS_CAPTIONRESTORE : DFCS_CAPTIONMAX; NC_GetInsideRect( hwnd, &rect ); - if (GetWindowLongA( hwnd, GWL_STYLE) & WS_SYSMENU) - rect.right -= GetSystemMetrics(SM_CXSIZE) + 1; - rect.left = rect.right - GetSystemMetrics(SM_CXSIZE); - rect.bottom = rect.top + GetSystemMetrics(SM_CYSIZE) - 1; rect.top += 2; + if (GetWindowLongA( hwnd, GWL_STYLE) & WS_SYSMENU) + rect.right -= (GetSystemMetrics(SM_CXSIZE) - 2) + 2; rect.right -= 2; + rect.bottom = rect.top + (GetSystemMetrics(SM_CYSIZE) - 4); + rect.left = rect.right - (GetSystemMetrics(SM_CXSIZE) - 2); if (down) flags |= DFCS_PUSHED; if (bGrayed) flags |= DFCS_INACTIVE; DrawFrameControl( hdc, &rect, DFC_CAPTION, flags ); @@ -750,14 +750,14 @@ return; NC_GetInsideRect( hwnd, &rect ); + rect.top += 2; if (style & WS_SYSMENU) - rect.right -= GetSystemMetrics(SM_CXSIZE) + 1; + rect.right -= (GetSystemMetrics(SM_CXSIZE) - 2) + 2; + rect.right -= 2; if (style & (WS_MAXIMIZEBOX|WS_MINIMIZEBOX)) rect.right -= GetSystemMetrics(SM_CXSIZE) - 2; - rect.left = rect.right - GetSystemMetrics(SM_CXSIZE); - rect.bottom = rect.top + GetSystemMetrics(SM_CYSIZE) - 1; - rect.top += 2; - rect.right -= 2; + rect.left = rect.right - (GetSystemMetrics(SM_CXSIZE) - 2); + rect.bottom = rect.top + (GetSystemMetrics(SM_CYSIZE) - 4); if (down) flags |= DFCS_PUSHED; if (bGrayed) flags |= DFCS_INACTIVE; DrawFrameControl( hdc, &rect, DFC_CAPTION, flags ); @@ -871,7 +871,7 @@ if ((style & WS_SYSMENU) && !(exStyle & WS_EX_TOOLWINDOW)) { if (NC_DrawSysButton (hwnd, hdc, FALSE)) - r.left += GetSystemMetrics(SM_CYCAPTION) - 1; + r.left += GetSystemMetrics(SM_CXSMICON) + 2; } if (style & WS_SYSMENU) @@ -885,18 +885,22 @@ /* Draw a grayed close button if disabled and a normal one if SC_CLOSE is not there */ NC_DrawCloseButton (hwnd, hdc, FALSE, ((((state & MF_DISABLED) || (state & MF_GRAYED))) && (state != 0xFFFFFFFF))); - r.right -= GetSystemMetrics(SM_CYCAPTION) - 1; + r.right -= (GetSystemMetrics(SM_CXSIZE) - 2) + 2; if ((style & WS_MAXIMIZEBOX) || (style & WS_MINIMIZEBOX)) { + /* There's a 2-pixel space between Maximize and Close buttons */ + + r.right -= 2; + /* In win95 the two buttons are always there */ /* But if the menu item is not in the menu they're disabled*/ NC_DrawMaxButton( hwnd, hdc, FALSE, (!(style & WS_MAXIMIZEBOX))); - r.right -= GetSystemMetrics(SM_CXSIZE) + 1; + r.right -= GetSystemMetrics(SM_CXSIZE) - 2; NC_DrawMinButton( hwnd, hdc, FALSE, (!(style & WS_MINIMIZEBOX))); - r.right -= GetSystemMetrics(SM_CXSIZE) + 1; + r.right -= GetSystemMetrics(SM_CXSIZE) - 2; } } @@ -915,6 +919,7 @@ else SetTextColor( hdc, GetSysColor( COLOR_INACTIVECAPTIONTEXT ) ); SetBkMode( hdc, TRANSPARENT ); r.left += 2; + r.right -= 2; DrawTextW( hdc, buffer, -1, &r, DT_SINGLELINE | DT_VCENTER | DT_NOPREFIX | DT_LEFT ); DeleteObject (SelectObject (hdc, hOldFont)); @@ -1010,12 +1015,12 @@ { RECT r = rect; if (dwExStyle & WS_EX_TOOLWINDOW) { - r.bottom = rect.top + GetSystemMetrics(SM_CYSMCAPTION); rect.top += GetSystemMetrics(SM_CYSMCAPTION); + r.bottom = rect.top; } else { - r.bottom = rect.top + GetSystemMetrics(SM_CYCAPTION); rect.top += GetSystemMetrics(SM_CYCAPTION); + r.bottom = rect.top; } if( !clip || IntersectRect( &rfuzz, &r, &rectClip ) ) NC_DrawCaption(hdc, &r, hwnd, dwStyle, dwExStyle, active); @@ -1029,7 +1034,7 @@ TRACE("Calling DrawMenuBar with rect (%ld, %ld)-(%ld, %ld)\n", r.left, r.top, r.right, r.bottom); - rect.top += MENU_DrawMenuBar( hdc, &r, hwnd, suppress_menupaint ) + 1; + rect.top += MENU_DrawMenuBar( hdc, &r, hwnd, suppress_menupaint ); } TRACE("After MenuBar, rect is (%ld, %ld)-(%ld, %ld).\n",

5 8

Re: [shellpath.c] Taking into account the profile value set in wine config file
by Juan Lang 09 Nov '04

09 Nov '04

You've exposed some softness in my thinking in this patch. Like I mentioned in the comments for it, _SHExpandEnvironmentVariables exists because the environment isn't actually set up during wine install time. I didn't think to look up the values in the registry. I also didn't register some of the "environment" variables that I use, and probably should have. You might rewrite it just to look at the registry. You probably want to look in HKLM\System\Current Control Set\Session Manager\Environment if the value you're looking for isn't in HKCU, and some variables should probably not be overridable in HKCU either (SystemRoot, for example). --Juan __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com

3 5

Re: [Fwd: Re: dlls/winmm/tests/capture.c - yes, we can open a device in 2MHz...]
by Robert Reif 09 Nov '04

09 Nov '04

> > > How about this? > > > > regards, > Jakob > How about starting a blacklist framework. You could have a table with the function that fails and some caps info that identifies the driver. I would suspect that there is more than one buggy driver out there. You could then just add it's info to the table when it is found. You could then do: if (!inBlacklist(WAVE_IN_OPEN, &capsA)) { // do the test ... } else trace("blacklisted ..... \n"); There are modems that do strange things and the Remote Desktop Protocol driver and other third party sound rerouting pseudo drivers also do strange things. These will need to be added someday also. This could become a real maintenance nightmare if not done properly from the start.

2 1

Blocking automatic debugger launch
by Kenneth Porter 09 Nov '04

09 Nov '04

I've got an app that seems to be crashing during shutdown. (Tribes Vengeance dedicated server) I'm running it detached inside a screen session, and I don't want the debugger to automatically launch when the app crashes. I just want the thing to die when I send it a "quit" command. Currently I've hacked the registry setting and changed the debugger name to "true". Is there a cleaner way to accomplish this?

4 4

Re: dlls/winmm/tests/capture.c - yes, we can open a device in 2MHz...
by Robert Reif 09 Nov '04

09 Nov '04

Jakob Eriksson wrote: > > > As shown by: > http://test.winehq.org/data/200411021000/2000_IDWASEMPTY_1/winmm:capture.txt > > > capture.c:571:found 1 WaveIn devices > capture.c:302: 0: "Avance AC'97 Audio" > (\\?\pci#ven_1106&dev_3059&subsys_00000000&rev_10#3&61aaa01&0&8d#{6994ad04-93ef-11d0-a3cc-00a0c9223196}\wave) > 5.0 (1:101) > capture.c:305: channels=65535 formats=00fff > capture.c:364: Test failed: waveInOpen(0): opening the device with 2 > MHz sample rate should fail: rc=MMSYSERR_NOERROR(The specified > command was carried out.) That's a driver bug.

5 9

Update to flymake patch
by Mike Hearn 08 Nov '04

08 Nov '04

This adds support for the lovely flymake-mode, which compiles C as you write it in the background and highlights errors and warnings. It's an update to the patch I sent in about a year ago. Since then GNU Emacs has changed (in cvs) so I've attached the version of flymake-mode you need to make it all work. Not expecting this to get merged so it goes to wine-devel.

1 0

registry test incorrect for xp
by James Hawkins 08 Nov '04

08 Nov '04

I just completed building the wine conformance tests with Visual Studio .NET. When I ran the advapi32/security tests, there were 28 failures (compiled and tested on XP). The first error I looked at is: registry.c:93: Test failed: data_count set to 24 instead of 7 Looking at registry.c, this test calls RegEnumValue with an output data buffer that is too small, LONG RegEnumValue( HKEY hKey, DWORD dwIndex, LPTSTR lpValueName, LPDWORD lpcValueName, LPDWORD lpReserved, LPDWORD lpType, LPBYTE lpData, LPDWORD lpcbData ); so the lpcbData should contain the required size of the buffer on return. hKey is initialized to HKCU\Software\Wine\Test and dwIndex is 0, so we're reading this: Name: Test1 Type: REG_EXPAND_SZ Data: %LONGSYSTEMVAR%\subdir1 The current test expects RegEnumValue to expand the environment variable %LONGSYSTEMVAR%, leaving nothing since the variable doesn't exist. If this were the case then lpcbData would return the length of 'subdir1' which is 7, which is what the test expects, but testing shows that even though the type is REG_EXPAND_SZ, RegEnumValue does not expand the environment variable, so lpcbData contains the length of %LONGSYSTEMVAR%\subdir1 which is 24, and which is what is returned when called with XP. This is further clarified by msdn docs, "Your application should call ExpandEnvironmentStrings before attempting to read the value of a REG_EXPAND_SZ registry data type." http://msdn.microsoft.com/library/default.asp?url=/library/en-us/apcompat/a… While it never says that RegEnumValue doesn't expand REG_EXPAND_SZ, this evidence shows that this is the case. If anyone has any thoughts on this, please let me know. Otherwise I will be sending a patch that fixes this test and then checking the test in wine to see if our RegEnumValue needs to be fixed as well. -- James Hawkins

1 1

150 test failures. advapi32 test crashes.
by Dan Kegel 08 Nov '04

08 Nov '04

Hey folks, I pulled down sources from CVS this morning, and tried running the regression tests. There are about 150 failures. Here's a summary: $ grep "Test failed" log | sed 's/:.*//' | uniq -c | sort 1 filtergraph.c 1 rsaenh.c 1 shelllink.c 1 shreg.c 2 typelib.c 4 capture.c 4 wave.c 6 dsound8.c 6 dsound.c 7 vartype.c 8 path.c 15 crypt.c 43 metafile.c 51 shellpath.c Is this unusual? How many failures are most people seeing? For what it's worth, this is a Red Hat 9.0 system with two processors, and this was done with no pre-existing .wine directory. Also, there was a crash during the test. Here's that part of the log: ../../../../wine/tools/runtest -q -P wine -M advapi32.dll -T ../../.. -p advapi32_test.exe.so ../../../../wine/dlls/advapi32/tests/crypt.c && touch crypt.ok crypt.c:104: Test failed: -2146893799 crypt.c:117: Test failed: 0/-2146893799 crypt.c:126: Test failed: 0/-2146893801 crypt.c:457: Test failed: expected 234, got -2146893801 crypt.c:464: Test failed: expected 0, got 0 crypt.c:471: Test failed: expected (null), got crypt.c:472: Test failed: expected 0, got 0 crypt.c:491: Test failed: -2146893805 crypt.c:494: Test failed: -2146893805 crypt.c:502: Test failed: expected Microsoft Base Cryptographic Provider v1.0, got crypt.c:503: Test failed: expected 43, got 0 crypt.c:491: Test failed: -2146893805 crypt.c:494: Test failed: -2146893805 crypt.c:502: Test failed: expected Microsoft Base Cryptographic Provider v1.0, got crypt.c:503: Test failed: expected 43, got 0 wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x8dbe4073 in 32-bit code (0x403602e2). In 32 bit mode. Register dump: CS:0023 SS:002b DS:002b ES:002b FS:003b GS:0033 EIP:403602e2 ESP:4073f9d2 EBP:4073fa5e EFLAGS:00010202( - 00 - -RI1) EAX:8dbe4073 EBX:404174c8 ECX:40053500 EDX:401f0b20 ESI:4073fe26 EDI:77f01330 Stack dump: 0x4073f9d2: 00004001 00000000 00000000 d14c0000 0x4073f9e2: 0c884001 13304020 fa3477f0 020f4073 0x4073f9f2: fa340000 a5864073 fa644001 009b4073 0x4073fa02: d8940000 00004002 00000001 6c644008 0x4073fa12: ffff4041 e384ffff fa2c400c 68114073 0x4073fa22: 6c644008 74c84041 fa544041 e3844073 Backtrace: =>1 0x403602e2 INSTR_EmulateInstruction+0xda(rec=0x4073fe26, context=0x4073fb5a) [../../../wine/dlls/kernel/instr.c:449] in kernel32 (0x4073fa5e) 2 0x403a441e vectored_handler+0x5e(ptrs=0x4073fa8e) [../../../wine/dlls/kernel/wowthunk.c:358] in kernel32 (0x4073fa7e) 3 0x4008bf89 call_vectored_handlers+0x5a(rec=0x4073fe26, context=0x4073fb5a) [../../../wine/dlls/ntdll/exception.c:196] in ntdll (0x4073faa2) 4 0x4008c30d EXC_RtlRaiseException+0x239(rec=0x4073fe26, context=0x4073fb5a) [../../../wine/dlls/ntdll/exception.c:252] in ntdll (0x4073fb2a) 5 0x400abe12 raise_segv_exception+0x8b(rec=0x4073fe26, context=0x4073fb5a) [../../../wine/dlls/ntdll/signal_i386.c:888] in ntdll (0x4073fb46) 0x403602e2 INSTR_EmulateInstruction+0xda [../../../wine/dlls/kernel/instr.c:449] in kernel32: movzbl 0x0(%eax),%eax Unable to open file ../../../wine/dlls/kernel/instr.c Modules: Module Address Debug info Name (17 modules) ELF 0x40000000-40016000 Deferred ld-linux.so.2 ELF 0x40017000-40030000 Deferred libwine.so.1 ELF 0x40032000-4003e000 Deferred libnss_files.so.2 ELF 0x40043000-40050000 Deferred libpthread.so.0 ELF 0x40050000-40053000 Deferred libdl.so.2 ELF 0x40054000-400d1000 Stabs ntdll<elf> \-PE 0x40070000-400d1000 \ ntdll ELF 0x400d1000-401c5000 Deferred libwine_unicode.so.1 ELF 0x401c5000-401e7000 Deferred libm.so.6 ELF 0x40300000-40419000 Stabs kernel32<elf> \-PE 0x40330000-40419000 \ kernel32 ELF 0x40621000-4063c000 Deferred advapi32_test<elf> \-PE 0x40630000-4063c000 \ advapi32_test ELF 0x40740000-4077b000 Deferred advapi32<elf> \-PE 0x40750000-4077b000 \ advapi32 ELF 0x42000000-42133000 Deferred libc.so.6 ELF 0x77f00000-77f03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 00000008 (D) Z:\home\dank\demo\build\dlls\advapi32\tests\advapi32_test.exe 00000009 0 <== WineDbg terminated on pid 0x8 -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

5 11

Re: signaling unix threads
by Jukka Heinonen 08 Nov '04

08 Nov '04

Markus Amsler wrote: > There's a fundamental bug in winedos/dosvm. c[1]. SIGUSR2 is sent to the > current process, but it should be sent to the dosvm thread. This causes > various ugly bugs. > I found no way signaling a unix thread, without modifing the wineserver. > I have implemented a thread_kill command in the wineserver, this solves > my problem, but i'm quite sure it won't get applied. > > I'm really not a wineserver/threading expert. Have I missed something? Yep. If using Linux 2.6 kernel and recent pthread library, threads share the same pid and they must be signalled using tkill and not kill. The only place which knows how to correctly signal threads is send_thread_signal function in server/ptrace.c. So, the easy way to fix signalling is to use Windows thread identifier for identifying dosvm thread instead of pids (which don't work anyway) and add to wineserver a handler that just calls send_thread_signal, which I guess is what you have been doing, anyway. Now, I have tried this approach and it seems to work. I have some prototype implementation lying around but I was thinking about doing something more complicated at the time, like using SIGUSR2 handler for doing Win32 remote operations discussed earlier on wine-devel, because signal handler is probably running in the correct context for doing this kind of things but I guess locking issues are going to be pretty complicated so it is probably better to just fix dosvm issues with a simple mechanism and not worry about anything else. So, feel free to submit a patch, if it is simple enough it should get accepted or at least you should get some suggestions how to change the patch in order for it to get accepted. -- Jukka Heinonen <http://www.iki.fi/jhei>

4 5

← Newer
1
...
15
16
17
18
19
20
21
...
25
Older →

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 November 2004