wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Re: mixing SHELL32.DLL and SHFOLDER.DLL
by Juan Lang 30 Aug '04

30 Aug '04

Saulius wrote: > Lets try. I am not sure about many things: > > 1, whether is better to duplicate code > SHGetFolderPathW() or to try finding it by an > ordinal its value (the case for the older versions > of SHELL32.DLL) as it was stated by Juergen? What are you trying to accomplish? For example, it seems reasonable to assert that you must use the builtin shell32 and shfolder.dll in combination, or not at all, as Alexandre once suggested. Or, in order for Wine's shfolder.dll to succeed on older (native) versions of shell32.dll, it seems reasonable to have it call SHGetSpecialFolderPath* from SHGetFolderPath*, as MS' version does. In other words, why do you need the combination of native shell32 and builtin shfolder.dll? --Juan __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

3 6

Re: working together on stdole.tlb and a end to dcom9x
by Filip Navara 30 Aug '04

30 Aug '04

Jacek Caban wrote: [snip] > I don't thik it Wine's bug. Applications don't depend on this stuff > and Wine's ref handling is correct. Of course that applications depend on this stuff. This is common code: LoadTypeLib("stdole.tlb", &ptlibStdOle); ptlibStdOle->GetTypeInfoOfGuid(IID_IUnknown, &ptinfoIUnknown)); ptlibStdOle->GetTypeInfoOfGuid(IID_IDispatch, &ptinfoIDispatch)); ptlibStdOle->Release(); Now with Wine the last Release will cause the typelib object to be destroyed and resulting that any later typeinfo references to typelib are invalid pointers. Regards, Filip

2 2

ScrollBars and Wine
by Diego 'Flameeyes' Pettenò 30 Aug '04

30 Aug '04

Hi, Last tuesday I reported some problems with Ultima OnLine AutoPatch ( http://article.gmane.org/gmane.comp.emulators.wine.user/7046 ), with the last CVS and now I found some more information about the problem. Seems like this NULL Pointer (because I think it's this the problem, seeing the 0x00000000) is dereferenced everytime a scrollbar changes position or size (at least while it's painted). I had a similar problem trying to use Inside UO (program to find out data inside the UO files, wrote in Delphi) and everytime I moved a scrollbar I got an NULL Pointer Exception (but in that case it was handled by the Delphi's Exception Handler, so the program didn't closed). Similar problems have Dependency Walker and also native Regedit. Every time I have this: Backtrace: =>1 0x00000000 (0x00001396) 2 0x00000000 (0x00000000) 0x00000000: addb %al,0x0(%eax) as backtrace. With the CVS of two weeks ago at least Dependency Walker run fine without problems at all. -- Diego "Flameeyes" Pettenò dgp85(a)users.sourceforge.net - http://flameeyes.web.ctonet.it/

1 0

trouble debugging
by James Hawkins 30 Aug '04

30 Aug '04

Hi, I'm having a real tough time debugging a program im trying to get to run called KLConfigWizard.exe. I had a problem earlier that was fixed by a tip from Rob. After trying a bunch of different native dll's that this program uses, I located the culprit dll (which is about as much as I seem to be able to do.) If I use native shlwapi then the crash doesnt happen. When i'm not using native shlwapi, the output I get is: [truiken@cmu-127081 Kazaa Lite K++]$ wine KLConfigWizard.exe Please use the registry key HKEY_CURRENT_CONFIG\Sotfware\Fonts\LogPixels to set the screen resolution and remove the "Resolution" entry in the config file fixme:commctrl:InitCommonControlsEx Unknown class! dwICC=0x4000 wine: Unhandled exception (thread 0009), starting debugger... fixme:console:SetConsoleCtrlHandler (0x405fbab0,1) - no error checking or testing yet WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00000000). In 32 bit mode. 0x00000000: addb %al,0x0(%eax) Wine-dbg>bt Backtrace: =>1 0x00000000 (0x00000000) Wine-dbg>q WineDbg terminated on pid 0x8 I do have the log of WINEDEBUG=trace+all, but the log file is ~243mb? I tried scanning through it looking for anything that would give me a clue, but it was hard to tell where any error was. It also doesnt help that the backtrace doesnt contain much of anything. Any ideas? -- James Hawkins

2 3

Re: CommonUnimpStub looping
by Juan Lang 30 Aug '04

30 Aug '04

Mike wrote: > On Sun, 29 Aug 2004 09:23:31 -0700, Steven Edwards > wrote: > > I dont see how native loading of Advapi32 ever > > worked anyway. Its a case like ntdll, kernel32, > > user32 or gdi. Maybe the Win9x advapi32 can..... > > I thought native NT advapi just forwarded to ntdll? Yeah. It depends on a bunch of security APIs that aren't implemented in ntdll though. The win9x advapi32 used to sort of work under wine iirc. I forget at what point that stopped being the case, probably about the time the builtin one became useful. --Juan __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

1 0

CommonUnimpStub looping
by Stefan Leichter 30 Aug '04

30 Aug '04

Hello, trying to install ie6 on current wine gives me an endless loop with function calls to CommonUnimpStub(). I started with .wine and dirve_c created by wine and installed dcom98, vc c++ runtime, vb 5 + 6 Runtime What i found so far is that it happens when the iebatch.exe gets started. The call the DllMain of the gdi32.dll never returns. In the traces i can see: 0016:Call PE DLL (proc=0x4080e5a4,module=0x40800000 L"gdi32.dll",reason=PROCESS_ATTACH,res=0x1) but a line like 0016:Ret PE DLL (proc=0x409b15a4,module=0x409a0000 L"gdi32.dll",reason=PROCESS_ATTACH,res=0x1) retval=1 is not inside the log file. Any tips to get around this problem ? Bye Stefan

3 3

mixing SHELL32.DLL and SHFOLDER.DLL
by Saulius Krasuckas 29 Aug '04

29 Aug '04

Using native version of SHELL32.DLL (from the Win98 install) and builtin version of SHFOLDER.DLL ends up in Wine failure: [s2@katleriai wine]$ WINEDLLOVERRIDES="shell32=n" WINEDEBUG=+loaddll wine /home/s2/cc/Program\ Files/mIRC/mirc 2>&1 | grep -i [^a-z]sh trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\shlwapi.dll" : builtin trace:loaddll:load_dll Loaded module L"C:\\windows\\system\\shell32.dll" : native trace:loaddll:MODULE_LoadModule16 Loaded module "shell.dll" : native trace:loaddll:load_dll Loaded module L"c:\\windows\\system\\shfolder.dll" : builtin err:module:find_forwarded_export function not found for forward 'shell32.SHGetFolderPathA' used by L"c:\\windows\\system\\shfolder.dll". If you are using builtin L"shfolder.dll", try using the native one instead. err:commdlg:DllMain Failed to get entry point "SHGetFolderPathA" for hinst = 0x41930000 This situation was already discussed three years ago or so [1], [3]. The most initiative person here was Juergen Schmied, it seems. Besides another things on Sun, 03 Dec 2000, Juergen Schmied wrote [2]: > Hmm, shlfolder is introduced for systems with a older version of > shell32.dll. I think we should use it just like it's done in cdlg32.c > and get the function with GetProcAdress. Bye the way: this way is used > in several cases of functions within shell32 introduced in later > versions. I'm currently having a patch for comdlg32 and shell32 to the > imports. Will send it soon. AFAICS, there was no patches sent against the SHFOLDER.DLL. Dear Wine developers, can I expect this situation to change soon? Please tell me: should I wait even more, or should I try writing a patch on my own? TIA. [1] http://www.winehq.org/hypermail/wine-devel/2000/12/index.html#41 [2] http://www.winehq.org/hypermail/wine-devel/2000/12/0048.html [3] http://www.winehq.org/hypermail/wine-devel/2001/07/index.html#4

3 4

RE: patch: shell32.dll - SHELL_ArgifyW expands env-vars
by Jens Collin 29 Aug '04

29 Aug '04

Is there anything wrong with this patch? I can't see my changes taken place in CVS. Let me know and I'll fix 'em. /J -----Original Message----- From: wine-patches-admin(a)winehq.org [mailto:wine-patches-admin@winehq.org] On Behalf Of Jens Collin Sent: den 8 augusti 2004 17:55 To: wine-patches(a)winehq.org Subject: patch: shell32.dll - SHELL_ArgifyW expands env-vars changelog: * lookup of envoronment-vars in SHELL_ArgifyW in shell32.dll added. (Such as %SystemRoot%).

2 1

Winrash / Winetest
by Stephen Ogletree 29 Aug '04

29 Aug '04

(I sent a version of this to wine-users originally and Ivan said to send it over here to wine-devel) On windows XP, with the latest patches/service packs, I got the errors below. Since these were popups and/or crashes, I'm assuming they need to be reported manually. 0. Small issue: The winrash installer (NSIS) concludes with a window that has 3 lines that are in blue text to suggest a hyperlink (and the surrounding text even says "Click the text below to make a bookmark for the test results") but clicking the text has no visible effect (when moving the cursor over the text, the cursor does change shape to indicate the text is clickable, so at least that much works...). My default browser is Opera and my security settings in IE are maxed out, with everything possible disabled. In Opera, I typically keep popups, plugins, and javascript disabled, but none of that should keep normal URL to a html page from opening. Since installing winrash didn't do anything except put the service in place and start it, I figured I'd go ahead and download the test manually. This rest of this email pertains to /winetest-200407091000-kevin-mingw.exe/ 1. I received the "Can't parse subtests output of msvcrtd" message during 'extraction'. I assume this is the same error Holly reported. 2. I had a message indicating a timeout during the user32 tests (before the network tests - this appears to be the same message Holly reported). Also, I remember the timeout was occurring back when we first tried out this testing program a month or two (or 3?) ago, so its a bug thats been around a while. 3. I am still seeing an error that I pointed out in the first round (or a long time ago, at least..) of testing where the test crashes Explorer (this is after the timeout, but before the prompt to send the results). Explorer crashing causes all of my desktop icons to reset to their positions from when I last logged in/out (which has been a week or two, so this was significant change), as well as causes some of the SysTray icons to vanish, and finally, of course I lose the start menu bar and the bar containing the running application names for a moment, while Windows XP nicely restarts explorer.exe. Meanwhile, there's no indication of trouble from the winetest window. FWIW: When I agreed to submit my test results, I did *not* receive any warning about my log being too big. Stephen Ogletree

2 1

tips needed for implementing the common control ICC_STANDARD_CLASSES
by James Hawkins 29 Aug '04

29 Aug '04

Hi, I've had a lot of people ask me about how well kazaa lite runs in wine, so I will be working on getting it to work. The install file is called klitekpp243e.exe, and the setup works great. (NOTE: im trying to get the app to work without having to use any native dlls) After the installation of klite, a program called KLConfigWizard.exe is run. It's a dialog box with some text initially, then when you click the next button, the user encounters a fatal error and we're sent to the debugger. The error is: fixme:commctrl:InitCommonControlsEx Unknown class! dwICC=0x4000 The unknown class is one of the two control classes left to be implemented in commctrl: ICC_STANDARD_CLASSES. I would like to implement this class, but I have no idea where to start. I've searched msdn for ICC_STANDARD_CLASSES, but it only turned up a link to the INITCOMMONCONTROLSEX structure. If anyone has any ideas or hints that they can give me, I would really appreciate it. Thanks for your time. -- James Hawkins

3 6

winetest can't parse subtest for msvcrt(d)
by Saulius Krasuckas 29 Aug '04

29 Aug '04

On linuxe I get this: [s2@katleriai s2]$ wine /usr/local/lib/wine/winetest.exe.so Usage: /tmp/wctW5ad4P/msvcrt_test.exe.so test_name Valid test names: cpp environ file headers heap scanf string time ..while Wine Test Shell pops up a message box with the error text: "Can't parse subtests output of msvcrt". I think that's due to some additional \r\n-s in the output of "msvcrt_test.exe.so". Here goes my observation and comparision to the case of "mlang_test.exe.so" (which works smoothly with the winetest): [s2@katleriai tests]$ wine msvcrt_test.exe.so | head -n 1 | od -t x1 0000000 55 73 61 67 65 3a 20 6d 73 76 63 72 74 5f 74 65 0000020 73 74 2e 65 78 65 2e 73 6f 20 74 65 73 74 5f 6e 0000040 61 6d 65 0d 0a 0000045 [s2@katleriai tests]$ wine mlang_test.exe.so | head -n 1 | od -t x1 0000000 55 73 61 67 65 3a 20 6d 6c 61 6e 67 5f 74 65 73 0000020 74 2e 65 78 65 2e 73 6f 20 74 65 73 74 5f 6e 61 0000040 6d 65 0a 0000043 As the "Valid test names:" string is printed by calling fprintf(), I suppose some differences arise due to incorrect linkage or such: [s2@katleriai tests]$ nm msvcrt_test.exe.so | grep fprintf 0001e100 D fprintf 0001e180 D vfprintf [s2@katleriai tests]$ nm mlang_test.exe.so | grep fprintf U fprintf@@GLIBC_2.0 U vfprintf@@GLIBC_2.0 It seems we realy are using msvcrt version of the fprintf(), which works in true-M$-way and adds an additional \r here. Next goes last lines from the build process: [s2@katleriai tests]$ (make clean && make) | tail -n 1 ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole cpp.o environ.o file.o headers.o heap.o scanf.o string.o time.o testlist.o -o msvcrt_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../libs -lmsvcrt [s2@katleriai tests]$ (make clean && make) | tail -n 1 ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole mlang.o testlist.o -o mlang_test.exe.so -L../../../libs/port -lwine_port -L../../../dlls -L../../../libs -lole32 -lgdi32 -lkernel32 -lntdll -luuid Can we fix it? I have no idea on how to link it right with the GLIBC. Of course, I am not sure this is the core of the problem. It would be nice to have winetest running in linux without such two hits (one for the msvcrt and another one for the msvcrtd). Or is this just my linux box configuration flawed?

3 7

Re: CommonUnimpStub looping
by Mike Hearn 29 Aug '04

29 Aug '04

On Sun, 29 Aug 2004 13:26:37 +0100, Robert Shearman wrote: > Use the attached patch and run with warn+module. > > Rob There's no need, I debugged this in January. The problem is that the IE installer contains its own copy of advapi32 but it doesn't actually implement all the functions that ours does. In particular some are exported but just forward to the CommonUnimpStub function which is a bit like our code which throws an exception. Our GDI32 implementation uses one of the registry APIs that is implemented by our advapi32 implementation, but when IE is loaded the advapi32 inside the installer package takes precendence with the result that the GDI is linked to stub code. So things blow up. The solution is to force advapi32 to builtin so the older native version is never loaded. thanks -mike

1 0

Re: W->A cleanup of DirectDrawEnumerateEx part 4
by Mike McCormack 29 Aug '04

29 Aug '04

You should post one patch not four that depend upon each other. Rule of Thumb: * After each patch is applied, the CVS should build and work. Mike James Hawkins wrote: > Changelog > * cleanup cross calls in DirectDrawEnumerateEx >

2 1

cleanup w->a cross calls in printdrv
by James Hawkins 29 Aug '04

29 Aug '04

I want to send this through wine-devel first to see if there are any problems with it. In gdi_private.h I had to change the parameters that pStartDoc accepted from DOCINFOA to DOCINFOW. I know I shouldn't change public api headers, but this one is private so the change seems acceptable. If it's not let me know. Another problem that might popup is the way the DOCINFOW struct is filled in the StartDocA function: len = MultiByteToWideChar( CP_ACP, 0, doc->lpszDocName, -1, NULL, 0 ); docName = HeapAlloc( GetProcessHeap(), 0, len * sizeof(WCHAR) ); MultiByteToWideChar( CP_ACP, 0, doc->lpszDocName, -1, docName, len ); docW.lpszDocName = docName; <--- is this assignment a problem? if(docName) HeapFree( GetProcessHeap(), 0, (LPWSTR)docName ); The reason why I had to make a docName variable is because docW.lpszDocName is a LPCWSTR so there were warnings when i had docW.lpszDocName directly in the call to MultiByteToWideChar. Changelog * cleanup w->a cross calls in StartDoc -- James Hawkins

2 1

Wine's X11drv integration in Mac OS X
by Pierre d'Herbemont 29 Aug '04

29 Aug '04

Hi, We are currently porting Wine to Mac OS X. Currently Wine has a display driver for X11, and we would like to continue to use it for the Mac OS X port: to display the GUI interface, we don't need the Aqua UI elements since we prefer to use Windows theming system, and given the complexity and amount of work done in x11drv . But we also would like to be able to build something that behaves like a normal Carbon or Cocoa App, with a Dock Icon, and a Menu Bar, which would be managed by some Carbon code in Wine itself. I had a look to the X11CallCarbonAndCocoa [1] sample code, but the trouble is that the X11 window still belongs to X11.app, a mouse click in the Dock to get the App's Windows to the front doesn't work for the X11 Window, and the menu bar for this Window is still the X11.app's menu bar. So I'd like to know if there is a way for the Wine Carbon instance to own the X11 Windows Wine created. At least it would be a feature that we'd like to see :) Thanks, Pierre. PS: I am not subscribed to the x11-users so please CC me. I am also CC-ing the wine-devel and darwine-devel, sorry about that. [1] http://developer.apple.com/samplecode/X11CallCarbonAndCocoa/ X11CallCarbonAndCocoa.html

1 0

Re: tips needed for implementing the common control ICC_STANDARD_CLASSES
by Juan Lang 29 Aug '04

29 Aug '04

James wrote: > The unknown class is one of the two control classes > left to be implemented in commctrl: > ICC_STANDARD_CLASSES. I would like to implement > this class, but I have no idea where to start. It doesn't look like you'd need to do anything special for the ICC_STANDARD_CLASSES case. The standard controls are all registered when user32 loads (see the call to CLASS_RegisterBuiltinClasses in user32's user_main.c). Comctl32 already imports user32, so ICC_STANDARD_CLASSES ought to be able to be added to the /* dummy initialization */ section of InitCommonControlsEx. While you're at it, the comment appears to be incorrect. It says ICC_LINK_CLASS is unimplemented, but in fact it is in the case statement below. The comment at the top of the file is similarly out of date. At least, that's what I get by reading it. YMMV. Try patching and seeing how kazaa lite does :) --Juan __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail

2 1

Re: Other W->A crosscalls
by Rolf Kalbermatter 28 Aug '04

28 Aug '04

Vincent Beron wrote: >I attach the smatch script to generate the results I have. It's still >not perfect (the listview.c references are wrong, for example), but as >it's tied to gcc it can detect some calls which otherwise would not be >caught. For example, the calls to GetWindowLongA in header.c are in a >macro. > >Not all of them are bugs: caution is needed when checking, although >reducing the number of false positive would likely be welcome (either by >modifying the script or patches). I see many "xxxAW calls xxxA function" mainly in the shell related DLLs. This is of course not something you can really get rid of, so the script should be able to exclude those cases. Rolf Kalbermatter

2 1

Re: W->A cleanup of DirectDrawEnumerateEx part 1
by Lionel Ulmer 28 Aug '04

28 Aug '04

On Sat, Aug 28, 2004 at 12:17:27PM -0400, James Hawkins wrote: > Changelog > * change szDriver and szDescription from char to WCHAR in > DDDEVICEIDENTIFIER and DDDEVICEIDENTIFIER2. Well, this seems completely wrong to me. Why Unicodify an API that has no Unicode equivalent in Microsoft code ? If I look at the platform SDK, this structure is defined with a 'char', so I wonder why you would choose to deviate from the standard ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

3 2

Re: W->A cleanup of DirectDrawEnumerateEx part 4
by Lionel Ulmer 28 Aug '04

28 Aug '04

On Sat, Aug 28, 2004 at 12:20:24PM -0400, James Hawkins wrote: > Changelog > * cleanup cross calls in DirectDrawEnumerateEx To continue with my other mail, you should have sent all this in one big patch as (from what I can see) it cannot work if you do not apply all 4 parts in one go. Anyway, the 'problem' in Wine is that it uses the DDDEVICEIDENTIFIER2 structure to hold driver information. But, as this information is also exported via API calls like the 'GetDeviceIdentifier' method from the DDraw COM object, you cannot just Unicodify it, you need to let it in ASCII (as there are no, AFAIK, Unicode versions of any of the DirectX < 8 APIs). Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

Problem in mutex?
by Shachar Shemesh 27 Aug '04

27 Aug '04

Hi all, Attached is a sample program, originally written to find out about the impact of using epoll on performance. However, the program doesn't run properly. When running it, I get deadlocked. Does anyone have any explanation? Is it a bug in my Win32 code? > err:ntdll:RtlpWaitForCriticalSection section 0x4017fec0 "?" wait timed > out in thread 0009, blocked by 0000, retrying (60 sec) Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

6 7

Re: 2nd try closed reg keys. make sure CryptSetProviderEx doesnt delete the 'Type XXX' key
by Alexandre Julliard 27 Aug '04

27 Aug '04

James Hawkins <truiken(a)gmail.com> writes: > Changelog > * make CryptSetProviderEx only delete the 'Name' value and not > delete the entire 'Type XXX' key when deleting the default provider. You are still leaking keys, and it doesn't even build (CryptCloseKey is not a valid function). Please take your time, look over the code carefully, fix all the leaks, then build and test it before resubmitting. There's no hurry, you don't need to send a new patch within 10 minutes of getting my mail <g> -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: DbgHelp: Fix for Includes with Relative Paths
by Eric Pouech 27 Aug '04

27 Aug '04

Robert Shearman a écrit : > Hi, > > On startup, the debugger usually prompted me to type the path where > "/winternl.h" can be found. This was due to the path being stored > internally as "../../include/winternl.h", i.e. relative to the source > directory. This patch adds the ability to store the source directory and > then use it when encountering an include path of this type to get the > full path, which means no more prompting. > > Rob > > Changelog: > Store the current source directory and use it when encountering a > relative include so that the full path to it is stored instead. > Robert, normally currpath is supposed to be the directory where the file has been compiled. So, IMO currpath and srcpath duplicate the same stuff. Does it mean that you only get one N_SO per compilation unit ? (the code assumes two: the first one for the dir, the second for the path). A+

2 6

Re: closed reg keys. make sure CryptSetProviderEx doesnt delete the 'Type XXX' key
by Alexandre Julliard 27 Aug '04

27 Aug '04

1 0

Almost final epoll patch
by Shachar Shemesh 27 Aug '04

27 Aug '04

Hi list, Attached is the epoll patch. All problems described in my previous patch sent should be solved here. The only reason I'm not sending this to wine-patches instead of here is that I have not yet had a chance to check it on my client's huge system, and so I cannot say for sure that all problems are truly and utterly resolved. In any case, I would welcome any and all comments about it. This patch is against CVS head, and should compile even if epoll.h is not available, as well as on old glibc's where epoll.h required stdint.h as a prerequisite, and the library's implementation did not have glibc. Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/ Index: configure =================================================================== RCS file: /home/sun/sources/cvs/wine/configure,v retrieving revision 1.592 diff -u -r1.592 configure --- configure 24 Aug 2004 21:00:15 -0000 1.592 +++ configure 27 Aug 2004 11:43:39 -0000 @@ -16207,6 +16207,7 @@ + for ac_header in \ arpa/inet.h \ arpa/nameser.h \ @@ -16269,6 +16270,7 @@ sys/msg.h \ sys/param.h \ sys/poll.h \ + sys/epoll.h \ sys/ptrace.h \ sys/reg.h \ sys/scsiio.h \ Index: configure.ac =================================================================== RCS file: /home/sun/sources/cvs/wine/configure.ac,v retrieving revision 1.303 diff -u -r1.303 configure.ac --- configure.ac 24 Aug 2004 21:00:15 -0000 1.303 +++ configure.ac 27 Aug 2004 11:42:58 -0000 @@ -1156,6 +1156,7 @@ sys/msg.h \ sys/param.h \ sys/poll.h \ + sys/epoll.h \ sys/ptrace.h \ sys/reg.h \ sys/scsiio.h \ Index: include/config.h.in =================================================================== RCS file: /home/sun/sources/cvs/wine/include/config.h.in,v retrieving revision 1.193 diff -u -r1.193 config.h.in --- include/config.h.in 4 Aug 2004 19:10:26 -0000 1.193 +++ include/config.h.in 27 Aug 2004 11:42:58 -0000 @@ -608,6 +608,9 @@ /* Define to 1 if you have the <sys/elf32.h> header file. */ #undef HAVE_SYS_ELF32_H +/* Define to 1 if you have the <sys/epoll.h> header file. */ +#undef HAVE_SYS_EPOLL_H + /* Define to 1 if you have the <sys/errno.h> header file. */ #undef HAVE_SYS_ERRNO_H Index: server/fd.c =================================================================== RCS file: /home/sun/sources/cvs/wine/server/fd.c,v retrieving revision 1.22 diff -u -r1.22 fd.c --- server/fd.c 18 Aug 2004 00:04:58 -0000 1.22 +++ server/fd.c 27 Aug 2004 11:47:12 -0000 @@ -33,6 +33,13 @@ #ifdef HAVE_SYS_POLL_H #include <sys/poll.h> #endif +#ifdef HAVE_SYS_EPOLL_H +#include <stdint.h> +#include <sys/epoll.h> +#endif +#ifdef HAVE_SYS_SYSCALL_H +#include <sys/syscall.h> +#endif #include <sys/stat.h> #include <sys/time.h> #include <sys/types.h> @@ -255,51 +262,173 @@ /****************************************************************/ -/* poll support */ +/* poll and epoll support */ -static struct fd **poll_users; /* users array */ -static struct pollfd *pollfd; /* poll fd array */ -static int nb_users; /* count of array entries actually in use */ +struct fdtrack { + enum { FDT_FREE, FDT_UNWATCHED, FDT_WATCHED, FDT_ERROR } state; + union { + int nextfree; + struct fd *fd; + } data; +}; + +/* Vars used by both */ static int active_users; /* current number of active users */ static int allocated_users; /* count of allocated entries in the array */ -static struct fd **freelist; /* list of free entries in the array */ +static struct fdtrack *poll_users; /* users array */ +static int freelist; /* list of free entries in the array. End of list marker is -1 */ + +/* Vars used by poll */ +static struct pollfd *pollfd; /* poll fd array */ +static int nb_users; /* Maximal index of array entry actually in use */ + +/* Vars used by epoll */ +static int epoll_fd=-1; /* File descriptor for the epoll */ +static const int EPOLL_SIZE=1024; /* "Maximal size" passed to epoll_create. This is an optimization, not a real maximum */ +static struct epoll_event *epoll_revents; /* Array for event results */ +static int epoll_revents_size; /* Number of elements in epoll_revents */ +static int in_epoll; /* Marks whether we are currently processing the epoll results */ +static int closependinglist; /* List of users in close pending state. End of list marker is -1 */ + +#if defined(HAVE_SYS_EPOLL_H) && (HAVE_SYS_EPOLL_H) +/* To prevent wine from not loading on non-epoll supporting platforms, + * we need to dynamically call the epoll functions */ +#ifndef __NR_epoll_create +#define __NR_epoll_create 254 +#endif + +#ifndef __NR_epoll_ctl +#define __NR_epoll_ctl 255 +#endif + +#ifndef __NR_epoll_wait +#define __NR_epoll_wait 256 +#endif + +static inline int _epoll_create( int size ) +{ + return syscall(__NR_epoll_create, size); +} + +static inline int _epoll_ctl(int epfd, int op, int fd, struct epoll_event *event) +{ + return syscall(__NR_epoll_ctl, epfd, op, fd, event); +} + +static inline int _epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout) +{ + return syscall(__NR_epoll_wait, epfd, events, maxevents, timeout); +} +#else +/* epoll not available - make sure that the server still compiles and runs without it */ + +static inline int _epoll_create( int size ) +{ + errno=ENOSYS; + return -1; +} + +static inline int _epoll_ctl(int epfd, int op, int fd, struct epoll_event *event) +{ + errno=ENOSYS; + return -1; +} + +static inline int _epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout) +{ + errno=ENOSYS; + return -1; +} + +/* The following definitions are incorrect ON PURPOSE. They are only meant to make code that will never be reached pass + * compilation. + */ +struct epoll_event { + unsigned int events; + struct { unsigned int u32; } data; +}; + +enum { EPOLL_CTL_DEL, EPOLL_CTL_MOD, EPOLL_CTL_ADD }; + +#endif + +/* Initialize a new area in the poll_users array to be free. + * Does not check input parameters - don't call with increment=0 */ +static void increase_poll_users_size( int increment ) +{ + struct fdtrack *new_poll_users=realloc(poll_users, sizeof(struct fdtrack)*(increment+allocated_users)); + struct pollfd *new_pollfd=(epoll_fd>=0)?NULL:realloc(pollfd, sizeof(struct pollfd)*(increment+allocated_users)); + + if( new_poll_users!=NULL && ( epoll_fd>=0 || new_pollfd!=NULL )) + { + int oldend=allocated_users; + int old_freelist=freelist; + + assert(old_freelist==-1); /* This funciton would never be called unless the free list is empty */ + + poll_users=new_poll_users; + pollfd=new_pollfd; + allocated_users+=increment; + freelist=oldend; + + while( increment>0 ) + { + poll_users[oldend].state=FDT_FREE; + poll_users[oldend].data.nextfree=oldend+1; + + if( epoll_fd<0 ) + { + pollfd[oldend].fd=-1; + pollfd[oldend].events=0; + pollfd[oldend].revents=0; + } + + oldend++; + increment--; + } + + assert(poll_users[oldend-1].state==FDT_FREE); /* If this assert fails, someone probably called us with a zero increment */ + poll_users[oldend-1].data.nextfree=old_freelist; + } + else if( new_poll_users!=NULL ) + { + /* The first realloc succeeded, the second one failed. Make sure the list is consistant. Not much else you can do */ + poll_users=new_poll_users; + } +} /* add a user in the poll array and return its index, or -1 on failure */ static int add_poll_user( struct fd *fd ) { int ret; - if (freelist) + + /* Find next free entry in list */ + if( freelist==-1 ) { - ret = freelist - poll_users; - freelist = (struct fd **)poll_users[ret]; + increase_poll_users_size(allocated_users); } - else + + ret=freelist; + + if( ret!=-1 ) { - if (nb_users == allocated_users) - { - struct fd **newusers; - struct pollfd *newpoll; - int new_count = allocated_users ? (allocated_users + allocated_users / 2) : 16; - if (!(newusers = realloc( poll_users, new_count * sizeof(*poll_users) ))) return -1; - if (!(newpoll = realloc( pollfd, new_count * sizeof(*pollfd) ))) - { - if (allocated_users) - poll_users = newusers; - else - free( newusers ); - return -1; - } - poll_users = newusers; - pollfd = newpoll; - allocated_users = new_count; - } - ret = nb_users++; - } - pollfd[ret].fd = -1; - pollfd[ret].events = 0; - pollfd[ret].revents = 0; - poll_users[ret] = fd; - active_users++; + assert(poll_users[ret].state==FDT_FREE); + assert(epoll_fd>=0 || pollfd[ret].fd==-1); + assert(epoll_fd>=0 || pollfd[ret].events==0); + assert(epoll_fd>=0 || pollfd[ret].revents==0); + + /* Mark the node as allocated */ + freelist=poll_users[ret].data.nextfree; + assert(poll_users[ret].state==FDT_FREE); + poll_users[ret].state=FDT_UNWATCHED; + poll_users[ret].data.fd = fd; + active_users++; + + if( epoll_fd<0 && ret>=nb_users ) + nb_users=ret+1; + } + /* If the above "if" fails, it means there is no memory for the new entry */ + return ret; } @@ -307,17 +436,68 @@ static void remove_poll_user( struct fd *fd, int user ) { assert( user >= 0 ); - assert( poll_users[user] == fd ); - pollfd[user].fd = -1; - pollfd[user].events = 0; - pollfd[user].revents = 0; - poll_users[user] = (struct fd *)freelist; - freelist = &poll_users[user]; + assert( poll_users[user].data.fd==fd && fd->poll_index==user ); + assert( poll_users[user].state!=FDT_WATCHED || fd->unix_fd!=-1 ); + /* If this fails it means that there is a file descriptor still being watched by us, that is no longer recorded in the fd struct. + * This is not a problem for poll, and is not a problem for epoll IF the file descriptor was indeed closed. */ + + if( epoll_fd>=0 ) + { + if( fd->unix_fd!=-1 ) + { + struct epoll_event event; /* This struct needn't actually contain anything meaningful, as we are merely calling DEL */ + _epoll_ctl(epoll_fd, EPOLL_CTL_DEL, fd->unix_fd, &event); + /* XXX - May need to check return code, but there is really nothing to do on failure. + * In any case, failing with errno=ENOENT is ok. + */ + } + } + else + { + pollfd[user].fd = -1; + pollfd[user].events = 0; + pollfd[user].revents = 0; + } + + /* Mark the entry for reuse */ + poll_users[user].state=FDT_FREE; + if( in_epoll ) + { + /* This junction prevents a race where an epoll returned several fds, and this fd is one of them. Before epoll gets to handling + * this fd, however, a previous fd asks to release this fd. As a result, epoll might call a handler on a released fd. epoll checks + * the state to avoid this race. + * However, it may still happen that the same epoll handling loop may release this fd, and then reallocate for a totally different + * purpose. This will foil the state checking safty measure. + * + * To prevent this, fds freed when epoll is still processing results are + * put on a pending list, and are only added to the free list after epoll finishes processing. + * + * Notice when changing this comment - there are two comments in main_loop that refer to this one. Make sure these are updated as well. + */ + poll_users[user].data.nextfree=closependinglist; + closependinglist=user; + } + else + { + poll_users[user].data.nextfree=freelist; + freelist=user; + } active_users--; } +/* initialize the fd related state */ +void init_fd() +{ + /* If this function fails, epoll_fd will be -1, which will signal + * the rest of the functions to use poll instead */ + epoll_fd=_epoll_create(EPOLL_SIZE); + + freelist=-1; + closependinglist=-1; + increase_poll_users_size(32); +} -/* server main poll() loop */ +/* server main poll() or epoll() loop */ void main_loop(void) { int ret; @@ -341,16 +521,79 @@ } if (!active_users) break; /* last user removed by a timeout */ } - ret = poll( pollfd, nb_users, diff ); - if (ret > 0) + if( epoll_fd>=0 ) { + /* if the event handlers added a lot of new events, we may want to increase the returned + * events space */ + if( epoll_revents_size<active_users ) + { + /* If epoll_revents_size is below active_users, there is a (very slim) potential for starvation. + * It is not, strictly speaking, an error though. As such, if the allocation fails, we just go on + * with the smaller array size. */ + struct epoll_event *new_revents=malloc(sizeof(struct epoll_event)*active_users); + if( new_revents!=NULL ) + { + free(epoll_revents); + epoll_revents=new_revents; + epoll_revents_size=active_users; + } + } + + in_epoll=1; + ret = _epoll_wait(epoll_fd, epoll_revents, epoll_revents_size, diff ); + if( ret>=0 ) + { + while( (ret--)>0 ) + { + /* This "if" is preventing a race. The race is documented in a comment inside the "remove_poll_user" function */ + if( poll_users[epoll_revents[ret].data.u32].state==FDT_WATCHED ) + fd_poll_event(poll_users[epoll_revents[ret].data.u32].data.fd, epoll_revents[ret].events); + } + } + else + { + if( errno!=EINTR ) + perror("wineserver: main_loop epoll"); + else if( debug_level ) + perror("wineserver: main_loop epoll (nothing to worry about)"); + } + in_epoll=0; + + /* Free the close pending users. + * Link the current free list to the end of the pending list, and transfer to the free list. + * The race prevented by these actions is documented in a comment in the "remove_poll_user" function + */ + if(closependinglist!=-1) + { + int nextfree, currentfree; + + currentfree=closependinglist; + + assert(poll_users[currentfree].state==FDT_FREE); + + while( (nextfree=poll_users[currentfree].data.nextfree)!=-1 ) + { + assert(poll_users[nextfree].state==FDT_FREE); + currentfree=nextfree; + } + + poll_users[currentfree].data.nextfree=freelist; + freelist=closependinglist; + closependinglist=-1; + } + } + else + { + /* No epoll support - use poll */ int i; - for (i = 0; i < nb_users; i++) + + ret = poll( pollfd, nb_users, diff ); + for (i = 0; ret>0 && i < nb_users; i++) { if (pollfd[i].revents) { - fd_poll_event( poll_users[i], pollfd[i].revents ); - if (!--ret) break; + fd_poll_event( poll_users[i].data.fd, pollfd[i].revents ); + --ret; } } } @@ -835,18 +1078,48 @@ /* set the events that select waits for on this fd */ void set_fd_events( struct fd *fd, int events ) { - int user = fd->poll_index; - assert( poll_users[user] == fd ); - if (events == -1) /* stop waiting on this fd completely */ + int user=fd->poll_index; + assert(poll_users[user].state!=FDT_FREE); + assert( poll_users[user].data.fd == fd ); + + if( epoll_fd>=0 ) { - pollfd[user].fd = -1; - pollfd[user].events = POLLERR; - pollfd[user].revents = 0; + struct epoll_event event; + event.events=events; + event.data.u32=user; + + assert(fd->unix_fd>=0); + + if( events != -1 && poll_users[user].state!=FDT_ERROR ) + { + int epoll_res; + + epoll_res=_epoll_ctl( epoll_fd, (poll_users[user].state==FDT_WATCHED)?EPOLL_CTL_MOD:EPOLL_CTL_ADD, fd->unix_fd, &event ); + /* FIXME: Need to handle failure here */ + poll_users[user].state=FDT_WATCHED; + } + else if( events==-1 ) + { + /* flag fd as erred */ + _epoll_ctl(epoll_fd, EPOLL_CTL_DEL, fd->unix_fd, &event ); + poll_users[user].state=FDT_ERROR; + } } - else if (pollfd[user].fd != -1 || !pollfd[user].events) + else { - pollfd[user].fd = fd->unix_fd; - pollfd[user].events = events; + if (events == -1) /* stop waiting on this fd completely */ + { + pollfd[user].fd = -1; + pollfd[user].events = POLLERR; + pollfd[user].revents = 0; + poll_users[user].state=FDT_ERROR; + } + else if (poll_users[user].state!=FDT_ERROR) + { + pollfd[user].fd = fd->unix_fd; + pollfd[user].events = events; + poll_users[user].state = FDT_WATCHED; + } } } Index: server/file.h =================================================================== RCS file: /home/sun/sources/cvs/wine/server/file.h,v retrieving revision 1.17 diff -u -r1.17 file.h --- server/file.h 18 Aug 2004 00:04:58 -0000 1.17 +++ server/file.h 27 Aug 2004 11:42:58 -0000 @@ -44,6 +44,7 @@ /* file descriptor functions */ +extern void init_fd(); extern struct fd *alloc_fd( const struct fd_ops *fd_user_ops, struct object *user ); extern struct fd *open_fd( struct fd *fd, const char *name, int flags, mode_t *mode, unsigned int access, unsigned int sharing, unsigned int options ); Index: server/main.c =================================================================== RCS file: /home/sun/sources/cvs/wine/server/main.c,v retrieving revision 1.31 diff -u -r1.31 main.c --- server/main.c 26 Mar 2003 01:32:18 -0000 1.31 +++ server/main.c 27 Aug 2004 11:42:58 -0000 @@ -122,6 +122,7 @@ signal( SIGTERM, sigterm_handler ); signal( SIGABRT, sigterm_handler ); + init_fd(); sock_init(); open_master_socket(); sync_namespace = create_namespace( 37, TRUE );

1 0

Fwd: Re: make CryptSetProviderEx update the provider Name and TypeName to registry
by James Hawkins 27 Aug '04

27 Aug '04

---------- Forwarded message ---------- From: James Hawkins <truiken(a)gmail.com> Date: Fri, 27 Aug 2004 08:18:48 -0400 Subject: Re: Re: make CryptSetProviderEx update the provider Name and TypeName to registry To: Jakob Eriksson <jakob(a)vmlinux.org> I sent in a patch earlier that added tests for CryptSetProviderEx. It's been committed. On Fri, 27 Aug 2004 11:39:55 +0200, Jakob Eriksson <jakob(a)vmlinux.org> wrote: > > Can you add this test code to the Wine regression suite? > > > > > James Hawkins wrote: > > >I just ran a test programming in windows to see how the registry is > >changed by called CryptSetProviderEx with the CRYPT_DELETE_DEFAULT > >flag. When the CRYPT_DELETE_DEFAULT flag is used, the Name value of > >the Type XXX key is removed, but not the TypeName, which solves the > >problem of not being able to get to the TypeName. I will rewrite this > >patch with the new behavior and send it shortly. > > > >On Fri, 20 Aug 2004 13:11:12 -0700, James Hawkins <truiken(a)gmail.com> wrote: > > > > > >>I'm working on a test app that I hope wil shine some light on how > >>windows gets the Name and TypeName values back in the registry after > >>they've been deleted. The problem is that the only instance of the > >>Name and TypeName data is in the DllRegisterServer function of the > >>provider dll. I couldn't think of any other way to get to that data > >>to get it in the registry, but I will be testing this in windows. > >>What im thinking is that windows might not even delete the key at all. > >> If you have any suggestions it would help a lot. > >> > >> > >> > >>On Fri, 20 Aug 2004 12:48:07 -0700, Alexandre Julliard > >><julliard(a)winehq.org> wrote: > >> > >> > >>>James Hawkins <truiken(a)gmail.com> writes: > >>> > >>> > >>> > >>>>>Changelog > >>>>> * Call provider.dll's DllRegisterServer from CryptSetProviderEx to > >>>>>update the Name and TypeName values in the registry properly when > >>>>>setting the default provider > >>>>> > >>>>> > >>>It doesn't seem right to call DllRegisterServer from there, IMO it > >>>should only be called when the dll is installed. Do you have evidence > >>>that Windows does it this way? > >>> > >>>-- > >>>Alexandre Julliard > >>>julliard(a)winehq.org > >>> > >>> > >>> > >>-- > >>James Hawkins > >> > >> > >> > > > > > > > > > > -- James Hawkins -- James Hawkins

1 0

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