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

unixfs.dll: shell namespace extension for the unix filesystem
by Michael Jung 23 Feb '05

23 Feb '05

Hi, this is a first rough cut version of a shell namespace extension to access the unix filesystem from wine. It's primary use-case is for winecfg's drive-mapping propery sheet. It already works for this purpose. It would be cool if 'the COM guys' could take a look at the code, since this is the first time I did something COM'ish. It would be nice if possible miss-conceptions could be found early on. Ciao, -- Michael Jung mjung(a)iss.tu-darmstadt.de

2 3

RE: [ros-dev] RE: Collection of wine tools on windows
by Rolf Kalbermatter 23 Feb '05

23 Feb '05

"Casper Hornstrup" <ch(a)csh-consult.dk> wrote: >Yes, but then you need to publish the sources for the non-free application under the LGPL. >When using headers to build your application, you create a derived work of those headers. > >http://www.fsf.org/licensing/licenses/lgpl.html > >"A "work based on the Library" means either the Library or any derivative work under copyright >law: that is to say, a work containing the Library or a portion of it, either verbatim or with >modifications and/or translated straightforwardly into another language. (Hereinafter, translation >is included without limitation in the term "modification".)" > >"4. You may copy and distribute the Library (or a portion or derivative of it, under Section 2) in >object code or executable form under the terms of Sections 1 and 2 above provided that you accompany >it with the complete corresponding machine-readable source code, which must be distributed under >the terms of Sections 1 and 2 above on a medium customarily used for software interchange." This is rubish. LGPL is understood by most in such a way, that you can use a library in a closed source application as long as you do not make that library a static dependency in your app, meaning that the user could replace that LGPLed library with a newer, compatible version of his and your app still works. Shared libs (or DLLs) clearly are not a static dependency. You are obliged to provide to users of your closed source app and other interested parties the (possibly modified) sources of the LGPL library only, either directly on the media where you distribute your app with or under reasonable terms on request. A download link to Wine seems a very reasonable term to me as long as you didn't make modifications to it, or took care to at least provide a patch with those modifications to the project in question. With public headers for a library, it could be argued that they do not really provide any code (in most cases) and therefore are even less protectable in the interest of portability and interoperation compatibility. If it wouldn't be that way nobody could possibly write a closed source application to run under Linux as the kernel and it's headers are under the even more "restrictive" GPL license and every app has to link to the OS kernel (and use the appropriate headers) in some ways to be operable. Rolf Kalbermatter

2 1

Re: winmm/wineoss: use DSP_POST to flush the frag buffers
by Jeremy White 23 Feb '05

23 Feb '05

Don't apply this; more survey of alternate sound cards shows that DSP_POST does not work as well as advertised everywhere. Jer Jeremy White wrote: > When we get down to the last fragment or two in our output > to the DSP, we should use the SND_DSP_POST ioctl to let the > sound card know to flush those fragments. This allows us to > precisely know when the buffer is empty, and fixes another > set of winmm tests. > > > ------------------------------------------------------------------------ > > Index: dlls/winmm/wineoss/audio.c > =================================================================== > RCS file: /home/wine/wine/dlls/winmm/wineoss/audio.c,v > retrieving revision 1.152 > diff -u -r1.152 audio.c > --- dlls/winmm/wineoss/audio.c 28 Jan 2005 17:21:07 -0000 1.152 > +++ dlls/winmm/wineoss/audio.c 22 Feb 2005 22:17:22 -0000 > @@ -1665,12 +1665,13 @@ > > /* input queue empty and output buffer with less than one fragment to play > * actually some cards do not play the fragment before the last if this one is partially feed > - * so we need to test for full the availability of 2 fragments > + * so we need to test for full the availability of 2 fragments ; the DSP_POST ioctl > + * will let the card know to play out the rest of the fragments > */ > if (!wwo->lpPlayPtr && wwo->dwBufferSize < availInQ + 2 * wwo->dwFragmentSize && > !wwo->bNeedPost) { > - TRACE("Run out of wavehdr:s...\n"); > - return INFINITE; > + TRACE("Run out of wavehdr's, requesting a POST...\n"); > + wwo->bNeedPost = TRUE; > } > > /* no more room... no need to try to feed */

1 0

ole/storage: Problems with 'Myst Uru Demo'
by Paul Vriens 23 Feb '05

23 Feb '05

Hi, eventhough Michael withdrew his patch (http://www.winehq.org/hypermail/wine-devel/2005/02/0687.html) I've tried it, and it crashes in the ole/storage area. I've added some TRACE's and this is the output: 000b:trace:storage:StorageBaseImpl_Release (0x77ece0f8/0x77ece0f8) decremented refcount to 8 000b:trace:storage:StorageBaseImpl_OpenStorage (0x77ece0f8, L"ID_9", (nil), 1012, (nil), 0, 0x28de68) 000b:trace:storage:StorageBaseImpl_OpenStorage Calling IEnumSTATSTGImpl_Construct 000b:trace:storage:IEnumSTATSTGImpl_Construct 0xa2f7c0 / 10680096 000b:trace:storage:IEnumSTATSTGImpl_Construct Calling IStorage_AddRef(0x77ece0f8) 000b:trace:storage:StorageBaseImpl_AddRef (0x77ece0f8) incremented refcount to 9 000b:trace:storage:IEnumSTATSTGImpl_Construct Calling IEnumSTATSTGImpl_Reset 000b:trace:storage:IEnumSTATSTGImpl_Destroy Calling IStorage_Release(0x77ece0f8) 000b:trace:storage:StorageBaseImpl_Release (0x77ece0f8/0x77ece0f8) decremented refcount to 8 000b:trace:storage:StorageBaseImpl_OpenStorage Calling StorageInternalImpl_Construct 000b:trace:storage:StorageInternalImpl_Construct Calling StorageBaseImpl_AddRef(0x77ece0f8) 000b:trace:storage:StorageBaseImpl_AddRef (0x77ece0f8) incremented refcount to 9 000b:trace:storage:StorageBaseImpl_OpenStorage Calling StorageBaseImpl_AddRef(0x77e96a80) 000b:trace:storage:StorageBaseImpl_AddRef (0x77e96a80) incremented refcount to 2012012793 000b:trace:storage:StorageBaseImpl_OpenStorage <-- 00000000 000b:trace:storage:StorageBaseImpl_AddRef (0x77e96a80) incremented refcount to 2012012794 000b:trace:storage:StorageBaseImpl_OpenStream (0x77e96a80, L"FEATURELOG_STDPROPS", (nil), 12, 0, 0x28dd14) 000b:trace:storage:StorageBaseImpl_OpenStream Calling IEnumSTATSTGImpl_Construct 000b:trace:storage:StorageBaseImpl_Release (0x77e96a80/0x77e96a80) decremented refcount to 2012012793 000b:trace:ole:GetErrorInfo (0, 0x28e12c, (nil)) 000b:fixme:crypt:CRYPT_VerifyImage (rsaenh.dll, 0x77e95528): not verifying image 000b:trace:storage:StorageBaseImpl_OpenStream (0x77e96a80, L"FEATURELOG_STDPROPS", (nil), 12, 0, 0x28df4c) 000b:trace:storage:StorageBaseImpl_OpenStream Calling IEnumSTATSTGImpl_Construct wine: Unhandled exception (thread 000b), starting debugger... the refcount with values of 2012012793 look a bit suspicious. Any ideas where to look? Cheers, Paul.

1 1

A call to fix the BeginPaint issue
by Nick Hornback 23 Feb '05

23 Feb '05

Alright, this is probably the last time I will bring it up before I realize that there is essentially no interest in fixing this, but this has been bothering me for quite some time now. A few others have brought it up over the past couple months as well. http://www.winehq.org/hypermail/wine-cvs/2004/10/0395.html As discussed (but nothing really done about it), this patch is directly known to break painting in at least the following applcations: DeusEx Trickstyle Foobar2000 Zoo Tycoon 1 demo This is because, as far as I'm aware, these applications don't send BeginPaint/EndPaint as they technically should, but they all work fine on native Windows. Now, before, it has simply been a matter of reversing the patch, no big deal. However, since the region handling has been moved to the server, that is not possible without a lot of tinkering, something that I just don't have the mad skillz to do. --Nick __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com

6 8

Re: rsabase: Make rsabase a wrapper around rsaenh
by Alexandre Julliard 23 Feb '05

23 Feb '05

Michael Jung <mjung(a)iss.tu-darmstadt.de> writes: > As suggested by Alexandre, I removed all implementation code from rsabase and > made it a pure wrapper around rsaenh. I've imitated the scheme used in wine's > unicows.dll to do so. You don't need that, you can forward directly in the spec file. Unicows has to do it differently because of the way it's loaded, but other dlls can use normal forwards. -- Alexandre Julliard julliard(a)winehq.org

1 0

re: Poor performance when using Texas Instruments code generation tools in Wine
by Dan Kegel 23 Feb '05

23 Feb '05

Anders wrote: > We have been using TI code generation tools (compiler and linker) on > Wine, and it has worked well. However, when we started evaluating newer > versions of the codegen tools, the linking time was dramatically > increased (from 20 sec to 30 minutes...). > > We have done some profiling using oprofile, and found that most of this > time (96%) is spent in the HEAP_FindFreeBlock* *function in the ntdll > module. The time needed to locate a free heap block increases gradually, > from a few iterations up to about 15000 in the project we are building. Wow, that's worth looking into! Can you write a small C program that has the same behavior? That would help us reproduce the problem and then solve it. Thanks, Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

2 1

richedit (ro): "Select all" or "Copy" crashes wine
by Tobias Burnus 23 Feb '05

23 Feb '05

Hi, in Diamond 2.x (http://www.codeweavers.com/compatibility/browse/name?app_id=865) there is a structure-data richedit (read-only). (Under Windows: http://www.physik.fu-berlin.de/~tburnus/wine/diamond_info.png; it's on the right side; Wine looks similar, but the background is grey and it is not that sleek.) I can flawlessly select some text using the mouse or the keyboard, but if I use the context menu and choose either of - "Select all" - "Copy" (after selecting something) it crashes with: wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x451e158b). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:451e158b ESP:406dfb98 EBP:406dfbb4 EFLAGS:00210246( - 00 -RIZP1) EAX:40425b70 EBX:451eecec ECX:40b77600 EDX:451f2c50 ESI:00000000 EDI:40425b70 Stack dump: 0x406dfb98: 4058a80e 4058a80e 451eecec 00000000 0x406dfba8: 451eecec 404240d8 00000111 406dfbe8 0x406dfbb8: 451e3ba8 40425b70 00000000 00000000 0x406dfbc8: 00000111 00000000 00000301 00000301 0x406dfbd8: 44b68a14 40b6a450 00000000 00020048 0x406dfbe8: 406dfc0c 40ae88f7 00020048 00000111 Backtrace: =>1 0x451e158b RTFSetEditStream in riched32 (0x406dfbb4) 2 0x451e3ba8 RICHED32_WindowProc in riched32 (0x406dfbe8) 3 0x40ae88f7 WINPROC_wrapper in user32 (0x406dfc0c) 4 0x40ae9c1b WINPROC_CallWndProc in user32 (0x406dfc50) 5 0x40aef2c5 CallWindowProcA in user32 (0x406dfc94) 6 0x00563a90fixme:dbghelp_msc:pe_load_debug_directory This guy has FPO information in diamond (+0x163a90) (0x406dfcb4) 7 0x005641c2 in diamond (+0x1641c2) (0x406dfcd4) 8 0x00562ed9 in diamond (+0x162ed9) (0x406dfd40) 9 0x005631e5 in diamond (+0x1631e5) (0x406dfd5c) 10 0x40ae88f7 WINPROC_wrapper in user32 (0x406dfd80) 11 0x40ae9c1b WINPROC_CallWndProc in user32 (0x406dfdc4) 12 0x40aef2c5 CallWindowProcA in user32 (0x406dfe08) 13 0x40ad26f2 DispatchMessageA in user32 (0x406dfe34) 14 0x00567cb7 in diamond (+0x167cb7) (0x005f3d50) 15 0x00000001 (0x005ab278) 16 0x00464520 in diamond (+0x64520) (0x00589f71) 0x451e158b RTFSetEditStream+0x2b in riched32: movl 0x0(%esi),%eax A WINEDEBUG=+relay,+seh,+tid gives the following (excerpt): (This is with Meissner's wine-20050211-1.1 and CXOffice-nightly 05-02-21 and occurs also with earlier versions of WINE. The excerpt below comes from wine-20050211-1.1 with "Select all".) [...] 0009:Call window proc 0x5631b9 (hwnd=0x20048,msg=WM_COMMAND,wp=000000b1,lp=00000000) 0009:Call kernel32._ConfirmSysLevel(40b77600) ret=40ade8c5 0009:Ret kernel32._ConfirmSysLevel() retval=00000000 ret=40ade8c5 0009:Call kernel32.TlsGetValue(00000007) ret=0058c6c9 0009:Ret kernel32.TlsGetValue() retval=403cdc08 ret=0058c6c9 0009:Call kernel32.TlsGetValue(00000007) ret=0058c6c9 0009:Ret kernel32.TlsGetValue() retval=403cdc08 ret=0058c6c9 0009:Call kernel32.TlsGetValue(00000007) ret=0058c6c9 0009:Ret kernel32.TlsGetValue() retval=403cdc08 ret=0058c6c9 0009:Call user32.CallWindowProcA(451e38b0,00020048,00000111,000000b1,00000000) ret=00563a90 0009:Call kernel32._EnterSysLevel(40b77600) ret=40ade890 0009:Call ntdll.RtlEnterCriticalSection(40b77600) ret=4050828b 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=4050828b 0009:Ret kernel32._EnterSysLevel() retval=4058a640 ret=40ade890 0009:Call kernel32._LeaveSysLevel(40b77600) ret=40ade920 0009:Call ntdll.RtlLeaveCriticalSection(40b77600) ret=40507fc1 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=40507fc1 0009:Ret kernel32._LeaveSysLevel() retval=4058a80e ret=40ade920 0009:Call kernel32._EnterSysLevel(40b77600) ret=40ade890 0009:Call ntdll.RtlEnterCriticalSection(40b77600) ret=4050828b 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=4050828b 0009:Ret kernel32._EnterSysLevel() retval=4058a640 ret=40ade890 0009:Call kernel32._LeaveSysLevel(40b77600) ret=40ade920 0009:Call ntdll.RtlLeaveCriticalSection(40b77600) ret=40507fc1 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=40507fc1 0009:Ret kernel32._LeaveSysLevel() retval=4058a80e ret=40ade920 0009:Call kernel32.GlobalGetAtomNameW(0000c043,406df99c,0000003c) ret=40aba1ba 0009:Ret kernel32.GlobalGetAtomNameW() retval=00000008 ret=40aba1ba 0009:Call kernel32._EnterSysLevel(40b77600) ret=40ade890 0009:Call ntdll.RtlEnterCriticalSection(40b77600) ret=4050828b 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=4050828b 0009:Ret kernel32._EnterSysLevel() retval=4058a640 ret=40ade890 0009:Call kernel32._LeaveSysLevel(40b77600) ret=40ade920 0009:Call ntdll.RtlLeaveCriticalSection(40b77600) ret=40507fc1 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=40507fc1 0009:Ret kernel32._LeaveSysLevel() retval=4058a80e ret=40ade920 0009:Call window proc 0x451e38b0 (hwnd=0x20048,msg=WM_COMMAND,wp=000000b1,lp=00000000) 0009:Call kernel32._ConfirmSysLevel(40b77600) ret=40ade8c5 0009:Ret kernel32._ConfirmSysLevel() retval=00000000 ret=40ade8c5 0009:Call user32.GetWindowLongW(00020048,00000004) ret=451e38e2 0009:Call kernel32._EnterSysLevel(40b77600) ret=40ade890 0009:Call ntdll.RtlEnterCriticalSection(40b77600) ret=4050828b 0009:Ret ntdll.RtlEnterCriticalSection() retval=00000000 ret=4050828b 0009:Ret kernel32._EnterSysLevel() retval=4058a640 ret=40ade890 0009:Call kernel32._LeaveSysLevel(40b77600) ret=40ade920 0009:Call ntdll.RtlLeaveCriticalSection(40b77600) ret=40507fc1 0009:Ret ntdll.RtlLeaveCriticalSection() retval=00000000 ret=40507fc1 0009:Ret kernel32._LeaveSysLevel() retval=4058a80e ret=40ade920 0009:Ret user32.GetWindowLongW() retval=404240c0 ret=451e38e2 0009:trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x451e158b 0009:trace:seh:EXC_RtlRaiseException info[0]=00000000 0009:trace:seh:EXC_RtlRaiseException info[1]=00000000 0009:trace:seh:EXC_RtlRaiseException eax=40425b30 ebx=451eecec ecx=00000000 edx=451f2c50 esi=00000000 edi=40425b30 0009:trace:seh:EXC_RtlRaiseException ebp=406df9ec esp=406df9d0 cs=0073 ds=007b es=007b fs=003b gs=0033 flags=00210246 0009:trace:seh:EXC_CallHandler calling handler at 0x562f3e code=c0000005 flags=0 0009:Call kernel32.GetLastError() ret=00547758 0009:Ret kernel32.GetLastError() retval=00000000 ret=00547758 0009:Call kernel32.TlsGetValue(00000006) ret=00547766 0009:Ret kernel32.TlsGetValue() retval=44b60100 ret=00547766 0009:Call kernel32.SetLastError(00000000) ret=005477ba 0009:Ret kernel32.SetLastError() retval=00000000 ret=005477ba 0009:trace:seh:EXC_CallHandler handler returned 1 0009:trace:seh:EXC_CallHandler calling handler at 0x54c1e0 code=c0000005 flags=0 0009:Call kernel32.GetLastError() ret=00547758 0009:Ret kernel32.GetLastError() retval=00000000 ret=00547758 0009:Call kernel32.TlsGetValue(00000006) ret=00547766 0009:Ret kernel32.TlsGetValue() retval=44b60100 ret=00547766 0009:Call kernel32.SetLastError(00000000) ret=005477ba 0009:Ret kernel32.SetLastError() retval=00000000 ret=005477ba 0009:Call kernel32.UnhandledExceptionFilter(406df57c) ret=0054e15a 0009:Call kernel32.IsBadCodePtr(41036a10) ret=005503a1 0009:Ret kernel32.IsBadCodePtr() retval=00000000 ret=005503a1 0009:Call kernel32.IsBadCodePtr(1000a670) ret=410386a1 0009:Ret kernel32.IsBadCodePtr() retval=00000000 ret=410386a1 0009:Call ntdll.NtCreateEvent(406df240,001f0003,406df408,00000001,00000000) ret=404c574f 0009:Ret ntdll.NtCreateEvent() retval=00000000 ret=404c574f wine: Unhandled exception (thread 0009), starting debugger... 0009:Call ntdll.RtlInitUnicodeString(406df238,40568a80 L"Machine\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug") ret=404c 57e0 [...] Tobias

1 0

Checking Wine's spec files
by Francois Gouget 23 Feb '05

23 Feb '05

The recent problems with -noname in shell32.spec got be to dig up an old script I had which reads spec and dumpbin files and processes them. I then retrofitted it so it could do some hopefully useful checks for this kind of issues. So this script works by comparing the output of winedump or dumpbin on the Windows dlls for as many platforms as are available (I have 7 so far) with the contents of Wine's spec files. It then applies a number of rules to try to detect problems. However the information we can extract from the Windows dlls is incomplete so this script uses heuristics. This means the problems it reports should be treated with a grain of salt. Running the check script To download and run the check script, see the instructions are on my web site: http://fgouget.free.fr/wine/checkspec-en.shtml Then you can run it as follows: ./check_spec --verbose ~/wine/dlls/shell32.spec And here is a description of the checks it performs so far, illustrated with the output for shell32.dll. Comments and suggestions for more checks or improvements are welcome. I'll wait a bit (and then start sending some patches unless someone else wants to tackle this (could be a nice janitorial project). Notes: * It would be nice if winedump could dump the Platform SDK's .lib files. These files must have an explicit mention of which entry points have the -noname property so this would give us a more reliable source of information than the heuristics in this script. * dumpbin will something special when an API is being forwarded: 40 [NONAME] (forwarded to shlwapi.PathIsRelativeW) But winedump prints nothing special. It would be nice to add this functionality to winedump. -noname vs. ordinal internal consistency ----------------------------------------- This check verifies that all APIs which have the '-noname' property, also have an explicit ordinal. This is the only check which does not depend on dumps of the Windows dlls. No problem found here. APIs which should not have an explicit ordinal ---------------------------------------------- The script scans the Wine spec file for APIs which have both a name and an explicit ordinal. For each of these, the script looks up the API by name on the Windows platforms and collates a list of the corresponding ordinals. If it finds more than one ordinal then it considers the API should not be given an explicit ordinal. In that case it reports how many times the API was found with the right ordinal on Windows, and how many different values were found. If the former is 0 or 1 then it's clear the API should not be given an explicit ordinal. If the latter is 2 then things are maybe not so clear. These 64 APIs should not have an ordinal: SHGetDataFromIDListA (correct 0 times, found 5 values) StrChrIW (correct 0 times, found 3 values) SheGetCurDrive (correct 0 times, found 5 values) ShellAboutW (correct 0 times, found 5 values) SheFullPathA (correct 0 times, found 5 values) DllGetClassObject (correct 0 times, found 5 values) SheGetDirA (correct 0 times, found 5 values) SheGetPathOffsetW (correct 0 times, found 5 values) SheGetDirW (correct 0 times, found 5 values) DragFinish (correct 0 times, found 5 values) StrCmpNW (correct 0 times, found 3 values) StrNCmpA (correct 0 times, found 3 values) StrCmpNIA (correct 0 times, found 3 values) ShellExecuteW (correct 0 times, found 5 values) SheChangeDirW (correct 0 times, found 5 values) Shell_NotifyIconW (correct 0 times, found 5 values) StrCpyNA (correct 0 times, found 3 values) SheRemoveQuotesW (correct 0 times, found 5 values) StrCmpNA (correct 0 times, found 3 values) ShellExecuteExA (correct 0 times, found 5 values) StrRStrIA (correct 0 times, found 3 values) StrStrA (correct 0 times, found 3 values) StrStrW (correct 0 times, found 3 values) StrChrA (correct 0 times, found 3 values) SheShortenPathA (correct 0 times, found 5 values) StrNCmpIW (correct 0 times, found 3 values) StrRChrIA (correct 0 times, found 3 values) StrChrIA (correct 0 times, found 3 values) SheConvertPathW (correct 0 times, found 5 values) StrNCpyW (correct 0 times, found 3 values) DragAcceptFiles (correct 0 times, found 5 values) StrRStrIW (correct 0 times, found 3 values) StrNCmpIA (correct 0 times, found 3 values) Shell_NotifyIconA (correct 0 times, found 5 values) ShellExecuteA (correct 0 times, found 5 values) ShellExecuteEx (correct 0 times, found 5 values) SheChangeDirA (correct 0 times, found 5 values) StrStrIA (correct 0 times, found 3 values) SheChangeDirExA (correct 0 times, found 5 values) ShellAboutA (correct 0 times, found 5 values) SheChangeDirExW (correct 0 times, found 5 values) ShellExecuteExW (correct 0 times, found 5 values) StrNCmpW (correct 0 times, found 3 values) StrChrW (correct 0 times, found 3 values) DragQueryFile (correct 0 times, found 5 values) StrRStrW (correct 0 times, found 3 values) StrCpyNW (correct 0 times, found 3 values) DragQueryFileA (correct 0 times, found 5 values) StrNCpyA (correct 0 times, found 3 values) DragQueryFileW (correct 0 times, found 5 values) Shell_NotifyIcon (correct 0 times, found 5 values) StrStrIW (correct 0 times, found 3 values) SHGetDataFromIDListW (correct 0 times, found 5 values) SheGetDirExW (correct 0 times, found 5 values) SheFullPathW (correct 0 times, found 5 values) SheRemoveQuotesA (correct 0 times, found 5 values) SheShortenPathW (correct 0 times, found 5 values) StrRStrA (correct 0 times, found 3 values) StrCmpNIW (correct 0 times, found 3 values) StrRChrW (correct 0 times, found 3 values) SheSetCurDrive (correct 0 times, found 5 values) StrRChrIW (correct 0 times, found 3 values) DragQueryPoint (correct 0 times, found 5 values) StrRChrA (correct 0 times, found 3 values) APIs which have the wrong ordinal --------------------------------- This check collates a list of Windows ordinals for the API exactly as above. But it emits a warning about the API only if it found a single ordinal value on Windows and that ordinal does not match Wine's ordinal. These 1 APIs have the wrong ordinal: ReadCabinetState (is 654 on api2003es) (may be best to ignore this one) APIs which should have the -noname property -------------------------------------------- Again this check concerns APIs which have both an explicit ordinal and a name. This time it counts the number of Windows platforms where the API is not exported by name but which still have an entry point with the right ordinal and no name. If more than one such platforms were found, the script considers the API should have the '-noname' property. These 28 APIs should have the -noname property: SHRegOpenKeyW (507 has no name on api95 api98 apint4) SHGetNetResource (69 has no name on all) DAD_SetDragImageFromListView (177 has no name on all) ReceiveAddToRecentDocs (647 has no name on api95 api98 apime apint4 api2000) SHRegQueryValueExW (511 has no name on api95 api98 apint4) PifMgr_GetProperties (10 has no name on api95 api98 apime apint4 api2000 apixp) SHChangeRegistrationReceive (646 has no name on all) RestartDialogEx (730 has no name on apixp) SHRegQueryValueA (508 has no name on api95 api98 apint4) SHWaitOp_Operate (648 has no name on all) SHNetConnectionDialog (160 has no name on all) InvalidateDriveType (65 has no name on all) SHRegCloseKey (505 has no name on api95 api98 apint4) SHHandleDiskFull (185 has no name on all) SHFindComputer (91 has no name on all) SHRegQueryValueW (510 has no name on api95 api98 apint4) SHGlobalDefect (197 has no name on all) PifMgr_OpenProperties (9 has no name on api95 api98 apime apint4 api2000 apixp) SHRegQueryValueExA (509 has no name on api95 api98 apint4) PifMgr_SetProperties (11 has no name on api95 api98 apime apint4 api2000 apixp) SHCreatePropSheetExtArrayEx (194 has no name on all) RealDriveTypeFlags (525 has no name on all) SHChangeNotifyReceive (643 has no name on all) SHRegOpenKeyA (506 has no name on api95 api98 apint4) SHIsBadInterfacePtr (84 has no name on all) SHRegDeleteKeyW (512 has no name on apint4) PifMgr_CloseProperties (13 has no name on api95 api98 apime apint4 api2000 apixp) DragQueryInfo (76 has no name on all) APIs which should not have the -noname property ------------------------------------------------ This the same check as above but with a different analysis of the results. Namely, the script considers the API should not have the -noname property if one of the following two conditions is met: * the API is exported by name on all platforms * the API's ordinal corresponds to another API on one of the platforms. These 33 APIs should not have the -noname property: FileMenu_AppendItem (115 has other names on apixp api2003es) FileMenu_Create (114 has other names on apixp api2003es) DragFinish FileMenu_DeleteItemByFirstID (141 has other names on apixp api2003es) FileMenu_DrawItem (105 has other names on apixp api2003es) FileMenu_DeleteAllItems (104 has other names on apixp api2003es) FileMenu_DeleteItemByCmd (117 has other names on apixp api2003es) FileMenu_DeleteItemByIndex (140 has other names on apixp api2003es) FileMenu_DeleteSeparator (142 has other names on apixp api2003es) FileMenu_ReplaceUsingPidl (113 has other names on apixp api2003es) FileMenu_MeasureItem (112 has other names on apixp api2003es) ILAppend (154 has other names on api2003es) FileMenu_AppendFilesForPidl (124 has other names on apixp api2003es) DragAcceptFiles FileMenu_InitMenuPopup (109 has other names on apixp api2003es) FileMenu_AbortInitMenu (120 has other names on apixp api2003es) FileMenu_GetLastSelectedItemPidls (107 has other names on apixp api2003es) FileMenu_EnableItemByCmd (143 has other names on apixp api2003es) FileMenu_HandleMenuChar (108 has other names on apixp api2003es) Shell_GetImageList (71 has other names on api2003es) FileMenu_GetItemExtent (144 has other names on apixp api2003es) FileMenu_TrackPopupMenuEx (116 has other names on apixp api2003es) DragQueryFile FileMenu_FindSubMenuByPidl (106 has other names on apixp api2003es) FileMenu_Invalidate (111 has other names on apixp api2003es) DragQueryFileA DragQueryFileW FileMenu_AddFilesForPidl (125 has other names on api95 api98 apime apint4 api2000 apixp api2003es) FileMenu_Destroy (118 has other names on apixp api2003es) ShellDDEInit (188 has other names on api95 api98 apint4) DragQueryPoint FileMenu_InsertUsingPidl (110 has other names on apixp api2003es) IsUserAdmin (680 has other names on api2003es) Missing APIs ------------ The script only reports an API as missing if it is present on all platforms but missing from Wine's spec file. That's per Wine's policy to not add APIs that are only present on newer platforms unless we have a good reason to. These 2 APIs are missing: SHInvokePrinterCommandW SHInvokePrinterCommandA -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ RFC 2549: ftp://ftp.isi.edu/in-notes/rfc2549.txt IP over Avian Carriers with Quality of Service

2 5

Re: Should winecfg drive detection create device symlinks
by Michael Jung 23 Feb '05

23 Feb '05

On Wednesday 23 February 2005 08:40, Paul van Schayck wrote: > <mjung(a)iss.tu-darmstadt.de> wrote: > > I think winecfg does this already. Take a look at the function > > apply_drive_functions in drive.c. Does'nt it work for you? > > As far as I can tell it does not. We do not store the device node path > in the detect functions so I see no way we make symlinks from > dosdevices/ to device nodes. Sorry, I misunderstood you. > Yeah, the auto detect works here just fine (symlinks are created). > Just one problem I haven't come up with a sollution yet. My floppy has > as fs type in fstab 'auto'. This means my floppy comes up as a fixed > harddrive. I have the same problem for my cdrom. As a heuristic, how about the following: If fs type is auto and the referenced device node is /dev/fd*, we assume it's a floppy. If fs type is auto and the referenced device node is not /dev/fd*, we assume it's a cdrom. Are floppies always mapped to /dev/fd* or are there other valid device nodes? How about BSD/Solaris? Bye, -- Michael Jung mjung(a)iss.tu-darmstadt.de

1 0