- wine-devel - winehq.org

RE: Cryptographic functions
by Rolf Kalbermatter 16 Sep '04

16 Sep '04

Alexander Yaworsky wrote: >there is some secret crypto API in 2k and xp. Not so long ago i played >with native rsaenh.dll under wine and found that it requires >md5 and sha functions exported by advapi32.dll. I don't know where >this API really should be. Latest platform SDK is very cryptic >itself. Just in case here is a patch. IMHO it worths to be submitted >but i'm not sure. My Advapi32.dll Ver 5.0.2195.6876 from W2K SP4 does not export these functions at all. Not even as delayed exports or forwards, at least by name. Not sure about ordinals. Rolf Kalbermatter

3 2

Re: Tooltips: Use Unicode Window Messages
by Dmitry Timoshkov 16 Sep '04

16 Sep '04

"Robert Shearman" <rob(a)codeweavers.com> wrote: > static LRESULT > TOOLTIPS_OnWMGetText (HWND hwnd, WPARAM wParam, LPARAM lParam) > { > TOOLTIPS_INFO *infoPtr = TOOLTIPS_GetInfoPtr (hwnd); > + LRESULT res; > + LPWSTR pszText = (LPWSTR)lParam; > > - if(!infoPtr || !(infoPtr->szTipText)) > + if(!(infoPtr->szTipText)) > return 0; > > - return WideCharToMultiByte(CP_ACP, 0, infoPtr->szTipText, -1, > - (LPSTR)lParam, wParam, NULL, NULL); > + res = min(strlenW(infoPtr->szTipText)+1, wParam); > + memcpy(pszText, infoPtr->szTipText, res*sizeof(WCHAR)); > + pszText[res-1] = '\0'; > + return res-1; What happens if wParam == 0? -- Dmitry.

2 1

Re: Other W->A crosscalls
by Tony Lambregts 16 Sep '04

16 Sep '04

Michael Stefaniuc wrote >Corrected script and output files are attached. Now they are only 178 >lines of output which brings us damn near to Dimi's number. Once I got rid of the duplicate calls I ended up with 130. Changelog: update Janitorial template to reflect the true number of A->W crosscalls Tony Lambregts Index: janitorial.template =================================================================== RCS file: /home/wine/lostwages/templates/en/janitorial.template,v retrieving revision 1.42 diff -u -u -r1.42 janitorial.template --- janitorial.template 15 Sep 2004 20:02:38 -0000 1.42 +++ janitorial.template 16 Sep 2004 04:34:48 -0000 @@ -196,65 +196,145 @@ The ASCII to Unicode conversion is lossy; moreover, with the shift to Unicode, it's actually slower to deal in ASCII than in Unicode, because of the additional conversions required. - There are 54 cross calls from Unicode to ANSI as reported by + There are 130 cross calls from Unicode to ANSI as of September 15, 2004. + + winapi_check <tt>tools/winapi_check/winapi_check --none --progress --cross-call-unicode-ascii</tt> - (as of Aug 12, 2004): + does not catch all cross calls. + however <a href="http://www.winehq.org/hypermail/wine-devel/2004/09/0452.html">wine_crosscalls.pl</a> + by Michael Stefaniuc seems to be more thorough. + <ul> - <li class=submitted>dlls/advapi32/crypt.c: advapi32: CryptAcquireContextW: illegal call to CryptAcquireContextA - <li class=submitted>dlls/advapi32/crypt.c: advapi32: CryptEnumProviderTypesW: illegal call to CryptEnumProviderTypesA - <li class=committed>dlls/advapi32/crypt.c: advapi32: CryptEnumProvidersW: illegal call to CryptEnumProvidersA - <li class=submitted>dlls/advapi32/crypt.c: advapi32: CryptGetDefaultProviderW: illegal call to CryptGetDefaultProviderA - <li class=submitted>dlls/advapi32/crypt.c: advapi32: CryptSetProviderExW: illegal call to CryptSetProviderExA - <li>dlls/ddraw/main.c: ddraw: DirectDrawEnumerateExW: illegal call to DirectDrawEnumerateExA - <li>dlls/gdi/printdrv.c: gdi32: StartDocW: illegal call to HEAP_strdupWtoA - <li>dlls/gdi/printdrv.c: gdi32: StartDocW: illegal call to StartDocA - <li>dlls/kernel/comm.c: kernel32: CommConfigDialogW: illegal call to CommConfigDialogA - <li>dlls/kernel/comm.c: kernel32: CommConfigDialogW: illegal call to HEAP_strdupWtoA - <li>dlls/kernel/comm.c: kernel32: SetDefaultCommConfigW: illegal call to HEAP_strdupWtoA - <li>dlls/kernel/comm.c: kernel32: SetDefaultCommConfigW: illegal call to SetDefaultCommConfigA - <li>dlls/kernel/locale.c: kernel32: GetLocaleInfoW: illegal call to GetModuleHandleA - <li>dlls/kernel/sync.c: kernel32: WaitNamedPipeW: illegal call to CreateEventA - <li>dlls/lzexpand/lzexpand_main.c: lz32: LZOpenFileW: illegal call to LZOpenFileA - <li>dlls/rpcrt4/rpc_binding.c: rpcrt4: RpcBindingToStringBindingW: illegal call to RpcBindingToStringBindingA - <li>dlls/rpcrt4/rpc_binding.c: rpcrt4: RpcBindingToStringBindingW: illegal call to RpcStringFreeA - <li>dlls/rpcrt4/rpc_server.c: rpcrt4: RpcServerUseProtseqEpExW: illegal call to RPCRT4_strdupWtoA - <li>dlls/shell32/shell32_main.c: shell32: ShellAboutW: illegal call to DialogBoxIndirectParamA - <li>dlls/shell32/shell32_main.c: shell32: ShellAboutW: illegal call to HEAP_strdupWtoA - <li>dlls/shell32/shell32_main.c: shell32: ShellAboutW: illegal call to LoadIconA - <li>dlls/shell32/shellole.c: shell32: DragQueryFileW: illegal call to DragQueryFileA - <li>dlls/shell32/systray.c: shell32: Shell_NotifyIconW: illegal call to Shell_NotifyIconA - <li>dlls/shlwapi/string.c: shlwapi: StrCmpLogicalW: illegal call to SHLWAPI_ChrCmpHelperA - <li>dlls/shlwapi/string.c: shlwapi: StrFormatByteSizeW: illegal call to StrFormatByteSize64A - <li>dlls/shlwapi/string.c: shlwapi: StrRetToStrW: illegal call to SHStrDupA - <li>dlls/version/install.c: version: VerInstallFileW: illegal call to VerInstallFileA - <li>dlls/winmm/driver.c: winmm: OpenDriverW: illegal call to OpenDriverA - <li>dlls/winmm/joystick.c: winmm: joyGetDevCapsW: illegal call to joyGetDevCapsA - <li>dlls/winmm/mci.c: winmm: mciSendStringW: illegal call to mciSendStringA - <li>dlls/winmm/mmio.c: winmm: mmioRenameW: illegal call to mmioRenameA - <li>dlls/winmm/mmio.c: winmm: mmioStringToFOURCCW: illegal call to mmioStringToFOURCCA - <li>dlls/winmm/winmm.c: winmm: auxGetDevCapsW: illegal call to auxGetDevCapsA - <li>dlls/winmm/winmm.c: winmm: mciGetErrorStringW: illegal call to mciGetErrorStringA - <li>dlls/winmm/winmm.c: winmm: midiInGetDevCapsW: illegal call to midiInGetDevCapsA - <li>dlls/winmm/winmm.c: winmm: midiOutGetDevCapsW: illegal call to midiOutGetDevCapsA - <li>dlls/winmm/winmm.c: winmm: mixerGetControlDetailsW: illegal call to mixerGetControlDetailsA - <li>dlls/winmm/winmm.c: winmm: mixerGetDevCapsW: illegal call to mixerGetDevCapsA - <li>dlls/winmm/winmm.c: winmm: mixerGetLineControlsW: illegal call to mixerGetLineControlsA - <li>dlls/winmm/winmm.c: winmm: mixerGetLineInfoW: illegal call to mixerGetLineInfoA - <li>dlls/winmm/winmm.c: winmm: waveInGetDevCapsW: illegal call to waveInGetDevCapsA - <li>dlls/winmm/winmm.c: winmm: waveOutGetDevCapsW: illegal call to waveOutGetDevCapsA - <li>dlls/winspool/info.c: winspool.drv: AddPrinterW: illegal call to DEVMODEdupWtoA - <li>dlls/winspool/info.c: winspool.drv: AddPrinterW: illegal call to RegSetValueExA - <li>dlls/winspool/info.c: winspool.drv: DeviceCapabilitiesW: illegal call to DEVMODEdupWtoA - <li>dlls/winspool/info.c: winspool.drv: DeviceCapabilitiesW: illegal call to DeviceCapabilitiesA - <li>dlls/winspool/info.c: winspool.drv: DeviceCapabilitiesW: illegal call to HEAP_strdupWtoA - <li>dlls/winspool/info.c: winspool.drv: DocumentPropertiesW: illegal call to DEVMODEdupWtoA - <li>dlls/winspool/info.c: winspool.drv: DocumentPropertiesW: illegal call to DocumentPropertiesA - <li>dlls/winspool/info.c: winspool.drv: DocumentPropertiesW: illegal call to HEAP_strdupWtoA - <li>windows/clipboard.c: user32: GetClipboardFormatNameW: illegal call to GetClipboardFormatNameA - <li>windows/clipboard.c: user32: RegisterClipboardFormatW: illegal call to HEAP_strdupWtoA - <li>windows/clipboard.c: user32: RegisterClipboardFormatW: illegal call to RegisterClipboardFormatA - <li>windows/winhelp.c: user32: WinHelpW: illegal call to WinHelpA - <li>windows/winproc.c: user32: CallWindowProcW: illegal call to WINPROC_CallProc32WTo32A + <li class=submitted>dlls/advapi32/crypt.c CryptAcquireContextW: illegal call to CryptAcquireContextA + <li class=submitted>dlls/advapi32/crypt.c CryptEnumProviderTypesW: illegal call to CryptEnumProviderTypesA + <li class=submitted>dlls/advapi32/crypt.c CryptGetDefaultProviderW: illegal call to CryptGetDefaultProviderA + <li class=submitted>dlls/advapi32/crypt.c CryptSetProviderExW: illegal call to CryptSetProviderExA + <li>dlls/comctl32/string.c StrRStrIW: illegal call to COMCTL32_ChrCmpIA + <li>dlls/comctl32/tooltips.c TOOLTIPS_AddToolW: illegal call to SendMessageA + <li>dlls/commdlg/colordlg.c ChooseColorW: illegal call to FindResourceA + <li>dlls/commdlg/filedlg.c GetFileDialog95W: illegal call to GetCurrentDirectoryA + <li>dlls/commdlg/filedlg.c GetFileDialog95W: illegal call to SetCurrentDirectoryA + <li>dlls/commdlg/filedlg.c GetFileName31W: illegal call to GetWindowLongA + <li>dlls/commdlg/fontdlg.c FormatCharDlgProcW: illegal call to GetPropA + <li>dlls/commdlg/printdlg.c PageDlgProcW: illegal call to GetPropA + <li>dlls/commdlg/printdlg.c PageDlgProcW: illegal call to SetDlgItemTextA + <li>dlls/commdlg/printdlg.c PageDlgProcW: illegal call to SetPropA + <li>dlls/commdlg/printdlg.c PRINTDLG_ChangePrinterW: illegal call to LoadStringA + <li>dlls/commdlg/printdlg.c PRINTDLG_ChangePrinterW: illegal call to SendDlgItemMessageA + <li>dlls/commdlg/printdlg.c PRINTDLG_PS_UpdateDlgStructW: illegal call to GetDlgItemTextA + <li>dlls/commdlg/printdlg.c PRINTDLG_SetUpPaperComboBoxW: illegal call to SendDlgItemMessageA + <li>dlls/commdlg/printdlg.c PRINTDLG_SetUpPrinterListComboW: illegal call to GetDefaultPrinterA + <li>dlls/commdlg/printdlg.c PRINTDLG_SetUpPrinterListComboW: illegal call to SendDlgItemMessageA + <li>dlls/commdlg/printdlg.c PRINTDLG_UpdatePrintDlgW: illegal call to LoadStringA + <li>dlls/commdlg/printdlg.c PRINTDLG_UpdatePrintDlgW: illegal call to MessageBoxA + <li>dlls/commdlg/printdlg.c PRINTDLG_WMCommandW: illegal call to SendDlgItemMessageA + <li>dlls/commdlg/printdlg.c PRINTDLG_WMInitDialogW: illegal call to LoadIconA + <li>dlls/commdlg/printdlg.c PRINTDLG_WMInitDialogW: illegal call to LoadImageA + <li>dlls/commdlg/printdlg.c PRINTDLG_WMInitDialogW: illegal call to RegisterWindowMessageA + <li>dlls/commdlg/printdlg.c PRINTDLG_WMInitDialogW: illegal call to SendDlgItemMessageA + <li>dlls/ddraw/main.c DirectDrawEnumerateExW: illegal call to DirectDrawEnumerateExA + <li>dlls/gdi/printdrv.c StartDocW: illegal call to HEAP_strdupWtoA + <li>dlls/gdi/printdrv.c StartDocW: illegal call to StartDocA + <li>dlls/hhctrl.ocx/hhctrl.c HtmlHelpW: illegal call to MessageBoxA + <li>dlls/kernel/comm.c CommConfigDialogW: illegal call to CommConfigDialogA + <li>dlls/kernel/comm.c CommConfigDialogW: illegal call to HEAP_strdupWtoA + <li>dlls/kernel/comm.c SetDefaultCommConfigW: illegal call to HEAP_strdupWtoA + <li>dlls/kernel/comm.c SetDefaultCommConfigW: illegal call to SetDefaultCommConfigA + <li>dlls/kernel/resource.c FindResourceExW: illegal call to get_res_name_type_WtoA + <li>dlls/lzexpand/lzexpand_main.c GetExpandedNameW: illegal call to GetExpandedNameA + <li>dlls/lzexpand/lzexpand_main.c LZOpenFileW: illegal call to LZOpenFileA + <li>dlls/rpcrt4/rpc_binding.c RpcBindingToStringBindingW: illegal call to RpcBindingToStringBindingA + <li>dlls/rpcrt4/rpc_binding.c RpcBindingToStringBindingW: illegal call to RpcStringFreeA + <li>dlls/rpcrt4/rpc_binding.c RPCRT4_CompleteBindingW: illegal call to RPCRT4_strdupWtoA + <li>dlls/rpcrt4/rpc_binding.c RPCRT4_CompleteBindingW: illegal call to RPCRT4_strndupA + <li>dlls/rpcrt4/rpc_binding.c RPCRT4_CreateBindingW: illegal call to RPCRT4_strdupWtoA + <li>dlls/rpcrt4/rpc_server.c RpcServerUseProtseqEpExW: illegal call to RPCRT4_strdupWtoA + <li>dlls/secur32/secur32.c SECUR32_findPackageW: illegal call to _makeFnTableA + <li>dlls/secur32/thunks.c thunk_AcquireCredentialsHandleW: illegal call to AcquireCredentialsHandleA + <li>dlls/secur32/thunks.c thunk_ImportSecurityContextW: illegal call to ImportSecurityContextA + <li>dlls/shell32/pidl.c SHELL_GetPathFromIDListW: illegal call to lstrlenA + <li>dlls/shell32/shell32_main.c ShellAboutW: illegal call to FindResourceA + <li>dlls/shell32/shellole.c DragQueryFileW: illegal call to DragQueryFileA + <li>dlls/shell32/systray.c Shell_NotifyIconW: illegal call to Shell_NotifyIconA + <li>dlls/shlwapi/ordinal.c DragQueryFileWrapW: illegal call to LoadLibraryA + <li>dlls/shlwapi/ordinal.c ExtractIconExWrapW: illegal call to LoadLibraryA + <li>dlls/shlwapi/ordinal.c ExtractIconWrapW: illegal call to LoadLibraryA + <li>dlls/shlwapi/ordinal.c ExtTextOutWrapW: illegal call to LoadLibraryA + <li>dlls/shlwapi/ordinal.c GetFileVersionInfoSizeWrapW: illegal call to LoadLibraryA + <li>dlls/shlwapi/ordinal.c GetFileVersionInfoWrapW: illegal call to LoadLibraryA + <li>dlls/shlwapi/ordinal.c GetOpenFileNameWrapW: illegal call to LoadLibraryA + <li>dlls/shlwapi/ordinal.c GetSaveFileNameWrapW: illegal call to LoadLibraryA + <li>dlls/shlwapi/ordinal.c PageSetupDlgWrapW: illegal call to LoadLibraryA + <li>dlls/shlwapi/ordinal.c PlaySoundWrapW: illegal call to LoadLibraryA + <li>dlls/shlwapi/ordinal.c PrintDlgWrapW: illegal call to LoadLibraryA + <li>dlls/shlwapi/ordinal.c SHBrowseForFolderWrapW: illegal call to LoadLibraryA + <li>dlls/shlwapi/ordinal.c SHCreateWorkerWindowW: illegal call to LoadCursorA + <li>dlls/shlwapi/ordinal.c SHCreateWorkerWindowW: illegal call to SetWindowLongA + <li>dlls/shlwapi/ordinal.c SHCreateWorkerWindowW: illegal call to SHCreateWorkerWindowA + <li>dlls/shlwapi/ordinal.c SHDefExtractIconWrapW: illegal call to LoadLibraryA + <li>dlls/shlwapi/ordinal.c ShellExecuteExWrapW: illegal call to LoadLibraryA + <li>dlls/shlwapi/ordinal.c SHFileOperationWrapW: illegal call to LoadLibraryA + <li>dlls/shlwapi/ordinal.c SHGetFileInfoWrapW: illegal call to LoadLibraryA + <li>dlls/shlwapi/ordinal.c SHGetNewLinkInfoWrapW: illegal call to LoadLibraryA + <li>dlls/shlwapi/ordinal.c SHGetPathFromIDListWrapW: illegal call to LoadLibraryA + <li>dlls/shlwapi/ordinal.c SHStringFromGUIDW: illegal call to SHStringFromGUIDA + <li>dlls/shlwapi/ordinal.c VerQueryValueWrapW: illegal call to LoadLibraryA + <li>dlls/shlwapi/ordinal.c WNetGetLastErrorWrapW: illegal call to LoadLibraryA + <li>dlls/shlwapi/ordinal.c WNetRestoreConnectionWrapW: illegal call to LoadLibraryA + <li>dlls/shlwapi/path.c PathIsNetworkPathW: illegal call to LoadLibraryA + <li>dlls/shlwapi/string.c StrCmpLogicalW: illegal call to SHLWAPI_ChrCmpHelperA + <li>dlls/shlwapi/string.c StrFormatByteSizeW: illegal call to StrFormatByteSize64A + <li>dlls/shlwapi/string.c StrRetToStrW: illegal call to SHStrDupA + <li>dlls/shlwapi/string.c StrRStrIW: illegal call to ChrCmpIA + <li>dlls/shlwapi/url.c ParseURLW: illegal call to lstrlenA + <li>dlls/user/message.c PeekMessageW: illegal call to GetClassLongA + <li>dlls/version/install.c VerInstallFileW: illegal call to VerInstallFileA + <li>dlls/wininet/internet.c InternetCheckConnectionW: illegal call to InternetCheckConnectionA + <li>dlls/winmm/driver.c OpenDriverW: illegal call to OpenDriverA + <li>dlls/winmm/joystick.c joyGetDevCapsW: illegal call to joyGetDevCapsA + <li>dlls/winmm/mci.c mciSendStringW: illegal call to mciSendStringA + <li>dlls/winmm/mmio.c mmioRenameW: illegal call to mmioRenameA + <li>dlls/winmm/mmio.c mmioStringToFOURCCW: illegal call to mmioStringToFOURCCA + <li>dlls/winmm/winmm.c auxGetDevCapsW: illegal call to auxGetDevCapsA + <li>dlls/winmm/winmm.c mciGetErrorStringW: illegal call to mciGetErrorStringA + <li>dlls/winmm/winmm.c mciSendCommandW: illegal call to MCI_MapMsgWtoA + <li>dlls/winmm/winmm.c mciSendCommandW: illegal call to MCI_UnmapMsgWtoA + <li>dlls/winmm/winmm.c mciSendCommandW: illegal call to mciSendCommandA + <li>dlls/winmm/winmm.c midiInGetDevCapsW: illegal call to midiInGetDevCapsA + <li>dlls/winmm/winmm.c midiOutGetDevCapsW: illegal call to midiOutGetDevCapsA + <li>dlls/winmm/winmm.c mixerGetControlDetailsW: illegal call to mixerGetControlDetailsA + <li>dlls/winmm/winmm.c mixerGetDevCapsW: illegal call to mixerGetDevCapsA + <li>dlls/winmm/winmm.c mixerGetLineControlsW: illegal call to mixerGetLineControlsA + <li>dlls/winmm/winmm.c mixerGetLineInfoW: illegal call to mixerGetLineInfoA + <li>dlls/winmm/winmm.c waveInGetDevCapsW: illegal call to waveInGetDevCapsA + <li>dlls/winmm/winmm.c waveOutGetDevCapsW: illegal call to waveOutGetDevCapsA + <li>dlls/winsock/socket.c WSAStringToAddressW: illegal call to WSAStringToAddressA + <li>dlls/winspool/info.c AddPrinterW: illegal call to DEVMODEdupWtoA + <li>dlls/winspool/info.c AddPrinterW: illegal call to RegCreateKeyA + <li>dlls/winspool/info.c AddPrinterW: illegal call to RegQueryValueA + <li>dlls/winspool/info.c AddPrinterW: illegal call to RegSetValueExA + <li>dlls/winspool/info.c DeviceCapabilitiesW: illegal call to DeviceCapabilitiesA + <li>dlls/winspool/info.c DeviceCapabilitiesW: illegal call to DEVMODEdupWtoA + <li>dlls/winspool/info.c DeviceCapabilitiesW: illegal call to HEAP_strdupWtoA + <li>dlls/winspool/info.c DocumentPropertiesW: illegal call to DEVMODEdupWtoA + <li>dlls/winspool/info.c DocumentPropertiesW: illegal call to DocumentPropertiesA + <li>dlls/winspool/info.c DocumentPropertiesW: illegal call to HEAP_strdupWtoA + <li>dlls/winspool/info.c OpenPrinterW: illegal call to RegCreateKeyA + <li>programs/winedbg/winedbg.c dbg_outputW: illegal call to dbg_outputA + <li>windows/clipboard.c GetClipboardFormatNameW: illegal call to GetClipboardFormatNameA + <li>windows/clipboard.c RegisterClipboardFormatW: illegal call to HEAP_strdupWtoA + <li>windows/clipboard.c RegisterClipboardFormatW: illegal call to RegisterClipboardFormatA + <li>windows/cursoricon.c map_fileW: illegal call to CreateFileMappingA + <li>windows/defwnd.c DEFWND_ImmIsUIMessageW: illegal call to GetModuleHandleA + <li>windows/winhelp.c WinHelpW: illegal call to WinHelpA + <li>windows/winhelp.c WinHelpW: illegal call to WinHelpA + <li>windows/winproc.c CallWindowProcW: illegal call to WINPROC_CallProc32WTo32A + <li>windows/winproc.c WINPROC_MapMsg16To32W: illegal call to CREATESTRUCT16to32A + <li>windows/winproc.c WINPROC_MapMsg16To32W: illegal call to MDICREATESTRUCT16to32A + <li>windows/winproc.c WINPROC_MapMsg16To32W: illegal call to WINPROC_MapMsg16To32A + <li>windows/winproc.c WINPROC_MapMsg32ATo32W: illegal call to GetWindowLongA + <li>windows/winproc.c WINPROC_UnmapMsg16To32W: illegal call to WINPROC_UnmapMsg16To32A + <li>windows/winproc.c WINPROC_UnmapMsg32ATo32W: illegal call to GetWindowLongA </ul> <p>Please note that patches have been submitted for the <span class=submitted>italic</span> entries;

3 3

Re: Wine and industrial communication like OPC
by Bernd Lachner 16 Sep '04

16 Sep '04

>> But I have to convince my boss... >> How meny ours do you think it wood take to get DCom to work in Wine? >> 50 h / 100h / 500h / 1000h ? > Good question. I'm afraid I have no idea, it's impossible to predict. Maybe it helps, if you have a OPC server source code to see what is needed on COM/DCOM functions. You can find a free (LGPL) OPC server on the following link: http://www.ipi.ac.ru/lab43/lopc-en.html We are a small software company, and I know that some customers of us are interested in OPC on Linux in the past. There is one working solution as far as I know. It is a OPC Toolkit from Technotrend which is based on the COM/DCOM implementation EntireX of Software AG. But its not Open Source unfortunally. Some links about this: http://www.opcconnect.com/tooltech.php http://www2.softwareag.com/corporate/products/entirex/default.asp http://www.tsopc.com/modules/solutions/products.html I don't know the license cost of this products at the moment, because our customers decided not to use Linux. -- Bernd Lachner NEU: Bis zu 10 GB Speicher f�r e-mails & Dateien! 1 GB bereits bei GMX FreeMail http://www.gmx.net/de/go/mail

2 1

Re: extern variable question
by Dan Kegel 16 Sep '04

16 Sep '04

reif(a)earthlink.net wrote: > I'm trying to write a Direct Input regression test and I ran into a > problem I can't resolve (and the linker too). dinput.h defines an > extern variable: > > extern const DIDATAFORMAT c_dfDIJoystick; > > I can't find this variable in dinput.dll ... It looks like it was added about ten days ago: http://www.winehq.org/hypermail/wine-patches/2004/08/0551.html What date is your wine source tree? - Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

6 10

Re: Wine and industrial communication like OPC
by Rickard Svensson 16 Sep '04

16 Sep '04

> >> But I have to convince my boss... > >> How meny ours do you think it wood take to get DCom to work in Wine? > >> 50 h / 100h / 500h / 1000h ? > > > Good question. I'm afraid I have no idea, it's impossible to predict. > > Maybe it helps, if you have a OPC server source code to see what is needed > on COM/DCOM functions. You can find a free (LGPL) OPC server on the > following link: > > http://www.ipi.ac.ru/lab43/lopc-en.html Thank you, always good to have a LGPL version... But the big problem is DCom > We are a small software company, and I know that some customers of us are > interested in OPC on Linux in the past. There is one working solution as far > as I know. It is a OPC Toolkit from Technotrend which is based on the > COM/DCOM implementation EntireX of Software AG. But its not Open Source > unfortunally. > > Some links about this: > > http://www.opcconnect.com/tooltech.php > http://www2.softwareag.com/corporate/products/entirex/default.asp > http://www.tsopc.com/modules/solutions/products.html > > I don't know the license cost of this products at the moment, because our > customers decided not to use Linux. I gote a privet mail tipp for that Solution to, it lookt god untill I lookt at Technosoftwares "Software AG's EntireX DCOM on Linux" and AG's EntireX DCOM licens: http://www2.softwareag.com/Corporate/products/entirex/downloads/downl_exxdc… It seems like they wanted a license from all users (not just a development License), so that don't look good in our case. But they have a free vertion for non comersial use, if someone else is helpt by that... And a free trial vertion, for companies. Perhaps could be interesting to try it. Thanks for your tipp thow. /Rickard -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

Re: avifil32: use InterlockedDecrement and InterlockedIncrement instead of ++/--
by Robert Shearman 16 Sep '04

16 Sep '04

James Hawkins wrote: >Changelog > * use InterlockedDecrement and InterlockedIncrement instead of ++/-- > > > >------------------------------------------------------------------------ > >Index: dlls/avifil32/avifile.c >=================================================================== >RCS file: /home/wine/wine/dlls/avifil32/avifile.c,v >retrieving revision 1.48 >diff -u -r1.48 avifile.c >--- dlls/avifil32/avifile.c 6 Sep 2004 21:34:26 -0000 1.48 >+++ dlls/avifil32/avifile.c 16 Sep 2004 01:48:46 -0000 >@@ -284,7 +284,7 @@ > IAVIFileImpl *This = (IAVIFileImpl *)iface; > > TRACE("(%p) -> %ld\n", iface, This->ref + 1); >- return ++(This->ref); >+ return InterlockedIncrement(&This->ref); > } > > static ULONG WINAPI IAVIFile_fnRelease(IAVIFile *iface) >@@ -294,7 +294,7 @@ > > TRACE("(%p) -> %ld\n", iface, This->ref - 1); > >- if (!--(This->ref)) { >+ if (!InterlockedDecrement(&This->ref)) { > A small nitpick, but the correct way implement the Release function is this: ULONG uRefs = InterlockedDecrement(&This->ref); if (!uRefs) /* Free stuff */ return uRefs; > if (This->fDirty) { > /* need to write headers to file */ > AVIFILE_SaveFile(This); >@@ -743,7 +743,7 @@ > if (This->paf != NULL) > IAVIFile_AddRef((PAVIFILE)This->paf); > >- return ++(This->ref); >+ return InterlockedIncrement(&This->ref); > } > > static ULONG WINAPI IAVIStream_fnRelease(IAVIStream* iface) >@@ -758,7 +758,7 @@ > return 0; > } > >- This->ref--; >+ InterlockedDecrement(&This->ref); > > if (This->paf != NULL) > IAVIFile_Release((PAVIFILE)This->paf); > >

1 0

Re: Wine and industrial communication like OPC
by Rickard Svensson 16 Sep '04

16 Sep '04

----- Original Message ----- From: Mike Hearn <m.hearn(a)signal.QinetiQ.com> Date: Tue, 14 Sep 2004 10:55:47 +0100 To: Rickard Svensson <riq(a)mail.com> Subject: Re: Wine and industrial communication like OPC > > I found the DCom update for Win 98 (Se: http://www.microsoft.com/com/dcom/dcom98/download.asp?SD=GN&LN=SV&gssnb=1) > > The licens is bad: (Se: http://www.microsoft.com/com/dcom/dcom98/eula.asp) > > --- --- --- --- > > 1. GRANT OF LICENSE. This EULA grants you the following rights: > > > > * Software License. Microsoft grants you the right to make and use as many copies of the SOFTWARE PRODUCT as you have validly licensed copies of Microsoft® Windows® 98. You may also make copies of the SOFTWARE PRODUCT for backup and archival purposes. > > > > * Distribution. You may not redistribute DCOM98. > > > > --- --- --- --- > > Yes, it's not good. I'm not sure about the distribution clause: > presumably it's talking about the package itself rather than the > software but obviously IANAL. I don't know that much about licenses, but the second point seem to stop all distribution: "You may not redistribute DCOM98." > > But I have to convince my boss... > > How meny ours do you think it wood take to get DCom to work in Wine? > > 50 h / 100h / 500h / 1000h ? > > Good question. I'm afraid I have no idea, it's impossible to predict. > > I've CCd Rob as really me and Rob are the only ones who have been > hacking on the DCOM code lately. Mike has been doing some work on widl > but that wouldn't be necessary to get a wire-compatible DCOM. > > If I had to guess, I'd say we're looking at 500 man hours + OK, now I have an aproximate time to go on, and talk to my boss about. > > I'm the one who is mostly for Linux here, as I mentioned XP ersion is on the way, we have used QT to make or application. So it is > easy to migrate and there is a definite risk that all will go towards a > XP embedded variant :( > > That would be bad, but you win some you lose some .... Yes, but for me personly the Linux work in this company would probably be redused to a minimum. /Rickard -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

2 1

Re: Pager Control: Rewritten
by Dimitrie O. Paun 16 Sep '04

16 Sep '04

On Wed, Sep 15, 2004 at 07:54:44PM +0100, Robert Shearman wrote: > Hi, > > This is a large patch that rewrites a lot of the layout and button state > code in the pager control. Cool stuff. While this is still fresh in your mind, an audit against comctrl v6.0 would be good too... :) -- Dimi.

4 3

Re: Other W->A crosscalls
by Rolf Kalbermatter 16 Sep '04

16 Sep '04

Michael Stefaniuc wrote: >Ok, attached is a modified wine_crosscalls.pl script which use smatch's >abilities better. Also it includes an easy way to check for false >positives. At the moment output from the wine tests is ignored. Also *AW >functions are allowed to call *A funtions so those are excluded too. >On tests done with the wine-20040914 release we get following results: >old crosscalls script: 275 lines >new crosscalls script: 234 lines >Dimi's hand edited list: 178 lines Your list would get a tiny bit shorter (~55 items) if the "*AW calls *A" would really be excluded. (They seem only in the shell32) Rolf Kalbermatter

1 0

Re: Other W->A crosscalls
by Juan Lang 16 Sep '04

16 Sep '04

Michael wrote: > Also *AW functions are allowed to call *A funtions > so those are excluded too. There seem to be quite a few of these from shell32 still included: dlls/shell32/shellpath.c 62 PathAppendAW: call to PathAppendA dlls/shell32/shellpath.c 75 PathCombineAW: call to PathCombineA dlls/shell32/shellpath.c 85 PathAddBackslashAW: call to PathAddBackslashA dlls/shell32/shellpath.c 95 PathBuildRootAW: call to PathBuildRootA --Juan __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail

2 1

Other W->A crosscalls
by Vincent Béron 15 Sep '04

15 Sep '04

I played a bit with smatch and Wine (after reading http://people.redhat.com/mstefani/wine/smatch/), to try to get over what I mentionned in my last email (regarding winapi_check and cross-calls in parenthesis). 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). Vincent

4 6

winemaker
by Patrick Goupell 15 Sep '04

15 Sep '04

I was looking at the development tasklets for something I might be able to do. I noticed bug #230 - winemaker: Extract more information from the source files. How do I make known my interest in attempting to do this task?

4 9

RE: Cryptographic functions
by Juan Lang 15 Sep '04

15 Sep '04

Rolf wrote: > My Advapi32.dll Ver 5.0.2195.6876 from W2K SP4 does > not export these functions at all. Yeah, I didn't remember them showing up in advapi32 until XP. MSDN mentions them as part of cryptdll.dll: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devnotes/w… This also exists in XP. Perhaps XP's advapi32.dll forwards these to cryptdll? --Juan _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com

2 1

RE: Cryptographic functions
by Rolf Kalbermatter 15 Sep '04

15 Sep '04

Juan Lang wrote: >Yeah, I didn't remember them showing up in advapi32 >until XP. MSDN mentions them as part of cryptdll.dll: >http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devnotes/w… > >This also exists in XP. Perhaps XP's advapi32.dll >forwards these to cryptdll? It would make sense for this algorithme being in cryptdll instead and advapi32.dll just forwarding to it, if it really exports those symbols. MSDN talks about these functions being included as resource in cryptdll. Talk about being clear, to me they seem to be exported by name just as other functions. However W2K only contains the MD5 functions. A_SHA only seems to have gotten added to XP. Rolf Kalbermatter

1 0

Re: Shell32: Reimplement SHGetFolder functions
by Alexandre Julliard 15 Sep '04

15 Sep '04

Juan Lang <juan_lang(a)yahoo.com> writes: > +static void loadShell32(void) > +{ > + if (hShell32) > + { > + if (pMalloc) > + { > + pMalloc->lpVtbl->Release(pMalloc); > + pMalloc = NULL; > + } > + /* until it's really unloaded: */ > + while (FreeLibrary(hShell32)) > + ; I'm not sure what you are trying to do here, but this causes an infinite loop on XP (and it probably should under Wine too, since the test binary imports shell32). Also some tests fail on XP: shellpath.c:433: Test failed: SHGetFolderPath returned 0x00000000, expected 0x80070002 shellpath.c:438: Test failed: SHGetFolderLocation returned 0x00000000, expected E_FAIL shellpath.c:442: Test failed: SHGetSpecialFolderPath succeeded, expected failure shellpath.c:447: Test failed: SHGetFolderLocation returned 0x00000000, expected E_FAIL -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: msvcrt: fill _chsize, _dup, _dup2
by Andreas Mohr 15 Sep '04

15 Sep '04

Hi, On Wed, Sep 15, 2004 at 06:53:28AM +0000, JustFillBug wrote: > > Use the POSIX peer. I don't think this is correct (and if it was, then it would have been done that way already, I guess). I'm not too familiar with our msvcrt, but it looks like these functions should definitely be implemented by means of our msvcrt's file handle management: msvcrt_alloc_fd(), msvcrt_alloc_fp() and many other related functions. Reason being that if you simply dup() an fd, that this properly registered source fd (in msvcrt, that is), would end up with a cloned fd that is NOT being properly registered on the msvcrt side. To make it more obvious: _close() uses msvcrt_fdtoh(), which would most likely fail for an msvcrt-foreign fd. Would be cool if you could implement it the correct way, though. Thanks, Andreas Mohr

1 0

DirectX compatability testing -- RFC results for running a specific program
by Belxjander Serechai 15 Sep '04

15 Sep '04

Ive got a small (can be transported on floppy disk) program that has a major and drastic result effect when run on a "pure" Wine only installation against both Xfree86 4.4.0 + Xorg 6.7.0, "Oh My Goddess - Smash The Bugs" ... I am curious as to anyone else Acquiring and testing this program against another installation. Im honestly not sure whether it is specifically my own setup or some interaction problem as it does a full X system deadlock and I have no response even when attempting to ssh into my own linux system I no longer have an active second machine to SSH from. I would like to confirm whether X alone or whether there is a full kernel level runtime deadlock occuring P.S. have to thank the person who gave such an eloquient reason to ignore trying to debug/test/ find those sections of the Wine "DirectX" implimentation needing work... since I wasn't interested in using the Windows release "DirectX" components for anything more than a compatability test suite to start with... Anyone else wanting to jump in feet first without asking questions? Thanks in advance, Jeremy Sutherland

2 2

Current cvs brokeness...
by James Pellow 15 Sep '04

15 Sep '04

Hi List, Just downloaded the most recent cvs, and noticed it can't run the Office 2000 installer. I haven't tried anything else, but it looks like a general msi failure. I can't spend any time on this (shouldn't be playing with it at the office anyway...) but here is the output: fixme:font:WineEngRemoveFontResourceEx :stub fixme:font:WineEngRemoveFontResourceEx :stub fixme:msi:MsiEnableLogA 00000516 "c:\\windows\\temp\\Office 2000 Professional Setup (0002)_MsiExec.txt" 00000000 fixme:msi:MsiInstallProductW L"/I" L"" fixme:msi:MSI_OpenDatabaseW open failed r = 80004005! Installation of /I () failed. Is the msi system brocken right now? I also noticed that the common file dialog seems to be returning garbage. Try selecting a file in progman-file-execute-browse for example. Just FYI... -- ***************************** James A. Pellow, President Alent Design Solutions www.alentdesignsolutions.com (509) 526-0682 *****************************

3 3

Cryptographic functions
by Alexander Yaworsky 15 Sep '04

15 Sep '04

Hello there is some secret crypto API in 2k and xp. Not so long ago i played with native rsaenh.dll under wine and found that it requires md5 and sha functions exported by advapi32.dll. I don't know where this API really should be. Latest platform SDK is very cryptic itself. Just in case here is a patch. IMHO it worths to be submitted but i'm not sure. Index: dlls/advapi32/advapi32.spec =================================================================== RCS file: /home/wine/wine/dlls/advapi32/advapi32.spec,v retrieving revision 1.55 diff -u -r1.55 advapi32.spec --- dlls/advapi32/advapi32.spec 14 Sep 2004 19:25:35 -0000 1.55 +++ dlls/advapi32/advapi32.spec 15 Sep 2004 11:56:04 -0000 @@ -1,3 +1,6 @@ +@ stub A_SHAInit +@ stub A_SHAUpdate +@ stub A_SHAFinal @ stdcall AbortSystemShutdownA(ptr) @ stdcall AbortSystemShutdownW(ptr) @ stdcall AccessCheck(ptr long long ptr ptr ptr ptr ptr) @@ -169,6 +172,9 @@ @ stdcall MakeAbsoluteSD(ptr ptr ptr ptr ptr ptr ptr ptr ptr ptr ptr) @ stdcall MakeSelfRelativeSD(ptr ptr ptr) @ stub MapGenericMask +@ stub MD5Init +@ stub MD5Update +@ stub MD5Final @ stdcall NotifyBootConfigStatus(long) @ stdcall NotifyChangeEventLog (long long) @ stub ObjectCloseAuditAlarmA

1 0

Re: Shell32: fix DllGetVersion for newer callers
by Robert Shearman 15 Sep '04

15 Sep '04

Juan Lang wrote: >A bit better than my last version, load the version >resource from the file for DllGetVersion, and update >the version of the file to produce the same output as >before. > >ChangeLog: add support for DLLVERSIONINFO2 in >DllGetVersion, and get version info from file > >--Juan > > ... >--- dlls/shell32/Makefile.in 11 Aug 2004 23:59:07 -0000 1.84 >+++ dlls/shell32/Makefile.in 14 Sep 2004 17:16:37 -0000 >@@ -4,7 +4,7 @@ > SRCDIR = @srcdir@ > VPATH = @srcdir@ > MODULE = shell32.dll >-IMPORTS = shlwapi comctl32 user32 gdi32 advapi32 kernel32 >+IMPORTS = shlwapi comctl32 user32 gdi32 advapi32 kernel32 version > DELAYIMPORTS = ole32 > EXTRALIBS = -luuid $(LIBUNICODE) > This is *really* ugly. Create a header file with just the version numbers defined and import it from the resource file and the file that implements the DllGetVersion function and problem solved. Rob

2 2

IUnknown_Release_Proxy leading to exception
by James Hawkins 15 Sep '04

15 Sep '04

This is the final debug output when I run ICQ: wine: Unhandled exception (thread 0023), starting debugger... fixme:console:SetConsoleCtrlHandler (0x405fbab0,1) - no error checking or testing yet WineDbg starting on pid 0x24 Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x40ab8695). In 32 bit mode. q0x40ab8695 IUnknown_Release_Proxy [/home/truiken/wine/dlls/rpcrt4/cproxy.c:330] in rpcrt4: movl 0x0(%eax),%edx 330 return IUnknown_Release(This->pUnkOuter); 330 return IUnknown_Release(This->pUnkOuter); Wine-dbg>l syntax error Wine-dbg>list 330 return IUnknown_Release(This->pUnkOuter); 331 #endif 332 } 333 in reading the comments, the interface refcounting is commented out and object refcounting is what is being used. i added a refCount variable to cproxy.c and did refCount++ and refCount-- in IUnknown_Release_Proxy and IUnknown_AddRef_Proxy with additional trace statements that show the value of refCount. right before the exception, a trace shows refCount to be -1. This is the log of trace+relay,ole: 045:Call kernel32.InterlockedDecrement(41277154) ret=00405614 0045:Ret kernel32.InterlockedDecrement() retval=0000000b ret=00405614 0045:Call kernel32.InterlockedDecrement(00637d80) ret=0040561b 0045:Ret kernel32.InterlockedDecrement() retval=00000042 ret=0040561b trace:ole:ObjectStubless (0x4311b3c4)->(5)([4 bytes]) ret=143db323 fixme:ole:RPCRT4_NdrClientCall2 (pStubDec == ^0x2476aa98,pFormat = ^0x2476a626,...): stub 0045:Call rpcrt4.IUnknown_Release_Proxy(4311b3c4) ret=00484779 trace:ole:IUnknown_Release_Proxy refCount: -1 trace:ole:IUnknown_Release_Proxy (0x4311b3c0)->Release() MIBDBCovnert 0045:Call kernel32.UnhandledExceptionFilter(406cdd6c) ret=4090f2b8 Any thoughts? -- James Hawkins

3 2

wine / dlls / itss / itss.c -> ICOM_THIS() macro is defined where ?
by Belxjander Serechai 15 Sep '04

15 Sep '04

I have currently for the last several days been attempting to update my local installation of wine and found that I get blocked by this... Apparently where this macro is used causes errors, is this a possible regression or something was missed at somepoint? Thanks in advance, Jeremy

2 1

include/wine/port.h and socklen_t breakage
by Gerald Pfeifer 15 Sep '04

15 Sep '04

The following change to include/wine/port.h revision 1.58 date: 2004/09/03 18:30:28; author: julliard; state: Exp; lines: +3 -0 Added configure check for socklen_t. +#ifndef HAVE_SOCKLEN_T +typedef unsigned int socklen_t; +#endif causes the following build failure on an old version of FreeBSD 5.1, and probably other systems as well. gmake[1]: Entering directory `/home/gerald/wine/loader' /usr/bin/gcc -c -I. -I. -I../include -I../include -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o kthread.o kthread.c In file included from kthread.c:41: /usr/include/sys/socket.h:77: error: redefinition of `socklen_t' ../include/wine/port.h:65: error: `socklen_t' previously declared here gmake[1]: *** [kthread.o] Error 1 The issue here is that socklen_t is defined in /usr/include/sys/socket.h, but ac_include_default in the configure script does not contain this dir. Which means that HAVE_SOCKLEN_T will be undefined, but once you include /usr/include/sys/socket.h, you'll get the conflict with our port.h. Gerald

1 0

Directx9
by Ann and Jason Edmeades 15 Sep '04

15 Sep '04

Hello, I've spoken with the wine-d3d people and noone is currently doing anything on directx9 support. Originally Raphael was trying to merge things into a new library, wined3d, using an interface which ddraw could also use. This has not happened, and as we stand there is no progress being made. Now, I know nothing about d3d9 support - I have started to see what would be the easiest way to implement this, and have come up with a couple of options, and am after some advice.... 1. (My preference) d3d8 and d3d9 are very similar in lots of respects. I would like to move all the GL code into the wined3d library, effectively factorizing d3d8 and d3d9. However, this would mean extra function call overhead for dx8 and I really dont know how common they will be. Obviously d3d8 will change during such a transition 2. I could implement d3d9 from scratch. This would have the advantage of being a standalone library and wont affect d3d8, but a disadvantage of having to fix anything twice, and probably they will get out of sync really quickly. Also, d3d8 still has parts missing, and I'd prefer a single implementation if possible. If we did this, wined3d could be deleted and a huge code duplication would be required (or 3.... Do nothing, and see if anyone else takes up the gauntlet.) Now, I am not a 3d graphics programmer - I learnt d3d8 as I implemented it (for wine) out of interest to see how things were done. I am happy to try to do the same for d3d9, and would prefer approach (1). I have a few concerns though - Mostly I havent done enough research to know if its possible, and I may end up having a shared library with 2 implementations anyway... I havent found any major stumbling block yet, but I havent researched it far enough either. My other concern is if I start doing it and have to give up due to work or other pressures, I could leave a half migrated setup. I assume its relavitevly easy with cvs to back out changes if this occurs, and I hope it wont, but it is a concern. I'd appreciate thoughts before I start (especially Lionels, AJ's etc) - I'm only just getting back into wine programming again hence my interest. Jason

9 16

Re: Re: Directx9
by brettholcomb＠charter.net 14 Sep '04

14 Sep '04

You're right - even MS can't do it - witness SP 2 for XP <G>. The important apps are core apps - Office, IE, etc., some of the more important apps like the big name games - Half Life <G>. However, it would be nice to know that if I'm running stable release xyz and I upgrade to stable xyz + 1 the apps it would run will still run or at least the chance of breakage is much much less than now. Right now if I run a release, then move to the next many things break. Things will always break to some extent but it seems to have gotten worse lately. I guess what really bothered me is the comment about breaking things and users would just have to live with it until it got fixed whenever. As I said, my objective is to move as much as I can off Windows and I have run wine-cvs and submitted some bugs and data to help debug the regression and I understand wine isn't ready for real use yet. Unfortunately, I don't have the time to do a lot of that so I've essentially dropped Wine and f! igure I'll either wait until someday I can have a release that doesn't break too much between updates or stay with Windows. This is probably what many others have done, too. Don't get me wrong - the Wine team has a very difficult task and has done very well and been responsive but the let 'em use it broke or eat cake approach is not so good. It would help to have a list like you suggest. That would at least let me know that if I have app z which is not on the list and want to run it then it's my problem if the next release breaks. > > From: Lionel Ulmer <lionel.ulmer(a)free.fr> > Date: 2004/09/14 Tue PM 04:32:52 GMT > To: brettholcomb(a)charter.net > CC: wine-devel(a)winehq.com > Subject: Re: Re: Directx9 > > > To be honest, Wine isn't going to be very useful and adopted until > > there is something that a user can install and know that if I have to update > > to a current verson and I pick the stable version that my apps that are > > running will continue to run. > > Well, you perfectly summed up the 'tragedy' of Wine: nobody ever knows what > YOUR applications are... There are so many Win32 applications that Wine > might run one day and so many Win32 APIs and interactions between them that

1 0

Re: Correct ConvertSidToStringSidW with test
by Alexandre Julliard 14 Sep '04

14 Sep '04

Juan Lang <juan_lang(a)yahoo.com> writes: > ChangeLog: fix ConvertSidToStringSidW for all expected > values, and add tests The tests fail for me on XP SP1 (I added some debug output): security.c:85: Test failed: failed to parse sid string S-1-860116326 err 1337 security.c:85: Test failed: failed to parse sid string S-1-16909060 err 1337 security.c:87: Test failed: string sid didn't parse to expected value security.c:85: Test failed: failed to parse sid string S-1-66051 err 1337 security.c:87: Test failed: string sid didn't parse to expected value security.c:85: Test failed: failed to parse sid string S-1-258 err 1337 security.c:87: Test failed: string sid didn't parse to expected value security.c:85: Test failed: failed to parse sid string S-1-2 err 1337 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Re: Directx9
by brettholcomb＠charter.net 14 Sep '04

14 Sep '04

As a user watching this thread here's my comments - Mike is correct. I understand Wine is not to 1.0 yet (close at .9 <G>) but we need something that is stable and that we can run while development is done in the unstable branch. To be honest, Wine isn't going to be very useful and adopted until there is something that a user can install and know that if I have to update to a current verson and I pick the stable version that my apps that are running will continue to run. At one time Wine was like this but in the last year it's gotten so that things that work don't anymore. I have submitted bugs and done some regression testing but let's be honest - most don't have the skills, time or desire to do that but they want to move apps to Linux. If anyone wants to use Wine for serious work to run apps they need then they won't use Wine. Some may go to Crossover, others will just drop it and either go Windows for those systems or forget about Wine or it's derivatives. As a user comments about letting things break and that users just have to put up with ituntil they are eventually fixed scare me! Many projects have stable source that is intended for users and those who want to actually do something useful with the application and then they also have CVS which is for those who want to try out the latest, help fix bugs, etc. > > From: Mike Hearn <m.hearn(a)signal.QinetiQ.com> > Date: 2004/09/14 Tue PM 12:59:45 GMT > I don't think it's about features. It's more about buggyness, and having > popular apps work. Having a stabilisation period where only regression > fixes are allowed on a particular branch could help with that. > > > After all I don't think our Wine CVS is THAT broken/problematic (the > > test suite should help here, too! Why not improve that one for a change?), > > and if people want that extra bit of stability, then they're very > > well-advised to go with CXO (or do you want to deprive CodeWeavers > > of their well-earned money? ;-)). > > Hehe, of course not :) I'm not volunteering to do any of this, at least > not right now! If Jeremy wanted to push Wine 0.9/1.0 forward then yes > I'd be happy to work on it but right now I don't have the time, and what > time I do have all goes on bugfixes and stabilisation for CrossOver. > > Anyway. The fact that CrossOver is a successful product perhaps says > something about the value of stable releases. > > > Even just thinking of the extra 700MB compiled code on my HDD resulting from > > two branches worries me a bit. ;-) > > Nobody is saying you have to use it, I'm sure most kernel developers > don't have both 2.4 and 2.6 installed at once. > > > Not to mention that I believe that the kernel and KDE projects have a > > drastically larger developer audience than Wine, so they can easily afford > > having some people do the branch maintenance. > > No, it's just a matter of willpower. Even small projects can do > stable/unstable releases. Indeed, KDE basically is just a collection of > smaller projects. > > > So at this point in time I still think that doing stable/unstable branching > > would be the entirely wrong thing to do. > > What point in time would it be the right thing to do? > > For me, the right time is "whenever Jeremy says it is" :) But, with my > community hat on, it's something that should be addressed at some point.

2 1

Re: Add IconsDir entry to config
by Marcus Meissner 14 Sep '04

14 Sep '04

On Tue, Sep 14, 2004 at 11:53:53AM -0400, Vincent Béron wrote: > Marcus patch for winemenubuilder has been commited, but for almost all > users the icons will end up in c:\windows\temp for a lack of an IconsDir > entry in config. I don't find that location suitable for long-term > storage of icons. > This is still not perfect as most new users don't use config anymore. wineshelllink will copy them out I guess, won't it? Ciao, Marcus

1 0

Re: MLANG: use Interlocked* in AddRef and Release
by Daniel Remenak 14 Sep '04

14 Sep '04

On Tue, 14 Sep 2004 18:56:40 +0900, Mike McCormack <mike(a)codeweavers.com> wrote: > > ChangeLog: > * use Interlocked* functions in AddRef and Release > <snip> > > static ULONG WINAPI fnIEnumCodePage_Release( > IEnumCodePage* iface) > { > ICOM_THIS_MULTI(EnumCodePage_impl, vtbl_IEnumCodePage, iface); > - ULONG ref = --This->ref; > + ULONG ref = InterlockedIncrement(&This->ref); operator-- changed to InterlockedIncrement instead of InterlockedDecrement. Is that intentional? --Daniel

1 0

Re: Wine and industrial communication like OPC
by Rickard Svensson 14 Sep '04

14 Sep '04

Hallo, sorry I didet awnser in a wile. Some discussion about the company at work on end license per system and so on. License issues isn't fun but ok I can tell you some more. Perhaps someone who knows more about license issues can contribute with something. Our company makes an embedded computer for general use, the first OS that it supported was Linux (an embedded minimum Debian about 10 mb + our app), which we have a customer that uses now. Now a colleague is working on a XP embedded version (is about 70 mb) Our company mostly works with Windows because most of our customers only use Windows. We don't sell any computers with Windows (we don't get bulk deals). We are mostly a software development company. The general industrial application we have made is good, most of our customers doesn't know that it is running Linux, and those who know likes it. But then the demand for OPC increased... In our case the cost of buying a OPC API for Linux perhaps could be economically reasonably, it depends on the amount of Linux computers with OPC we would sell. * 3000-4000$ / numbers of system * A fixed price for Windows licenses to be able to use the Win 98 DCom update. Win License prize * numbers of systems I am now doing some programming task and looking at our options. How does the API we can by from vendors to get OPC on Linux work and cost now. I found the DCom update for Win 98 (Se: http://www.microsoft.com/com/dcom/dcom98/download.asp?SD=GN&LN=SV&gssnb=1) The licens is bad: (Se: http://www.microsoft.com/com/dcom/dcom98/eula.asp) --- --- --- --- 1. GRANT OF LICENSE. This EULA grants you the following rights: * Software License. Microsoft grants you the right to make and use as many copies of the SOFTWARE PRODUCT as you have validly licensed copies of Microsoft® Windows® 98. You may also make copies of the SOFTWARE PRODUCT for backup and archival purposes. * Distribution. You may not redistribute DCOM98. --- --- --- --- The solution that companies like ours that have an interest in OPC collaborates to make a DCom part for Linux through Wine like Mike Hearn and Michael Chang suggested is the one I would go for! But I have to convince my boss... How meny ours do you think it wood take to get DCom to work in Wine? 50 h / 100h / 500h / 1000h ? I'm the one who is mostly for Linux here, as I mentioned XP version is on the way, we have used QT to make or application. So it is easy to migrate and there is a definite risk that all will go towards a XP embedded variant :( From: Mike Hearn <m.hearn(a)signal.QinetiQ.com> Date: Tue, 07 Sep 2004 10:14:50 +0100 To: Rickard Svensson <riq(a)mail.com> Subject: Re: Wine and industrial communication like OPC > > Yyyy! > > I hate license issues! > > I can see that for many people this wouldn't be an issue, because they probably have some old Win 98 CD/Licens somewhere (if they even care). > > But for a company that would like to send it as part of an embedded computer with Linux I can se a lot of problems. > > OK. I don't really know the details of licensing in embedded scenarios > but I can see it would cause problems. > > > But that was per development project, not per system we want to use OPC in. > > Ah, I see. Surely if you depend on Windows though you *already* have to > pay for Windows on a per-system basis? No? Or do you get bulk deals ... > > > That is good ;-) > > In the industry we are a lot of people who really question the total madness of letting the OPC standard be that depended on Windows, when it is supposed to be a "free" organization. > > > > My hope if I can get this to work is to publish a site on the net so all who want to use Linux in the industrial computing can do that quite easy... > > But then we have the license issues to :-( > > Yes. Unfortunately there are (as far as I know) only 4 DCOM > implementations in the world: > > 1) the one in Microsoft Windows > 2) DCOM for UNIX, which is based on Microsofts code > 3) Wines > 4) Cedegas (this is similar to Wines but more advanced, at least for > InstallShield support) > > The only one that is under a liberal license is Wines which is > incomplete. The only way to solve this problem is by having a > free-as-in-speech implementation of DCOM, which means extending and > improving Wine. > > > Ok, now I understand, and also why I got confused before. > > > > And there is a lot of work needed to make DCom to work in Wine? > > Is someone working on it or is it something that not is that important in other cases? > > Yes, it's a fair amount of work. Currently nobody is working on it as > their primary project - Rob Shearman and I did some work on it for > iTunes/InstallShield support lately and most of our code is motivated by > InstallShield. > > It is something that we want to do though, because we currently depend > on native DCOM for a lot of stuff, like installers/office embedding/etc > etc ... so there's interest there at least from CodeWeavers side. But > we're certainly not committed to anything. > > One possible plan is this: if it is true that there is general, > widespread concern over OPC depending on Windows in the industry, > perhaps you could get together with other companies and form a > consortium to fund the development of an LGPLd DCOM implementation in > Wine. This would allow you to write DCOM based software anywhere that > Wine runs and be independent of Microsoft and licensing costs. > > I think if funding was available in the right amounts Jeremy could be > persuaded to have CW at least put some hours into it and I know at least > one guy from ReactOS wants to work on it too. But I can't say for sure. > > Anyway, it was just a thought. > > thanks -mike -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

2 1

Re: resend: patch: shell32.dll - SHELL_ArgifyW expands env-vars
by Alexandre Julliard 14 Sep '04

14 Sep '04

"Jens Collin" <jens.collin(a)lakhei.com> writes: > + { > + TRACE("The env. var can't be found or is bigger than MAX_PATH => useless."); > + res += sprintfW(res, L"%s%%", tmpBuffer); You cannot use Unicode strings constants in Wine, they don't have the right size. -- Alexandre Julliard julliard(a)winehq.org

5 6

Re: Rename keyword variable
by Alexandre Julliard 14 Sep '04

14 Sep '04

Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> writes: > Hi, > > "template" is a keyword on c++, so better rename it to menu_template. We've been through this before; there's absolutely no reason to do that. -- Alexandre Julliard julliard(a)winehq.org

2 1

Why is our OutputDebugString a server request?
by Shachar Shemesh 14 Sep '04

14 Sep '04

Hi all, It seems that OutputDebugString is defined in the Win32 API as a set of client side operations. In wine, however, it is a server request. I have not traced it into the server to see whether they carry out the same operations or not. However, even if they do, I am wondering why we need them? Wouldn't it be better to not do server side things that can be done client side? (http://www.unixwiz.net/techtips/outputdebugstring.html) Shachar P.S. I perfectly understand that obtaining mutexes and waiting on events is a server side operation. However, it was my impression that such things are best carried out by mimicking the Win32 structure as much as possible. Isn't that the case? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

2 1

Re: Re: Why is our OutputDebugString a server request?
by Pouech Eric DMI AEI CAEN 14 Sep '04

14 Sep '04

> I get the feeling that I misunderstood what you just said. What is the > debug event? where do we do anything with it? debug events are part of the Win32 debug API. A debugger (ie a process using the client side of this API) will get "debug events" (basically the type of the event and some additional information). Such events are process created/terminated, thread created/terminated, thread stopped and so on. One of these "debug events" is the sending of a debug string (by the program being debugged). This means that running a "decent" debugger (decent meaning implementing the support for this debug event) will print all the OutputDebugString calls from the debuggee. A+

1 0

Re: Why is our OutputDebugString a server request?
by Pouech Eric DMI AEI CAEN 14 Sep '04

14 Sep '04

so that debuggers can intercept it (especially ones with GUI) and do what they want with it. A+ > Message du 13/09/04 17:50 > De : "Shachar Shemesh" > A : "Wine Development" > Copie à : > Objet : Why is our OutputDebugString a server request? >

3 3

extern variable question
by Robert Reif 14 Sep '04

14 Sep '04

I'm trying to write a Direct Input regression test and I ran into a problem I can't resolve (and the linker too). dinput.h defines an extern variable: extern const DIDATAFORMAT c_dfDIJoystick; I can't find this variable in dinput.dll but it is in dinput.lib on windows. It looks like I need to generate a dinput.a. How can I generate both a dinput.dll.so and a dinput.a from the same source?

1 0

RE: iostream and msvcrt?
by Scott Snell 14 Sep '04

14 Sep '04

Hi Dimi, Thanks for the offer but I have had the project pulled. Unfortunately I couldnt get a working model in time and the hardware has been recycled to another project ;-(. Basically I needed to compile STLport so I could use iostreams in a project I was converting to wine. I'm going to keep my eye on this list as I hope to have a new round of funding approved late in the year. I may also get an old PC at home working and have another go! thanks, scott. > -----Original Message----- > From: Dimitrie O. Paun [SMTP:dpaun@rogers.com] > Sent: Wednesday, 8 September 2004 0:06 > To: Scott Snell > Cc: Dimitrie O. Paun; Boaz Harrosh; Wine-Devel (E-mail) > Subject: Re: iostream and msvcrt? > > Just got back from vacation. Why is it including a cstdlib? > Anyway, can you send me exactly what you did, so I can try > to reproduce it on my box? > > -- > Dimi.

1 0

Re: Proper finalization in StartServiceW
by Alexandre Julliard 13 Sep '04

13 Sep '04

"Alexander Yaworsky" <yaworsky(a)migusoft.ru> writes: > + if( WAIT_FAILED == r ) > + { > + last_error = GetLastError(); > + CloseHandle( procinfo.hProcess ); > + goto done; > + } > > - ReleaseSemaphore(data, 1, NULL); > - > - if( r == WAIT_FAILED) > - return FALSE; > + /* allright */ > + CloseHandle( procinfo.hProcess ); > + last_error = 0; > + ret = TRUE; > > - return TRUE; > +done: > + CloseHandle( wait ); > + ReleaseSemaphore(data, 1, NULL); > + CloseHandle( data ); > + SetLastError( last_error ); > + return ret; You should never need to do that sort of thing. CloseHandle and ReleaseSemaphore won't change last error if they are called for valid handles, and if they are not you are just hiding a bug. Also, you very probably don't want to set last error to 0 on success, unless you have clear evidence that Windows does it in this case too. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Correct ConvertSidToStringSidW with test
by Alexandre Julliard 13 Sep '04

13 Sep '04

Juan Lang <juan_lang(a)yahoo.com> writes: > @@ -2230,13 +2232,23 @@ > > sz = 14 + pisid->SubAuthorityCount * 11; > str = LocalAlloc( 0, sz*sizeof(WCHAR) ); > - sprintfW( str, fmt, pisid->Revision, > - pisid->IdentifierAuthority.Value[2], > - pisid->IdentifierAuthority.Value[3], > - pisid->IdentifierAuthority.Value[0]&0x0f, > - pisid->IdentifierAuthority.Value[4]&0x0f, > - pisid->IdentifierAuthority.Value[1]&0x0f, > - pisid->IdentifierAuthority.Value[5]&0x0f); > + sprintfW( str, fmt, pisid->Revision ); > + for( i=2; i<=3; i++ ) > + { > + if( pisid->IdentifierAuthority.Value[i] ) > + printingIdent = TRUE; > + if( printingIdent ) > + sprintfW( str + lstrlenW( str ), identAuthFmt, > + pisid->IdentifierAuthority.Value[i] ); > + } That doesn't look right, you'd need something like %02x for the second value if the first was printed. It seems it would be a lot easier to simply build an int from the various values and then format it with a single %x. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Directx9
by Ivan Leo Puoti 13 Sep '04

13 Sep '04

> At *some* point we have to stop simply releasing CVS snapshots which may > or may not work/run important apps/eat your hard disk and actually do > proper releases that are, you know, tested'n'stuff. Also consider that the time wasted on testing/releasing/branching will slow up wine development, whoever would be doing that could certanly work on the wine code itself. I fully agree with what Joerg Mayer says, the time has not yet come. Ivan.

1 0

Re: Directx9
by Ivan Leo Puoti 13 Sep '04

13 Sep '04

>Anyway, that wasn't really what I was getting at.. last spring Lionel >had this to say about a wined3d library: It does make sense to have common code all in the same place... Ivan.

1 0

dlls/winsock/socket breakage
by Gerald Pfeifer 13 Sep '04

13 Sep '04

The following change revision 1.155 date: 2004/09/07 20:47:03; author: julliard; state: Exp; lines: +113 -0 Roderick Colenbrander <thunderbird2k(a)gmx.net> - set ipx packet type - add support for retrieving some ipx info breaks FreeBSD 4.10 quite a bit: /sw/gcc-3.3.4/bin/gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -DUSE_WS_PREFIX -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o socket.o socket.c socket.c: In function `WS2_send': socket.c:1120: error: `SOL_IPX' undeclared (first use in this function) socket.c:1120: error: (Each undeclared identifier is reported only once socket.c:1120: error: for each function it appears in.) socket.c:1120: error: `IPX_TYPE' undeclared (first use in this function) socket.c:1123: error: structure has no member named `sipx_type' socket.c: In function `WS_getsockopt': socket.c:1585: error: `SOL_IPX' undeclared (first use in this function) socket.c:1585: error: `IPX_TYPE' undeclared (first use in this function) socket.c: In function `WS_setsockopt': socket.c:2312: error: `SOL_IPX' undeclared (first use in this function) socket.c:2312: error: `IPX_TYPE' undeclared (first use in this function) gmake: *** [socket.o] Error 1 Concerning the error in socket.c, line 1120, SOL_IPX is not defined on FreeBSD 4.10, but there is a constant SOL_SOCKET which is supposed to be passed as the second parameter of getsockopt with the following description: "To manipulate options at the socket level, level is specified as SOL_SOCKET". Would that do the job? Concerning the error in socket.c, line 1123, struct sockaddr_ipx looks as follows on FreeBSD 4.10: struct sockaddr_ipx { u_char sipx_len; u_char sipx_family; struct ipx_addr sipx_addr; char sipx_zero[2]; }; Finally, I could not find anything remotely similiar to IPX_TYPE. I hope this will allow you to fix this breakage? (To check for FreeBSD, you can use #ifdef __FreeBSD_...) Thanks, Gerald -- Gerald Pfeifer (Jerry) gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

3 7

Re: Shwapi updates
by James Hawkins 13 Sep '04

13 Sep '04

Can this patch be broken up into smaller, independent parts? It's more likely to be committed if that is the case. On Sun, 12 Sep 2004 08:55:27 -0700 (PDT), Jon Griffiths <jon_p_griffiths(a)yahoo.com> wrote: > Cheers, > Jon > > +dlls/shlwapi/shlwapi.spec dlls/shlwapi/ordinal.c > Implement SHSimulateDrop > > +dlls/shlwapi/reg.c > Implement MIME_GetExtensionA/W > > +dlls/shlwapi/string.c > Implement StrCpyNXA/W, SHAnsiToAnsi, SHUnicodeToUnicode > > +dlls/shlwapi/tests/string.c > Test StrCpyNXA/W, SHAnsiToAnsi, SHUnicodeToUnicode > > ===== > "Don't wait for the seas to part, or messiahs to come; > Don't you sit around and waste this chance..." - Live > > jon_p_griffiths(a)yahoo.com > > > _______________________________ > Do you Yahoo!? > Shop for Back-to-School deals on Yahoo! Shopping. > http://shopping.yahoo.com/backtoschool > > > diff -ur wine/dlls/shlwapi/ordinal.c wine-develop/dlls/shlwapi/ordinal.c > --- wine/dlls/shlwapi/ordinal.c 2004-09-05 08:36:36.000000000 +0000 > +++ wine-develop/dlls/shlwapi/ordinal.c 2004-09-11 12:38:46.000000000 +0000 > @@ -1829,6 +1829,30 @@ > } > > /************************************************************************* > + * @ [SHLWAPI.186] > + */ > +BOOL WINAPI SHSimulateDrop(IDropTarget *pDrop, IDataObject *pDataObj, > + DWORD grfKeyState, PPOINTL lpPt, DWORD* pdwEffect) > +{ > + DWORD dwEffect = DROPEFFECT_LINK | DROPEFFECT_MOVE | DROPEFFECT_COPY; > + POINTL pt = { 0, 0 }; > + > + if (!lpPt) > + lpPt = &pt; > + > + if (!pdwEffect) > + pdwEffect = &dwEffect; > + > + IDropTarget_DragEnter(pDrop, pDataObj, grfKeyState, *lpPt, pdwEffect); > + > + if (*pdwEffect) > + return IDropTarget_Drop(pDrop, pDataObj, grfKeyState, *lpPt, pdwEffect); > + > + IDropTarget_DragLeave(pDrop); > + return TRUE; > +} > + > +/************************************************************************* > * @ [SHLWAPI.187] > * > * Call IPersistPropertyBag_Load() on an object. > @@ -3000,19 +3024,6 @@ > } > > /************************************************************************* > - * @ [SHLWAPI.346] > - */ > -DWORD WINAPI SHUnicodeToUnicode( > - LPCWSTR src, > - LPWSTR dest, > - int len) > -{ > - FIXME("(%s %p 0x%08x)stub\n",debugstr_w(src),dest,len); > - lstrcpynW(dest, src, len); > - return lstrlenW(dest)+1; > -} > - > -/************************************************************************* > * @ [SHLWAPI.350] > * > * See GetFileVersionInfoSizeW. > diff -ur wine/dlls/shlwapi/reg.c wine-develop/dlls/shlwapi/reg.c > --- wine/dlls/shlwapi/reg.c 2004-07-05 20:27:24.000000000 +0000 > +++ wine-develop/dlls/shlwapi/reg.c 2004-09-11 12:41:58.000000000 +0000 > @@ -1833,6 +1833,77 @@ > } > > /************************************************************************* > + * @ [SHLWAPI.330] > + * > + * Get the files extension for a given Mime type. > + * > + * PARAMS > + * lpszType [I] Mime type to get the file extension for > + * lpExt [O] Destingtion for the resulting extension > + * iLen [I] Length og lpExt in characters > + * > + * RETURNS > + * Success: TRUE. lpExt contains the file extension. > + * Failure: FALSE, if any paramater is invalid or the extension cannot be > + * retrieved. If iLen > 0, lpExt is set to an empty string. > + * > + * NOTES > + * - The extension returned in lpExt always has a leading '.' character, even > + * if the registry Mime database entry does not. > + * - iLen must be long enough for the file extension for this function to succeed. > + */ > +BOOL WINAPI MIME_GetExtensionA(LPCSTR lpszType, LPSTR lpExt, INT iLen) > +{ > + char szSubKey[MAX_PATH]; > + DWORD dwlen = iLen - 1, dwType; > + BOOL bRet = FALSE; > + > + if (iLen > 0 && lpExt) > + *lpExt = '\0'; > + > + if (lpszType && lpExt && iLen > 2 && > + GetMIMETypeSubKeyA(lpszType, szSubKey, MAX_PATH) && > + !SHGetValueA(HKEY_CLASSES_ROOT, szSubKey, szExtensionA, &dwType, lpExt + 1, &dwlen) && > + lpExt[1]) > + { > + if (lpExt[1] == '.') > + memmove(lpExt, lpExt + 1, strlen(lpExt + 1) + 1); > + else > + *lpExt = '.'; /* Supply a '.' */ > + bRet = TRUE; > + } > + return bRet; > +} > + > +/************************************************************************* > + * @ [SHLWAPI.331] > + * > + * Unicode version of MIME_GetExtensionA. > + */ > +BOOL WINAPI MIME_GetExtensionW(LPCWSTR lpszType, LPWSTR lpExt, INT iLen) > +{ > + WCHAR szSubKey[MAX_PATH]; > + DWORD dwlen = iLen - 1, dwType; > + BOOL bRet = FALSE; > + > + if (iLen > 0 && lpExt) > + *lpExt = '\0'; > + > + if (lpszType && lpExt && iLen > 2 && > + GetMIMETypeSubKeyW(lpszType, szSubKey, MAX_PATH) && > + !SHGetValueW(HKEY_CLASSES_ROOT, szSubKey, szExtensionW, &dwType, lpExt + 1, &dwlen) && > + lpExt[1]) > + { > + if (lpExt[1] == '.') > + memmove(lpExt, lpExt + 1, (strlenW(lpExt + 1) + 1) * sizeof(WCHAR)); > + else > + *lpExt = '.'; /* Supply a '.' */ > + bRet = TRUE; > + } > + return bRet; > +} > + > +/************************************************************************* > * @ [SHLWAPI.324] > * > * Set the file extension for a MIME content key. > diff -ur wine/dlls/shlwapi/shlwapi.spec wine-develop/dlls/shlwapi/shlwapi.spec > --- wine/dlls/shlwapi/shlwapi.spec 2004-09-05 08:36:36.000000000 +0000 > +++ wine-develop/dlls/shlwapi/shlwapi.spec 2004-09-11 12:42:10.000000000 +0000 > @@ -183,7 +183,7 @@ > 183 stdcall -noname SHRegisterClassA(ptr) > 184 stdcall @(ptr ptr long) SHLWAPI_184 > 185 stdcall -noname SHMessageBoxCheckA(ptr str str long long str) > -186 stub -noname SHSimulateDrop > +186 stdcall -noname SHSimulateDrop(ptr ptr long ptr ptr) > 187 stdcall -noname SHLoadFromPropertyBag(ptr ptr) > 188 stub -noname IUnknown_TranslateAcceleratorOCS > 189 stdcall -noname IUnknown_OnFocusOCS(ptr ptr) > @@ -327,8 +327,8 @@ > 327 stdcall -noname UnregisterExtensionForMIMETypeW(wstr) > 328 stdcall -noname GetMIMETypeSubKeyA(str ptr long) > 329 stdcall -noname GetMIMETypeSubKeyW(wstr ptr long) > -330 stub -noname MIME_GetExtensionA > -331 stub -noname MIME_GetExtensionW > +330 stdcall -noname MIME_GetExtensionA(str ptr long) > +331 stdcall -noname MIME_GetExtensionW(wstr ptr long) > 332 stdcall @(ptr long) user32.CallMsgFilterW > 333 stdcall -noname SHBrowseForFolderWrapW(ptr) > 334 stdcall -noname SHGetPathFromIDListWrapW(ptr ptr) > @@ -342,7 +342,7 @@ > 342 stdcall -noname SHInterlockedCompareExchange(ptr long long) > 343 stdcall -noname SHRegGetCLSIDKeyA(ptr str long long ptr) > 344 stdcall -noname SHRegGetCLSIDKeyW(ptr wstr long long ptr) > -345 stub -noname SHAnsiToAnsi > +345 stdcall -noname SHAnsiToAnsi(str ptr long) > 346 stdcall -noname SHUnicodeToUnicode(wstr ptr long) > 347 stdcall @(long wstr) advapi32.RegDeleteValueW > 348 stub -noname SHGetFileDescriptionW > diff -ur wine/dlls/shlwapi/string.c wine-develop/dlls/shlwapi/string.c > --- wine/dlls/shlwapi/string.c 2004-09-05 08:36:36.000000000 +0000 > +++ wine-develop/dlls/shlwapi/string.c 2004-09-11 12:43:37.000000000 +0000 > @@ -2098,7 +2098,7 @@ > * iLen [I] Maximum number of chars to copy > * > * RETURNS > - * Success: A pointer to the last character written. > + * Success: A pointer to the last character written to lpszDest.. > * Failure: lpszDest, if any arguments are invalid. > */ > LPSTR WINAPI StrCpyNXA(LPSTR lpszDest, LPCSTR lpszSrc, int iLen) > @@ -2623,6 +2623,48 @@ > } > > /************************************************************************* > + * @ [SHLWAPI.345] > + * > + * Copy one string to another. > + * > + * PARAMS > + * lpszSrc [I] Source string to copy > + * lpszDst [O] Destination for copy > + * iLen [I] Length of lpszDst in characters > + * > + * RETURNS > + * The length of the copied string, including the terminating NUL. lpszDst > + * contains iLen characters of lpszSrc. > + */ > +DWORD WINAPI SHAnsiToAnsi(LPCSTR lpszSrc, LPSTR lpszDst, int iLen) > +{ > + LPSTR lpszRet; > + > + TRACE("(%s,%p,0x%08x)\n", debugstr_a(lpszSrc), lpszDst, iLen); > + > + /* Our original version used lstrncpy/lstrlen, incorrectly filling up all > + * of lpszDst with extra NULs. This version is correct, and faster too. > + */ > + lpszRet = StrCpyNXA(lpszDst, lpszSrc, iLen); > + return lpszRet - lpszDst + 1; > +} > + > +/************************************************************************* > + * @ [SHLWAPI.346] > + * > + * Unicode version of SSHAnsiToAnsi. > + */ > +DWORD WINAPI SHUnicodeToUnicode(LPCWSTR lpszSrc, LPWSTR lpszDst, int iLen) > +{ > + LPWSTR lpszRet; > + > + TRACE("(%s,%p,0x%08x)\n", debugstr_w(lpszSrc), lpszDst, iLen); > + > + lpszRet = StrCpyNXW(lpszDst, lpszSrc, iLen); > + return lpszRet - lpszDst + 1; > +} > + > +/************************************************************************* > * @ [SHLWAPI.364] > * > * Determine if an Ascii string converts to Unicode and back identically. > diff -ur wine/dlls/shlwapi/tests/string.c wine-develop/dlls/shlwapi/tests/string.c > --- wine/dlls/shlwapi/tests/string.c 2004-07-21 12:17:03.000000000 +0000 > +++ wine-develop/dlls/shlwapi/tests/string.c 2004-09-11 12:47:14.000000000 +0000 > @@ -33,7 +33,12 @@ > #include "shlwapi.h" > #include "shtypes.h" > > -static HRESULT (WINAPI *ptr_StrRetToBSTR) (STRRET*, void*, BSTR*); > +static HMODULE hShlwapi; > +static LPSTR (WINAPI *pStrCpyNXA)(LPSTR,LPCSTR,int); > +static LPWSTR (WINAPI *pStrCpyNXW)(LPWSTR,LPCWSTR,int); > +static HRESULT (WINAPI *pStrRetToBSTR)(STRRET*,void*,BSTR*); > +static DWORD (WINAPI *pSHAnsiToAnsi)(LPCSTR,LPSTR,int); > +static DWORD (WINAPI *pSHUnicodeToUnicode)(LPCWSTR,LPWSTR,int); > > static inline int strcmpW(const WCHAR *str1, const WCHAR *str2) > { > @@ -592,22 +597,19 @@ > > static void test_StrRetToBSTR(void) > { > - HMODULE module; > static const WCHAR szTestW[] = { 'T','e','s','t','\0' }; > ITEMIDLIST iidl[10]; > BSTR bstr; > STRRET strret; > HRESULT ret; > > - module = GetModuleHandleA("shlwapi"); > - if (!module) return; > - ptr_StrRetToBSTR = (void *)GetProcAddress(module, "StrRetToBSTR"); > - if (!ptr_StrRetToBSTR) return; > + pStrRetToBSTR = (void *)GetProcAddress(hShlwapi, "StrRetToBSTR"); > + if (!pStrRetToBSTR) return; > > strret.uType = STRRET_WSTR; > strret.u.pOleStr = CoDupStrW("Test"); > bstr = 0; > - ret = ptr_StrRetToBSTR(&strret, NULL, &bstr); > + ret = pStrRetToBSTR(&strret, NULL, &bstr); > ok(ret == S_OK && bstr && !strcmpW(bstr, szTestW), > "STRRET_WSTR: dup failed, ret=0x%08lx, bstr %p\n", ret, bstr); > if (bstr) > @@ -615,7 +617,7 @@ > > strret.uType = STRRET_CSTR; > lstrcpyA(strret.u.cStr, "Test"); > - ret = ptr_StrRetToBSTR(&strret, NULL, &bstr); > + ret = pStrRetToBSTR(&strret, NULL, &bstr); > ok(ret == S_OK && bstr && !strcmpW(bstr, szTestW), > "STRRET_CSTR: dup failed, ret=0x%08lx, bstr %p\n", ret, bstr); > if (bstr) > @@ -624,7 +626,7 @@ > strret.uType = STRRET_OFFSET; > strret.u.uOffset = 1; > strcpy((char*)&iidl, " Test"); > - ret = ptr_StrRetToBSTR(&strret, iidl, &bstr); > + ret = pStrRetToBSTR(&strret, iidl, &bstr); > ok(ret == S_OK && bstr && !strcmpW(bstr, szTestW), > "STRRET_OFFSET: dup failed, ret=0x%08lx, bstr %p\n", ret, bstr); > if (bstr) > @@ -633,10 +635,85 @@ > /* Native crashes if str is NULL */ > } > > +static void test_StrCpyNXA(void) > +{ > + LPCSTR lpSrc = "hello"; > + LPSTR lpszRes; > + char dest[8]; > + > + pStrCpyNXA = (void *)GetProcAddress(hShlwapi, (LPSTR)399); > + if (!pStrCpyNXA) > + return; > + > + memset(dest, '\n', sizeof(dest)); > + lpszRes = pStrCpyNXA(dest, lpSrc, sizeof(dest)/sizeof(dest[0])); > + ok(lpszRes == dest + 5 && !memcmp(dest, "hello\0\n\n", sizeof(dest)), > + "StrCpyNXA: expected %p, \"hello\\0\\n\\n\", got %p, \"%d,%d,%d,%d,%d,%d,%d,%d\"\n", > + dest + 5, lpszRes, dest[0], dest[1], dest[2], dest[3], dest[4], dest[5], dest[6], dest[7]); > +} > + > +static void test_StrCpyNXW(void) > +{ > + static const WCHAR lpInit[] = { '\n','\n','\n','\n','\n','\n','\n','\n' }; > + static const WCHAR lpSrc[] = { 'h','e','l','l','o','\0' }; > + static const WCHAR lpRes[] = { 'h','e','l','l','o','\0','\n','\n' }; > + LPWSTR lpszRes; > + WCHAR dest[8]; > + > + pStrCpyNXW = (void *)GetProcAddress(hShlwapi, (LPSTR)400); > + if (!pStrCpyNXW) > + return; > + > + memcpy(dest, lpInit, sizeof(lpInit)); > + lpszRes = pStrCpyNXW(dest, lpSrc, sizeof(dest)/sizeof(dest[0])); > + ok(lpszRes == dest + 5 && !memcmp(dest, lpRes, sizeof(dest)), > + "StrCpyNXA: expected %p, \"hello\\0\\n\\n\", got %p, \"%d,%d,%d,%d,%d,%d,%d,%d\"\n", > + dest + 5, lpszRes, dest[0], dest[1], dest[2], dest[3], dest[4], dest[5], dest[6], dest[7]); > +} > + > +static void test_SHAnsiToAnsi(void) > +{ > + char dest[8]; > + DWORD dwRet; > + > + pSHAnsiToAnsi = (void *)GetProcAddress(hShlwapi, (LPSTR)345); > + if (!pSHAnsiToAnsi) > + return; > + > + memset(dest, '\n', sizeof(dest)); > + dwRet = pSHAnsiToAnsi("hello", dest, sizeof(dest)/sizeof(dest[0])); > + ok(dwRet == 6 && !memcmp(dest, "hello\0\n\n", sizeof(dest)), > + "SHAnsiToAnsi: expected 6, \"hello\\0\\n\\n\", got %ld, \"%d,%d,%d,%d,%d,%d,%d,%d\"\n", > + dwRet, dest[0], dest[1], dest[2], dest[3], dest[4], dest[5], dest[6], dest[7]); > +} > + > +static void test_SHUnicodeToUnicode(void) > +{ > + static const WCHAR lpInit[] = { '\n','\n','\n','\n','\n','\n','\n','\n' }; > + static const WCHAR lpSrc[] = { 'h','e','l','l','o','\0' }; > + static const WCHAR lpRes[] = { 'h','e','l','l','o','\0','\n','\n' }; > + WCHAR dest[8]; > + DWORD dwRet; > + > + pSHUnicodeToUnicode = (void *)GetProcAddress(hShlwapi, (LPSTR)346); > + if (!pSHUnicodeToUnicode) > + return; > + > + memcpy(dest, lpInit, sizeof(lpInit)); > + dwRet = pSHUnicodeToUnicode(lpSrc, dest, sizeof(dest)/sizeof(dest[0])); > + ok(dwRet == 6 && !memcmp(dest, lpRes, sizeof(dest)), > + "SHUnicodeToUnicode: expected 6, \"hello\\0\\n\\n\", got %ld, \"%d,%d,%d,%d,%d,%d,%d,%d\"\n", > + dwRet, dest[0], dest[1], dest[2], dest[3], dest[4], dest[5], dest[6], dest[7]); > +} > + > START_TEST(string) > { > CoInitialize(0); > > + hShlwapi = GetModuleHandleA("shlwapi"); > + if (!hShlwapi) > + return; > + > test_StrChrA(); > test_StrChrW(); > test_StrChrIA(); > @@ -656,4 +733,8 @@ > test_StrCmpA(); > test_StrCmpW(); > test_StrRetToBSTR(); > + test_StrCpyNXA(); > + test_StrCpyNXW(); > + test_SHAnsiToAnsi(); > + test_SHUnicodeToUnicode(); > } > > > -- James Hawkins

3 3

RE: patch: shell32.dll - SHELL_ArgifyW expands env-vars - HOLD PATCH
by Jens Collin 13 Sep '04

13 Sep '04

Please hold this patch and don't commit it yet. I've been told that it contains things to be checked first. /J -----Original Message----- From: wine-patches-admin(a)winehq.org [mailto:wine-patches-admin@winehq.org] On Behalf Of Jens Collin Sent: den 11 september 2004 21:47 To: wine-patches(a)winehq.org Subject: patch: shell32.dll - SHELL_ArgifyW expands env-vars Patch updated with correct string constants handling. thanks James and Alexandre. changelog: * lookup of envoronment-vars in SHELL_ArgifyW in shell32.dll added. (Such as %SystemRoot%).

1 0

(no subject)
by Ivan Leo Puoti 13 Sep '04

13 Sep '04

> For example, if DirectX is broken for 3 consecutive releases, I would expect > the people doing the release to label the old 'working' version and branch > from there if any bugs fixes are needed. Things in wine break all the time, users know it and are used to it, if d3d8 breaks for 3 releases, people will just use an old version until things are fixed. Many people stayed at wine-20031212 for months because of regressions that weren't fixed for a few months, but people just kept wine-20031212 and were happy. With alpha software this is quite normal. Ivan.

2 1

RE: Why is our OutputDebugString a server request?
by Raghavan Gurumurthy 13 Sep '04

13 Sep '04

I agree - I got stumped on this very issue when I got into Wine last year. I was used to relying on these trace messages and it took me a while to understand where the messages were actually being sent! //raghavan -----Original Message----- From: Shachar Shemesh [mailto:wine-devel@shemesh.biz] Sent: Monday, September 13, 2004 9:11 AM To: pouech-eric(a)wanadoo.fr Cc: Wine Development Subject: Re: Why is our OutputDebugString a server request? Pouech Eric DMI AEI CAEN wrote: > so that debuggers can intercept it (especially ones with GUI) and do > what they want with it. > A+ > > > > > Message du 13/09/04 17:50 > > De : "Shachar Shemesh" > > A : "Wine Development" > > Copie à : > > Objet : Why is our OutputDebugString a server request? > > > But as far as I can see, this means that Windows debuggers won't get it. Wouldn't it be better to implement it the Win32 way? At the very least, implement it ALSO as the Win32 way? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

1 0

A window update problem in Dutch tax program.
by Rein Klazes 13 Sep '04

13 Sep '04

Hi, I am looking in a display problem in the electronic declaration programs of the Dutch tax office. Here is a schematic of the windows involved: +--10022-------------------------------+ | | | +--100c6-------------------------+ | | | | | ..20110... | | | . . | | | . . | | | +-20114--+ | | | | | | | | | | | | | +--------+ | | | | | | | | +--------------------------------+ +--------------------------------------+ [10022] is a top level window. One of its child [20114] has itself a child window [20110] that initially lies outside the parent client area. A series of calls to ScrollWindowEx() brings it inside, simulating a drop down listbox. Now [20114] should normally not be visible because it lies behind another child of the main window: [10022] | +--[20114] | | | +--[20110] | | +-[100c6] | + ... No window styles that could affect this behavior (WS_CLIPCHILDREN, WS_CLIPSIBLINGS, WS_EX_TRANSPARENT) are used. Here the partial output of info wnd command: 00010022 WindowIB2003 14cb0000 00000000 Aangifte 2003 00020114 WindowIB2003 50000000 00000000 -- Empty -- 00020110 @LISTBOX 50800141 00000000 -- Empty -- 000100c6 WindowIB2003 50000000 00000000 TheContent The program first validates the update region of the main window with the rect of [20114]. |0009:Call user32.ValidateRect(00010022,4070f988) ret=00426f64 ... |trace:win:RedrawWindow Update region of hwnd 0x10022 is nil |0009:Ret user32.ValidateRect() retval=00000001 ret=00426f64 As the extra trace message reports, this window has a null update region at this point. Then the first scroll is requested: |0009:Call user32.ScrollWindowEx(00020114,00000000,0000000a,4070f6e4,4070f6b4,00000000,00000000,00000001) ret=00426fd1 |trace:scroll:ScrollWindowEx 0x20114, 0,10 hrgnUpdate=(nil) rcUpdate = (nil) (0,-47)-(71,0) 0001 |trace:scroll:ScrollWindowEx clipRect = (0,0)-(71,10) ... |0009:Ret user32.ScrollWindowEx() retval=00000001 ret=00426fd1 directly after this the same scroll rectangle (4070f6e4) is invalidated: |0009:Call user32.InvalidateRect(00020114,4070f6e4,00000001) ret=00426fe6 |trace:win:RedrawWindow 0x20114 (0x137e) rect 0,0-71,10 (nil) flags=0005 |trace:win:dump_rdw_flags flags: RDW_INVALIDATE RDW_ERASE ... |0009:Ret user32.InvalidateRect() retval=00000001 ret=00426fe6 and directly UpdateWindow is called: |0009:Call user32.UpdateWindow(00020114) ret=00426fef |0009:Call x11drv.MsgWaitForMultipleObjectsEx(00000001,4070f460,00000000,000000ff,00000000) ret=40764927 |trace:event:EVENT_ProcessEvent called. UpdateWindow calls RedrawWindows that first looks for outstanding events, that is where the trouble starts: |trace:event:EVENT_ProcessEvent Got event Expose for hwnd/window 0x20114/3a001aa, GetFocus()=0x20112 |trace:x11drv:X11DRV_Expose win 0x20114 (3a001aa) 0,0 71x47 ... |0009:Call user32.RedrawWindow(00010022,4070f010,00000000,00000085) ret=40d519a2 |trace:win:RedrawWindow 0x10022 ((nil)) rect 291,142-362,189 (nil) flags=0085 |trace:win:dump_rdw_flags flags: RDW_INVALIDATE RDW_ERASE RDW_ALLCHILDREN and the main window and child [100c6] find them selves invalidated: |trace:win:RDW_Paint hwnd 0x10022 [0x1382] -> hrgn [0x139e], flags [0085] ... |trace:win:RDW_Paint hwnd 0x100c6 [0x138a] -> hrgn [0x139e], flags [0085] after the final scroll, a WM_PAINT message is dispatched to [100c6] and the scrolled window [20114] is invisible. I am not sure what the real problem is: either the expose event should not be there or the handling of the event is wrong. For the latter case: the handling in expose_window() sure does not expect to make visible a normally obscured window. Any suggestions? The program is available on-line, but I would need to give some instruction for non-Dutch users. Rein. -- Rein Klazes rklazes(a)xs4all.nl

1 0

Re: Directx9
by Ivan Leo Puoti 13 Sep '04

13 Sep '04

> If we as a project are committed to doing 0.9, 1.0+ releases it means we > can't simply break code people are using to play their games for months > at a time and shrug it off After 1.0 there will be a stable and a development branch, the stable one for users, and the development one for new stuff, where it doesn't matter if things are broken for a while. A bit like the kernel with 2.4 stable and 2.5 full of broken/buggy stuff until 2.6 is ready, and so on. At least that's how most projects work. Ivan.

3 2

Re: Http Fixes
by Marcus Meissner 13 Sep '04

13 Sep '04

On Mon, Sep 13, 2004 at 11:38:32AM +0100, Robert Shearman wrote: > Hi, > > I have seen one server that likes to return "ICY" instead of "HTTP/1.x". > This patch allows the connection to the server continue, as native does. This would be "icecast" I suspect ;) Ciao, Marcus

1 0

Re: Wininet: InternetSetStatusCallback Fix
by Robert Shearman 13 Sep '04

13 Sep '04

Robert Shearman wrote: > Hi, > > You can call InternetSetStatusCallback on a HTTP handle, not just a > InternetOpen handle, so we should search up through the parents to > find it. Oops, I just checked on MSDN and this patch is wrong. We should copy and store the status callback in every handle, not just in the top level one. I'll submit a new patch soon. Rob

1 0

PEB documentation
by Mike Hearn 13 Sep '04

13 Sep '04

This is interesting information, but where did it come from? Is this structure described in some MS documentation? If so, does it have the full layout of the TEB as well? > Log message: > Robert Reif <reif(a)earthlink.net> > Document all the structure members up to SessionId in the PEB.

1 0

Re: winecfg (was Re: W->A calls)
by Mike Hearn 13 Sep '04

13 Sep '04

> It appears that Mike has been doing a lot of work on this. > http://www.winehq.org/hypermail/wine-devel/2004/09/0221.html > So you probably first want to coordinate with him. Yes. I'm aware that I'm holding people up right now due to my non-connectedness. I'm actually living in a bed&breakfast with no net connection, so I only have web/email access at work. It's kind of odd - I've been doing some work on it lately, and suddenly people pop up who want to work on it after a long period of inactivity. Oh well :) > I would start by running "winecfg", and seeing what doesn't work, which > is a lot. For example, on the very first tab, you can select a "Windows > Version", but changing the setting doesn't actually change anything (it > should make/alter a registry entry). The winecfg code is in > wine/programs/winecfg. Fixed by me already. Actually, I've done quite a bit of work on it, I'd recommend waiting for 2 weeks at which point I'll have net access to my laptop again and can hopefully send off my work. At that point I'll be disappearing back into university life and doing CW work again so the coast will be clear for others to work on it. > A long discussion of things that are needed is in the thread starting: > http://www.winehq.org/hypermail/wine-devel/2004/08/0007.html I've sorted some of these already, especially in the apps tab. So ... if you guys can wait for 2 weeks I should (hopefully) have something to show soon. thanks -mike

1 0

RFC: ntdll critical section debug
by Robert Reif 13 Sep '04

13 Sep '04

I have been running into deadlock problems in the direct sound dll and have been playing with the debug part of critical sections. I added a lock name to Spare[1] to give the critical sections names that will show up in the error messages just like wine's ntdll does. After looking at the ntdll code, it looks like this causes a leak because ntdll statically initializes it's locks and doesn't delete the debug part when it finds Spare[1] used. I also tried adding a linked list of critical section debug structs just like real windows does. Because ntdll statically initializes it's locks, they don't get added to the list. I manually stuff the critical section list lock into the list so it shows up and user locks show up but not the other internal ntdll locks. Is there a good reason to statically initialize ntdll locks or can they be initialized like normal locks? Here is a patch that adds the linked list of debug info: Index: dlls/ntdll/critsection.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/critsection.c,v retrieving revision 1.27 diff -u -r1.27 critsection.c --- dlls/ntdll/critsection.c 6 Sep 2004 20:26:23 -0000 1.27 +++ dlls/ntdll/critsection.c 10 Sep 2004 16:29:14 -0000 @@ -36,6 +36,51 @@ WINE_DEFAULT_DEBUG_CHANNEL(ntdll); WINE_DECLARE_DEBUG_CHANNEL(relay); +static LIST_ENTRY RtlCriticalSectionList; +static CRITICAL_SECTION RtlCriticalSectionLock; +static CRITICAL_SECTION_DEBUG RtlCriticalSectionDebug = +{ + 0, 0, &RtlCriticalSectionLock, + { &RtlCriticalSectionDebug.ProcessLocksList, + &RtlCriticalSectionDebug.ProcessLocksList }, + 0, 0, { 0, (DWORD)(__FILE__ ": RtlCriticalSectionLock") } +}; +static CRITICAL_SECTION RtlCriticalSectionLock = { &RtlCriticalSectionDebug, -1, 0, 0, 0, 0 }; + +void critsection_init() +{ + InitializeListHead( &RtlCriticalSectionList ); + InsertHeadList( &RtlCriticalSectionList, &RtlCriticalSectionDebug.ProcessLocksList ); +} + +static void CRIT_Dump() +{ + int i = 0; + PLIST_ENTRY mark, entry; + PCRITICAL_SECTION_DEBUG debug; + + RtlEnterCriticalSection( &RtlCriticalSectionLock ); + + mark = &RtlCriticalSectionList; + for (entry = mark->Flink; entry != mark; entry = entry->Flink) + { + debug = CONTAINING_RECORD(entry, CRITICAL_SECTION_DEBUG, ProcessLocksList); + + TRACE("RtlCriticalSectionDebug[%d]:\n", i++); + TRACE(" Type = %04x\n", debug->Type); + TRACE(" CreatorBackTraceIndex = %04x\n", debug->CreatorBackTraceIndex); + TRACE(" CriticalSection = %p\n", debug->CriticalSection); + TRACE(" ProcessLocksList.Flink = %p\n", debug->ProcessLocksList.Flink); + TRACE(" ProcessLocksList.Blink = %p\n", debug->ProcessLocksList.Blink); + TRACE(" EntryCount = %ld\n", debug->EntryCount); + TRACE(" ContentionCount = %ld\n", debug->ContentionCount); + TRACE(" Spare[0] = %08lx\n", debug->Spare[0]); + TRACE(" Spare[1] = %08lx (%s)\n", debug->Spare[1], debugstr_a((char *)debug->Spare[1])); + } + + RtlLeaveCriticalSection( &RtlCriticalSectionLock ); +} + inline static LONG interlocked_inc( PLONG dest ) { return interlocked_xchg_add( dest, 1 ) + 1; @@ -126,12 +171,16 @@ crit->DebugInfo->Type = 0; crit->DebugInfo->CreatorBackTraceIndex = 0; crit->DebugInfo->CriticalSection = crit; - crit->DebugInfo->ProcessLocksList.Blink = &(crit->DebugInfo->ProcessLocksList); - crit->DebugInfo->ProcessLocksList.Flink = &(crit->DebugInfo->ProcessLocksList); crit->DebugInfo->EntryCount = 0; crit->DebugInfo->ContentionCount = 0; crit->DebugInfo->Spare[0] = 0; crit->DebugInfo->Spare[1] = 0; + RtlEnterCriticalSection( &RtlCriticalSectionLock ); + InsertTailList( &RtlCriticalSectionList, &(crit->DebugInfo->ProcessLocksList) ); + RtlLeaveCriticalSection( &RtlCriticalSectionLock ); + + if (TRACE_ON(ntdll)) + CRIT_Dump(); } } crit->LockCount = -1; @@ -195,12 +244,19 @@ crit->LockSemaphore = 0; if (crit->DebugInfo) { + RtlEnterCriticalSection( &RtlCriticalSectionLock ); + RemoveEntryList( &(crit->DebugInfo->ProcessLocksList) ); + RtlLeaveCriticalSection( &RtlCriticalSectionLock ); + /* only free the ones we made in here */ if (!crit->DebugInfo->Spare[1]) { RtlFreeHeap( GetProcessHeap(), 0, crit->DebugInfo ); crit->DebugInfo = NULL; } + + if (TRACE_ON(ntdll)) + CRIT_Dump(); } return STATUS_SUCCESS; } Index: dlls/ntdll/ntdll_misc.h =================================================================== RCS file: /home/wine/wine/dlls/ntdll/ntdll_misc.h,v retrieving revision 1.48 diff -u -r1.48 ntdll_misc.h --- dlls/ntdll/ntdll_misc.h 15 Jul 2004 22:07:21 -0000 1.48 +++ dlls/ntdll/ntdll_misc.h 10 Sep 2004 16:29:14 -0000 @@ -50,6 +50,7 @@ extern void debug_init(void); extern void thread_init(void); extern void virtual_init(void); +extern void critsection_init(void); /* server support */ extern void server_init_process(void); Index: dlls/ntdll/thread.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/thread.c,v retrieving revision 1.21 diff -u -r1.21 thread.c --- dlls/ntdll/thread.c 23 Aug 2004 18:52:54 -0000 1.21 +++ dlls/ntdll/thread.c 10 Sep 2004 16:29:14 -0000 @@ -134,6 +134,7 @@ debug_info.str_pos = debug_info.strings; debug_info.out_pos = debug_info.output; + critsection_init(); debug_init(); virtual_init();

3 2

spying COM
by Saulius Krasuckas 13 Sep '04

13 Sep '04

Am not sure would it be of any use for list members, but just some minutes ago I've discovered "The COM spy". Quite old stuff, but whatever: http://staff.develop.com/jasonw/comspy/default.htm

2 1

epoll patch - status?
by Shachar Shemesh 12 Sep '04

12 Sep '04

Hi Alexandre, I'm sorry for being a pest about this. I was wondering whether there is anything that needs to be done on that one in order to facilitate committing this patch? Shachar -- Shachar Shemesh Lingnu Open Source Consulting ltd. http://www.lingnu.com/

5 14

Re: IShellFolder::CompareIDs partially undocumented take 2
by Vitaliy Margolen 12 Sep '04

12 Sep '04

Is there are any problems with this patch? Tests do confirm it. Vitaliy Margolen Saturday, September 4, 2004, 9:48:41 PM, Vitaliy Margolen wrote: > Since my previous patch wasn't excepted here it is again. This time with more fixes > and tests. > Also it _is_ documented that CompareIDs returns result in lower 16 bits. And this function > returns only -1/0/1 as a result. > Vitaliy Margolen > changelog: > dlls/shell32/shlfolder.c > IShellFolder::CompareIDs - return only -1/0/1 in lower 16 bit.

1 0

W->A calls
by Joris Huizer 11 Sep '04

11 Sep '04

Hello, By accident, I removed the emails of the thread I started, but I'll look it up if necessary; I found this old wine issue of some time ago.. I think the patch it has there could be helpfull http://winehq.org/?issue=229#About%20Converting%20W-%3EA%20Calls However, I don't know how to make simple tests.. as I'd really need to test wether the code I write works, and works properly :p How do I write tests for that? I'm running linux (in practice, I never boot into windows) so how should I do this (testing without windows environment)? How are tests supposed to run? I hope you can give some clues on that; I found there are many W->A calls in dlls/winmm/winmm.c (according to the janitorial page) so I might start there (hoping not all of them are so tricky ;) ) Thanks for suggestions on this, Joris

7 9

Re: Correct ConvertSidToStringSidW with test
by Dimitrie O. Paun 11 Sep '04

11 Sep '04

On Sat, Sep 11, 2004 at 08:37:09AM -0700, Juan Lang wrote: > ConvertSidToStringSidW was incorrect for low-value > authorities; it put spaces in the resulting string. > This corrects that, and includes a test case for it. Content-Description: advapi32.diff Uniffied diff, please :) -- Dimi.

1 0

Re: PROPSHEET: Wizard resizing
by Filip Navara 11 Sep '04

11 Sep '04

Filip Navara wrote: > I know this patch isn't really correct, but the old code isn't correct > either. Without it about 80% of the wizards were resized incorrectly > (or not at all) and the header line wasn't hidden sometimes. Even > though I would like to code the resizing correctly it will require > major code shuffling that I can't do now due to time constraints. So I > believe for now this patch is less evil than letting the code as is. > > (I can provide more details about how it should be implemented > correctly on request) > > - Filip > > Changelog: > First attempt at correcting wizard resizing. Scratch this patch please. I'll try to implement it correctly... Regards, Filip

1 0

Wine and non ANSI charset fonts
by Andreas Rosenberg 11 Sep '04

11 Sep '04

Hello guys, after a long pause I'm back testing our application (http://appdb.winehq.org/appview.php?appId=1536) with WINE. In the meantime I've been working to prepare our application for the east european/asian market (UTF16, wide char API). This seems to work so far, but as soon as you enter text requiring non ANSI glyphs, I'm only getting "square boxes" instead of the desired characters. So I was searching for another application that uses non ANSI glyhps with WINE. I choosed Opera, because it's quite easy to install. But unfortunately Opera 7.x crashed after entering the first URL. The function "WSAStringToAddress" and some other WSA funtions were missing/stubs. Yesterday evening I fixed these problems and just sent a patch making Opera work with Wine. With Opera I'm now getting the same or similar effects. just try the Opera in Wine and go to: http://www.viatech.com.tw/big5/index/index.jsp So my question: is this a configuration problem? Konquerer displays the page correctly, so the fonts on the Linux side have the correct glyphs available. But it seems they are not available in WINE - I looked into the WINE config file and found something like this: ;;default TrueType fonts with russian koi8-r encoding "Default" = "-monotype-arial-*-*-*--*-*-*-*-*-*-koi8-r" "DefaultFixed" = "-monotype-courier new-*-*-*--*-*-*-*-*-*-koi8-r" "DefaultSerif" = "-monotype-times new roman-*-*-*--*-*-*-*-*-*-koi8-r" "DefaultSansSerif" = "-monotype-arial-*-*-*--*-*-*-*-*-*-koi8-r" This seems to define something regarding the cyrilic charset. With these lines enabled, Opera can display russian pages correctly. But what do I need to enter to get the glyphs of other character sets? (chinese, hangul, etc...) I read the Wine users guide regarding fonts, but it still does not address the character set topic.Can anybody shed some light on this? Regards Andy

2 1

Re: Implementation of WSAStringToAddress(A/W), WSAHtonl, WSAHtons
by Alexandre Julliard 10 Sep '04

10 Sep '04

Andreas Rosenberg <andreas_rosenberg(a)web.de> writes: > +INT WINAPI WSAStringToAddressW(LPCWSTR AddressString, > + INT AddressFamily, > + LPWSAPROTOCOL_INFOA lpProtocolInfo, You should have an LPWSAPROTOCOL_INFOW here instead, and convert it before calling WSAStringToAddressA. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Almost complete UpdateResource implementation
by Alexandre Julliard 10 Sep '04

10 Sep '04

Vincent Béron <vberon(a)mecano.gme.usherb.ca> writes: > + if(!updates_list) > + { > + updates_list = current_updates; > + list_init(&updates_list->entry); > + } > + else > + list_add_after(&updates_list->entry, &current_updates->entry); That's not the right way to use the list functions. updates_list should be a separate struct list, that will make things a lot easier. > + LIST_FOR_EACH(ptr, &current_updates->resources_list->entry) > + { > + current_resource = LIST_ENTRY(ptr, QUEUEDRESOURCE, entry); > + free_queuedresource(current_resource); > + } You cannot free objects that are still on list, you have to remove them first. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: CreateDirectoryA conformance test improvement
by Alexandre Julliard 10 Sep '04

10 Sep '04

Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> writes: > This patch provides a conformance test for my patch > sent on 06. Sept 2004. > > I have successfully tested it on Windows98 and WindowsNT4. Actually the results of that test depend on what the current directory is on the drive you are testing. If your current directory is \ you will see that it fails on Windows too. I believe the Wine code is correct, it returns ACCESS_DENIED on the root and ALREADY_EXISTS anywhere else, just like Windows. -- Alexandre Julliard julliard(a)winehq.org

1 0

COmpilation problems with older Freetype 2
by Vincent Béron 10 Sep '04

10 Sep '04

A patch by Huw broke compilation of Wine on RH8 (and probably other platforms as well) which use Freetype 2.1.3 or earlier. More specifically, FT_ENCODING_NONE is undefined. Other ft_encoding_* (or FT_ENCODING_*) problems have arised in the past, but the solution used identifiers already present in older Freetype versions. The attached patch works (and results in the same compiled code IMHO), but looks like a hack rather than a proper fix (use MS_MAKE_TAG? that has already been removed in the past to use ft_encoding_*). Vincent

1 0

Re: Fix twain device handle corruption
by Alexandre Julliard 10 Sep '04

10 Sep '04

Francois Gouget <fgouget(a)codeweavers.com> writes: > * or we could check that config.h has been included first using > something like: > > #ifndef __WINE_CONFIG_H > # error You must include config.h first > #endif I think that's preferable, we really want to be using the same structure everywhere. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [SHLWAPI] Implemented PathSearchAndQualify (another fix)
by Vincent Béron 10 Sep '04

10 Sep '04

Le ven 10/09/2004 à 13:22, Diego 'Flameeyes' Pettenò a écrit : > I have fixed the patch for the problems Rolf Kalbermatter pointed out. Hope > this time is the good one :) Not likely if the patch is not attached... ;) Vincent

2 1

Re: winedos:MCB implementation
by Andreas Mohr 10 Sep '04

10 Sep '04

Hi, On Fri, Sep 10, 2004 at 06:09:26PM +0200, Markus Amsler wrote: > That's some of the result of my effort getting FreeCOM running in winedos. > It's quite important to winedos having proper MCB support, a lot of apps > depend on it. Indeed! Great, thanks a lot for this very important work!! > It also enables running/terminating apps within dos shells, and opens > the door to TSR. > With some more patches (IO-redirection, TSR comming soon) i'm able to > run FreeCOM, compile FreeCOM within FreeCOM, run XRAY and getting my TSR > app starting. Cool. > Please let me know, if there's something wrong with the patch (design > problems, naming conventions, formating, ...). Looks nice and clean to me on cursory glance. Andreas Mohr

1 0

Re: dinput axis mapping and format mapping patch
by Alexandre Julliard 10 Sep '04

10 Sep '04

Robert Reif <reif(a)earthlink.net> writes: > Add a [dinput] section to your config file and provide a line with the > following information: > > "your device name" = "X,Y,Z,Rx,Ry,Rz,Slider1,Slider2,POV1,POV2,POV3,POV4" > > where "your device name" is what you get from /bin/jstest and > the axes list are the axes supported by your joystick. > > For example, here is part of my config file: > > [dinput] > "Logitech Logitech Extreme 3D Pro" = "X,Y,Rz,Slider1,POV1" You should add this in the registry instead of the config file, this way we won't have to move it later on. HKLM/Software/Wine/Dinput should be a good place for it. -- Alexandre Julliard julliard(a)winehq.org

3 6

Fwd: Cron <paulm@quisquiliae> $HOME/Production/cronCrossBuild 10:00
by Paul Millar 10 Sep '04

10 Sep '04

Hi everyone, A couple of quick things: First, I'm off on holiday for a week (starting tomorrow :^) so won't be able to answer emails for a bit. The cross-building should carry on regardless, though. Second, very occasionally get messages like: ---------- Forwarded Message ---------- Subject: Cron <paulm@quisquiliae> $HOME/Production/cronCrossBuild 10:00 Date: Friday 10 September 2004 11:18 From: root of quisquiliae <p.millar(a)physics.gla.ac.uk> To: p.millar(a)physics.gla.ac.uk cvs checkout: warning: unrecognized response `cvs: buffer.c:1384: stdio_buffer_shutdown: Assertion `fstat ( fileno (bc->fp), &s ) != -1 failed.' from cvs server cvs [checkout aborted]: end of file from server (consult above messages if any) ------------------------------------------------------- which looks like WineHQ's cvs server sulking. Does any else get these? Cheers, Paul.

1 0

Linking with winelib
by Nikolay A. Liber 10 Sep '04

10 Sep '04

Hello I am using winelib with Mono hack to load windows DLL into python module. There is a dummy function wine_pthread_init_thread in libwine.so. wine_pthread_init_thread implemented in winelib.so.exe from mono shared winelib. I link module. gcc -shared mymodule.so module_code.o -lwine ./winelib.so.exe But when I load module init_thread from ntdll calls dummy wine_pthread_init_thread. How to override that dumy function? Thank you Nikolay

2 1

RE: modal dialog: Wait until message queue runs dry before calling ShowWindow()
by Zach Gorman 09 Sep '04

09 Sep '04

Yes, the test code is on its way. These patches are all from a few weeks ago, but Alexandre asked me to break them up into multiple smaller patches. I tested them with the latest tree and they seem to still work fine. Zach -----Original Message----- From: Mike McCormack [mailto:mike@codeweavers.com] Sent: Thursday, September 09, 2004 2:37 PM To: zach(a)archetypeauction.com Subject: Re: modal dialog: Wait until message queue runs dry before calling ShowWindow() Zach Gorman wrote: > My tests show that Windows behaves this way. If you could submit your test as a patch including it in the wine test suite, that would be great. If not, just posting it with a LGPL compatible license so others can adapt it to the test suite would be appreciated too. Mike

1 0

Re: edit control
by Robert Shearman 09 Sep '04

09 Sep '04

Ulrich Czekalla wrote: >ChangeLog: > Ulrich Czekalla <ulrich(a)codeweavers.com> > Allow copying selection when control is read only > > >------------------------------------------------------------------------ > >Index: dlls/user/edit.c >=================================================================== >RCS file: /home/wine/wine/dlls/user/edit.c,v >retrieving revision 1.1 >diff -u -r1.1 edit.c >--- dlls/user/edit.c 31 Aug 2004 01:10:08 -0000 1.1 >+++ dlls/user/edit.c 9 Sep 2004 13:01:26 -0000 >@@ -3604,7 +3604,8 @@ > > /* Protect read-only edit control from modification */ > if(es->style & ES_READONLY) >- return; >+ if (c != 0x03) /* Allow copying selection */ >+ return; > > control = GetKeyState(VK_CONTROL) & 0x8000; > > That read-only check looks completely bogus to me as the code below already checks for ES_READONLY. Rob

2 1

Settlers 3: bug in NTDLL_get_server_timeout??
by Stefan Dösinger 09 Sep '04

09 Sep '04

Hello list, I am trying to get Settlers 3(Siedler 3) working. This game crashes with a Integer divide by 0 exception very early. Wine version: cvs from September 7. 2004 Settlers 3 version: 1.60 with WinXp-patch. s3.exe produces a nice crash dump(attached errorlog.txt) and with a little debugging I found out that the crash occurs in RtlEnlargedUnsignedDivide(), file dlls/ntdll/large_int.c This is what I think is going on: *)s3.exe calls SetWaitableTimer() in dlls/kernel/sync.c *)NtSetTimer() in dlls/ntdll/sync.c is called, and this is where the problem beginns. NtSetTimer() calls NTDLL_get_server_timeout from time.c *)The 2nd case occurs(the else if) and RtlEnlargedUnsignedDivide is called. The interesting thing is that TICKSPERSEC is a constant(10000000) and this shouldn't give a divide by zero. But RtlEnlargedUnsignedDivide takes an UINT as 2nd arguemt, and 10000000 is too big for an UINT. For testing I enabled the C version of RtlEnlargedUnsignedDivide, and this time the exception didn't occur but wineserver blocked(kill -9 was necessary) The same thing happens if I move the divison to NTDLL_get_server_timeout(and do not call RtlEnlargedUnsignedDivide). I commented the call to NTDLL_get_server_timeout, and s3.exe starts successfully, but I don't think that's the correct way to solve this problem. I attached the output with normal debug options and a few TRACEs changed to ERRs. NTDLL_get_server_timeout is called quite often. The SetWaitableTimer call: err:ntdll:SetWaitableTimer called err:ntdll:NtSetTimer (0xf4,0x46d32104,(nil),(nil),00000000,0x000001f4,(nil)) stub err:ntdll:NTDLL_get_server_timeout called err:ntdll:NTDLL_get_server_timeout called err:ntdll:NTDLL_get_server_timeout called ... fixme:dialog:MSGBOX_OnInit system modal msgbox ! Not modal yet. -- The crash message err:ntdll:NTDLL_get_server_timeout called err:ntdll:NTDLL_get_server_timeout called Greetings, Stefan Dösinger

4 5

RE: Battlefield 1942 d3d8 crash
by Ann and Jason Edmeades 09 Sep '04

09 Sep '04

Hiya, Just an fyi - I installed it and gave it a try. The first problem (the one you mentioned) is easily solved by commenting out the hide and show calls around the setwindowpos. This may be the real fix - The problem is the app has a default window proc which is receiving a window activated message on the show, and assumes it had lost full screen and got it back. It then tries to reset everything but it never completed initialization! Anyway it then goes on to die on something I think is sound related, but might be my machines problem (sound on my test box is seriously screwed up). Note the game writes into a sub dir 'Logs' (from memory) a log of how far it gets. Try taking those 2 lines out and see if you get any further. I'll have another go at the 2nd trap I am seeing, but it would be interesting to see if you get any further. Jason

1 0

UltimaOnLine: X11DRV_CritSection deadlock
by Diego 'Flameeyes' Pettenò 09 Sep '04

09 Sep '04

Hi, I'm playing Ultima OnLine using wine in the last times, it works fine, except that wine processes eat all the cpu time and sometimes I have this fixme on stderr: fixme:bitblt:X11DRV_BitBlt potential optimization - client-side DIBcopy But the true problem is that if I'm idle for some time, I get this error, and kde stops responding at mouse (and sometimes also keyboard) events: err:ntdll:RtlpWaitForCriticalSection section 0x41bd6220 "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 0009, blocked by 000a, retrying (60 sec) Seems like a deadlock, but I don't know what can generate this problem, so I can't reproduce it after launching winedbg. Also when I close the client, wine remains open until I ctrl-c it. Trying to tracing this is quite impossible, because it's already heavy when launched directly, I don't think it's possible to have a +all with it without using the delayed debug, but I'm not able to find out the patch into wine-patches, if someone can point a link for it, I'll try to do that. If no one has idea of what problem is this, I'll report it as a bug, but maybe it's only an application's problem. TIA, -- Diego "Flameeyes" Pettenò dgp85(a)users.sourceforge.net - http://flameeyes.web.ctonet.it/

5 7

Re: Drowning in FIXMEs...
by Jukka Heinonen 09 Sep '04

09 Sep '04

Chris Rankin: > OK, here's a first draft at a patch. Created with > reference to my old copies of Ralph Brown's Interrupt > List. Well, under DOS VGA text mode, mouse cursor is like "gpm" mouse cursor, a character cell which gets inverted or otherwise highlighted in order to show where mouse is currently located at. As far as I know, neither Wine nor Windows supports this and SetConsoleCursorInfo really has no effect on mouse cursor, anyway. So, under text mode, hide/show functions should do nothing. However, under VGA graphics mode, show/hide cursor really should call ShowCursor. And, if mouse driver is reset, hide count must be reset to one and cursor must be hidden. I have some more or less untested patch for show/hide somewhere but the last time I tried to get that working I had to fix IRQ handling, again, and after that I was too bored and too busy for doing DOS stuff. Anyway, it will take probably about half a week until I have time for digging out the patch, which I will do if this thing is not fixed before that. I guess I should also dig my other DOS related patches and submit them as well, I don't know if they really help much but at least I would not have pending stuff in my computer. -- Jukka Heinonen <http://www.iki.fi/jhei>

4 3

Re: Re: test.winehq.org site
by Chris Morgan 09 Sep '04

09 Sep '04

>From what I can tell on my xp machine it looks like winrash is running correctly, no errors downloading the winetest are reported. Maybe winetest is failing prematurely or the reporting of the results isn't occuring correctly? Chris > > From: "Dimitrie O. Paun" <dpaun(a)rogers.com> > Date: 2004/09/08 Wed PM 12:06:04 EDT > To: Saulius Krasuckas <saulius2(a)ar.fi.lt> > CC: wine-devel(a)winehq.org > Subject: Re: test.winehq.org site > > On Wed, Sep 08, 2004 at 06:32:31PM +0200, Saulius Krasuckas wrote: > > When can we expect it to be up and running? > > It is up and running, we're just missing an index page. > Until that gets created, use this link instead: > > http://test.winehq.org/data/ > > Unfortunately, the testing process has been broken lately, > for unknown reasons. > > -- > Dimi. > >

3 2

The solution for the Delphi menu bug
by Michael Kaufmann 09 Sep '04

09 Sep '04

Hi all, I found a different approach to make the menus of Delphi applications work in WINE. I was working on a different bug (allow a single menu to be used in multiple windows), and found that my fix for this problem also fixes the Delphi menu bug. So we don't have to break a testcase! The fix is as simple as updating the menu bar's hWnd member every time the user clicks on a menu bar. This is even necessary if the menu is displayed in multiple windows, so it's not a "Delphi-only" fix. Thank you for the intensive discussion we had on the subject! My patch is here: http://www.winehq.org/hypermail/wine-patches/2004/09/0154.html Regards Michael

1 0

DirectInput suggestion
by Jonathan Wilson 08 Sep '04

08 Sep '04

I dont know how this stuff works on linux so my suggestion may be wrong but here goes. Basicly, my suggestion is that any joystick that is visible to linux apps be made visible to windows apps via DirectInput joystick APIs. This eliminates the need for WINE to care about USB and such.

2 1

Problem with change of DIDEVICEOBJECTDATA
by Stefan Dösinger 08 Sep '04

08 Sep '04

Hello, I have a problem with the change of struct DIDEVICEOBJECTDATA in CVS: DIDEVICEOBJECTDATA now has size 20, but Settler 3 still calls SysMouseAImpl_GetDeviceData with dodsize=16 and complains about the returned error. Stefan Dösinger

3 2

RE: [SHLWAPI] Implemented PathSearchAndQualify (fix)
by Rolf Kalbermatter 08 Sep '04

08 Sep '04

A few comments: /************************************************************************* @@ -3126,8 +3146,87 @@ */ BOOL WINAPI PathSearchAndQualifyW(LPCWSTR lpszPath, LPWSTR lpszBuf, UINT cchBuf) { - FIXME("(%s,%p,0x%08x)-stub\n", debugstr_w(lpszPath), lpszBuf, cchBuf); - return FALSE; + LPWSTR pathCopy; + LPWSTR bufPos = lpszBuf; + LPWSTR bufPos2 = bufPos; + BOOL ret = TRUE; + + if ( !(pathCopy = HeapAlloc(GetProcessHeap(), 0, cchBuf * sizeof(WCHAR)))) + return FALSE; + StrCpyW(pathCopy, lpszPath); + lpszPath = pathCopy; This is rather ugly. You shouldn't overwrite the pointer to the passed in buffer. Use for internal pointer reference handling one of the local variables instead of overwriting a parameter variable. + TRACE("(%s %p %d)\n", debugstr_w(lpszPath), lpszBuf, cchBuf); + + if (!lpszPath || !*lpszPath) + return FALSE; I think this is bad order! The trace should be on entry and definitely before you modify any passed in parameters. The same applies for the valid input parameter check. + if (*pathCopy == '\\' && pathCopy[1] == '\\') + { + /* Network share: skip share server and mount point */ + pathCopy += 2; + if ((pathCopy = StrChrW(pathCopy, '\\')) && + (pathCopy = StrChrW(pathCopy + 1, '\\'))) + pathCopy++; + } + + /* Check x:\ */ + if (pathCopy[0] && pathCopy[1] == ':' && pathCopy[2] == '\\') + pathCopy += 3; + + if ( pathCopy != lpszPath ) + { + StrCpyNW(bufPos, lpszPath, (pathCopy - lpszPath) +1); + bufPos += (pathCopy - lpszPath); + bufPos2 = bufPos; + *bufPos = '\0'; + lpszPath = pathCopy; + } else { + FIXME("must prepend current path"); + } + + while(*pathCopy) + { + if ( *pathCopy == '.' ) + { + if ( ! pathCopy[1] ) + { + ret = TRUE; + break; + } + + if ( pathCopy[1] == '\\' ) { pathCopy += 2; continue; } + + if ( pathCopy[1] == '.' && pathCopy[2] == '\\' ) + { + if ( bufPos == bufPos2 ) + { + pathCopy += 3; + continue; + } + + bufPos = StrRChrW(bufPos, bufPos2, '\\'); + *bufPos = '\0'; + continue; + } + } + + if ( StrChrW(pathCopy, '\\') ) + { + size_t len = (StrChrW(pathCopy, '\\') - pathCopy )+1; + StrCpyNW(bufPos, pathCopy, len+1); + bufPos += len; + pathCopy += len; + *bufPos = '\0'; + continue; + } else { + StrCpyW(bufPos, pathCopy); + break; + } + } + + HeapFree(GetProcessHeap(), 0, pathCopy); + return ret; } I don't see how pathCopy can be the original pointer here after having made so much of pointer increments on that variable inside the function. This would mean that HeapFree will completely fail or probably just crash. Rolf Kalbermatter

1 0

Revised menu patch
by Michael Kaufmann 08 Sep '04

08 Sep '04

Hi all My last menu patch didn't pass a test case. I've commented out this test case, because it tests undocumented behavior. We should re-activate this testcase as soon as WINE passes it. This will be the case when the menu code is moved to WineServer, as Dmitry pointed out. I've also added more bugfixes to the patch: Now WINE supports the (very rare) case where a menu is assigned to multiple windows. To test this, I'll attach a program which displays two windows using the same menu. The windows are from different window classes in order to test if WINE sends the ownerdraw messages to the correct window. Please test this patch and tell me if I should send it to wine-patches. Regards Michael Index: dlls/user/menu.c =================================================================== RCS file: /home/wine/wine/dlls/user/menu.c,v retrieving revision 1.1 diff -u -r1.1 menu.c --- dlls/user/menu.c 31 Aug 2004 01:10:08 -0000 1.1 +++ dlls/user/menu.c 7 Sep 2004 21:17:43 -0000 @@ -83,15 +83,14 @@ HWND hWnd; /* Window containing the menu */ MENUITEM *items; /* Array of menu items */ UINT FocusedItem; /* Currently focused item */ - HWND hwndOwner; /* window receiving the messages for ownerdraw */ BOOL bTimeToHide; /* Request hiding when receiving a second click in the top-level menu item */ /* ------------ MENUINFO members ------ */ - DWORD dwStyle; /* Extended mennu style */ - UINT cyMax; /* max hight of the whole menu, 0 is screen hight */ - HBRUSH hbrBack; /* brush for menu background */ + DWORD dwStyle; /* Extended menu style */ + UINT cyMax; /* Max height of the whole menu, 0 is screen height */ + HBRUSH hbrBack; /* Brush for menu background */ DWORD dwContextHelpID; - DWORD dwMenuData; /* application defined value */ - HMENU hSysMenuOwner; /* Handle to the dummy sys menu holder */ + DWORD dwMenuData; /* Application-defined value */ + HMENU hSysMenuOwner; /* Handle to the dummy system menu holder */ } POPUPMENU, *LPPOPUPMENU; /* internal flags for menu tracking */ @@ -171,6 +170,10 @@ * be tracked at the same time. */ static HWND top_popup; +/* Use a global owner window while tracking the menu. + * This window receives ownerdraw messages. */ +static HWND owner_window; + /* Flag set by EndMenu() to force an exit from menu tracking */ static BOOL fEndMenu = FALSE; @@ -181,6 +184,7 @@ /********************************************************************* * menu class descriptor */ + const struct builtin_class_descr MENU_builtin_class = { POPUPMENU_CLASS_ATOMA, /* name */ @@ -1405,8 +1409,9 @@ UINT u; for (u = menu->nItems, item = menu->items; u > 0; u--, item++) - MENU_DrawMenuItem( hwnd, hmenu, menu->hwndOwner, hdc, item, - menu->Height, FALSE, ODA_DRAWENTIRE ); + + MENU_DrawMenuItem( hwnd, hmenu, owner_window, hdc, item, + menu->Height, FALSE, ODA_DRAWENTIRE ); } } else @@ -1473,10 +1478,6 @@ menu->FocusedItem = NO_SELECTED_ITEM; } - /* store the owner for DrawItem */ - menu->hwndOwner = hwndOwner; - - MENU_PopupMenuCalcSize( menu, hwndOwner ); /* adjust popup menu pos so that it fits within the desktop */ @@ -2837,7 +2838,11 @@ */ static BOOL MENU_InitTracking(HWND hWnd, HMENU hMenu, BOOL bPopup, UINT wFlags) { + POPUPMENU* menu; + TRACE("hwnd=%p hmenu=%p\n", hWnd, hMenu); + + if (!(menu = MENU_GetMenu( hMenu ))) return FALSE; HideCaret(0); @@ -2849,9 +2854,8 @@ if (!(wFlags & TPM_NONOTIFY)) { - POPUPMENU *menu; SendMessageW( hWnd, WM_INITMENU, (WPARAM)hMenu, 0 ); - if ((menu = MENU_GetMenu( hMenu )) && (!menu->Height)) + if (!menu->Height) { /* app changed/recreated menu bar entries in WM_INITMENU Recalculate menu sizes else clicks will not work */ SetWindowPos( hWnd, 0, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOMOVE | @@ -2859,6 +2863,13 @@ } } + + /* Multiple windows can use the same menu. + * The menu needs to know its owner window for the + * current tracking operation. */ + owner_window = hWnd; /* for DrawItem */ + menu->hWnd = hWnd; /* for MENU_TrackMenu and many other functions */ + return TRUE; } /*********************************************************************** @@ -2970,6 +2981,8 @@ { BOOL ret = FALSE; + if (!IsMenu( hMenu )) return FALSE; + MENU_InitTracking(hWnd, hMenu, TRUE, wFlags); /* Send WM_INITMENUPOPUP message only if TPM_NONOTIFY flag is not specified */ @@ -3554,6 +3567,36 @@ DestroyWindow( lppop->hWnd ); lppop->hWnd = 0; } + + /* Check if the menu is still in use by a window + * (fix for bug 1486) + * + * FIXME: - A menu used by multiple windows is not removed + * from all windows, but only from the window that + * used the menu most recently + * - Update or remove this code if you move the menu + * code to WineServer + */ + if (lppop->hWnd && IsWindow(lppop->hWnd) && + GetMenu(lppop->hWnd) == hMenu) + { + /* Handle this situation in the same way as Windows 9x. + + Windows 9x destroys the menu and sets the window's + menu handle to NULL, without repainting the menu bar. + The application has to call SetMenu or DrawMenuBar + afterwards. + + FIXME: Windows 2000 returns TRUE, but doesn't destroy + the menu immediately. It waits until the menu + is not used anymore. */ + + WARN("The menu %p is still in use by window %p\n", + hMenu, lppop->hWnd); + + MENU_SetMenu(lppop->hWnd, NULL); + lppop->hWnd = 0; + } if (lppop->items) /* recursively destroy submenus */ { @@ -3728,7 +3771,6 @@ if (!hMenu || !(lppop = MENU_GetMenu( hMenu ))) return FALSE; lppop->Height = 0; /* Make sure we call MENU_MenuBarCalcSize */ - lppop->hwndOwner = hWnd; SetWindowPos( hWnd, 0, 0, 0, 0, 0, SWP_NOSIZE | SWP_NOMOVE | SWP_NOACTIVATE | SWP_NOZORDER | SWP_FRAMECHANGED ); return TRUE; Index: dlls/user/tests/win.c =================================================================== RCS file: /home/wine/wine/dlls/user/tests/win.c,v retrieving revision 1.33 diff -u -r1.33 win.c --- dlls/user/tests/win.c 26 Aug 2004 18:33:40 -0000 1.33 +++ dlls/user/tests/win.c 7 Sep 2004 21:17:45 -0000 @@ -1606,7 +1606,7 @@ { HWND child; HMENU hMenu, ret; - BOOL is_win9x = GetWindowLongW(parent, GWL_WNDPROC) == 0; + /* BOOL is_win9x = GetWindowLongW(parent, GWL_WNDPROC) == 0; */ hMenu = CreateMenu(); assert(hMenu); @@ -1619,9 +1619,12 @@ ok(DestroyMenu(hMenu), "DestroyMenu error %ld\n", GetLastError()); ok(!IsMenu(hMenu), "menu handle should be not valid after DestroyMenu\n"); ret = GetMenu(parent); - /* This test fails on Win9x */ - if (!is_win9x) - ok(ret == hMenu, "unexpected menu id %p\n", ret); + + /* FIXME: This test fails on Win9x and WINE + WINE will pass this test after the menu + code has been moved to WineServer */ + /* if (!is_win9x) + ok(ret == hMenu, "unexpected menu id %p\n", ret); */ ok(SetMenu(parent, 0), "SetMenu(0) on a top level window should not fail\n"); test_nonclient_area(parent); #include <windows.h> LRESULT CALLBACK WndProc1 (HWND, UINT, WPARAM, LPARAM); LRESULT CALLBACK WndProc2 (HWND, UINT, WPARAM, LPARAM); char szAppName1[] = "MenuDemo1"; char szAppName2[] = "MenuDemo2"; #define MENU_FILE 0 #define MENU_QUIT 1 char* MenuStrings[] = {"File", "Quit"}; int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow) { HWND hwnd1; HWND hwnd2; MSG msg; WNDCLASSEX wndclass; HMENU hMenu; HMENU hMenuPopup; // Window 1 with WndProc1 wndclass.cbSize = sizeof (wndclass); wndclass.style = CS_HREDRAW | CS_VREDRAW; wndclass.lpfnWndProc = WndProc1; wndclass.cbClsExtra = 0; wndclass.cbWndExtra = 0; wndclass.hInstance = hInstance; wndclass.hIcon = LoadIcon(NULL, IDI_APPLICATION); wndclass.hCursor = LoadCursor(NULL, IDC_ARROW); wndclass.hbrBackground = (HBRUSH) GetStockObject (WHITE_BRUSH); wndclass.lpszMenuName = 0; wndclass.lpszClassName = szAppName1; wndclass.hIconSm = LoadIcon(NULL, IDI_APPLICATION); RegisterClassEx (&wndclass); // Window 2 with WndProc2 wndclass.lpfnWndProc = WndProc2; wndclass.lpszClassName = szAppName2; RegisterClassEx (&wndclass); hMenu = CreateMenu(); hMenuPopup = CreateMenu(); AppendMenu(hMenuPopup, MF_STRING | MF_OWNERDRAW, 1, (char*) MENU_QUIT); AppendMenu(hMenu, MF_POPUP | MF_OWNERDRAW, (UINT)hMenuPopup, (char*) MENU_FILE); hwnd1 = CreateWindow (szAppName1, "Red Ownerdraw Menu", WS_OVERLAPPEDWINDOW, 50, 50, 300, 150, NULL, NULL, hInstance, NULL); SetMenu(hwnd1, hMenu); ShowWindow (hwnd1, iCmdShow); UpdateWindow (hwnd1); hwnd2 = CreateWindow (szAppName2, "Green Ownerdraw Menu", WS_OVERLAPPEDWINDOW, 350, 50, 300, 150, NULL, NULL, hInstance, NULL); SetMenu(hwnd2, hMenu); ShowWindow (hwnd2, iCmdShow); UpdateWindow (hwnd2); while (GetMessage (&msg, NULL, 0, 0)) { TranslateMessage (&msg); DispatchMessage (&msg); } return msg.wParam; } LRESULT CALLBACK WndProc1 (HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM lParam) { MEASUREITEMSTRUCT* m; DRAWITEMSTRUCT* d; HBRUSH brush; int savedDC; switch (iMsg) { case WM_COMMAND: switch (LOWORD (wParam)) { case 1: SendMessage (hwnd, WM_CLOSE, 0, 0L); return 0; } break; case WM_DESTROY: PostQuitMessage (0); return 0; case WM_MEASUREITEM: m = (MEASUREITEMSTRUCT*)lParam; m->itemWidth = 50; m->itemHeight = 20; return TRUE; case WM_DRAWITEM: d = (DRAWITEMSTRUCT*)lParam; savedDC = SaveDC(d->hDC); brush = CreateSolidBrush(RGB(255, 0, 0)); SelectObject(d->hDC, brush); FillRect(d->hDC, &(d->rcItem), brush); SetBkMode(d->hDC, TRANSPARENT); DrawText(d->hDC, MenuStrings[d->itemData], -1, &(d->rcItem), DT_CENTER | DT_SINGLELINE | DT_VCENTER); RestoreDC(d->hDC, savedDC); DeleteObject(brush); } return DefWindowProc (hwnd, iMsg, wParam, lParam); } // Only the brush color differs from WndProc1 LRESULT CALLBACK WndProc2 (HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM lParam) { MEASUREITEMSTRUCT* m; DRAWITEMSTRUCT* d; HBRUSH brush; int savedDC; switch (iMsg) { case WM_COMMAND: switch (LOWORD (wParam)) { case 1: SendMessage (hwnd, WM_CLOSE, 0, 0L); return 0; } break; case WM_DESTROY: PostQuitMessage (0); return 0; case WM_MEASUREITEM: m = (MEASUREITEMSTRUCT*)lParam; m->itemWidth = 50; m->itemHeight = 20; return TRUE; case WM_DRAWITEM: d = (DRAWITEMSTRUCT*)lParam; savedDC = SaveDC(d->hDC); brush = CreateSolidBrush(RGB(0, 255, 0)); SelectObject(d->hDC, brush); FillRect(d->hDC, &(d->rcItem), brush); SetBkMode(d->hDC, TRANSPARENT); DrawText(d->hDC, MenuStrings[d->itemData], -1, &(d->rcItem), DT_CENTER | DT_SINGLELINE | DT_VCENTER); RestoreDC(d->hDC, savedDC); DeleteObject(brush); } return DefWindowProc (hwnd, iMsg, wParam, lParam); }

7 11

Re: PATCH: use standard offsetof()
by Alexandre Julliard 08 Sep '04

08 Sep '04

Marcus Meissner <marcus(a)jet.franken.de> writes: > gcc 3.5 no longer likes our own OFFSETOF() macro in winebuild, so we should > use the standard one from <stddef.h> Not all platforms have offsetof (or even stddef.h). What's wrong with our definition? -- Alexandre Julliard julliard(a)winehq.org

3 3

rejected patch? libw32sys.so linked to win32s/libw32skrnl.so
by Peter Petrakis 08 Sep '04

08 Sep '04

Hello All, Citing this email from way back in 2000. http://www.mail-archive.com/wine-devel%40winehq.com/msg00914.html Talks about a crash when capture.exe is run from the orcad suite. I'm using orcad lite 9.2 (student edition), I can get everything to work except capture. I've upgraded to the latest rpm availble for suse 9.1 (wine-20040716-0.1, x86) but the problem remains. I tried some troubleshooting which included getting the actual w32sys dll and issuing an override, which seems to be ignored. I also destroyed the symlink that aliased aforementioned library to libw32skml. It still crashes. For whatever reason it is not honoring the override. The relevant config section is the following: [DllOverrides] ; some dlls you may want to change "oleaut32" = "builtin, native" "ole32" = "builtin, native" "comdlg32" = "builtin, native" "shell32" = "builtin, native" "shfolder" = "builtin, native" "shlwapi" = "builtin, native" "shdocvw" = "builtin, native" "advapi32" = "builtin, native" "w32sys" = "native, builtin" "w32skrnl" = "native, builtin" "msvcrt" = "native, builtin" "mciavi.drv" = "native, builtin" "mcianim.drv" = "native, builtin" "msi" = "native, builtin" "d3drm" = "native, builtin" "d3dxof" = "native, builtin" "dpnhpast" = "native, builtin" ; you can specify applications too ; this one will apply for all notepad.exe ;"*notepad.exe" = "native, builtin" ; this one will apply only for a particular file ;"C:\\windows\\regedit.exe" = "native, builtin" ; default for all other dlls "*" = "builtin, native" [AppDefaults\\capture.exe\\DllOverrides] "w32sys" = "native" Some debugging info, petrakis@prin-92:~/.wine/fake_windows/Program Files/OrcadLite/Capture> export WINEDEBUG=+dll petrakis@prin-92:~/.wine/fake_windows/Program Files/OrcadLite/Capture> wine capture.exe trace:dll:fill_init_list (krnl386.exe) - START trace:dll:fill_init_list (krnl386.exe) - END trace:dll:fill_init_list (system.drv) - START trace:dll:fill_init_list (system.drv) - END trace:dll:fill_init_list (gdi.exe) - START trace:dll:fill_init_list (gdi.exe) - END trace:dll:fill_init_list (user.exe) - START trace:dll:fill_init_list (user.exe) - END trace:dll:fill_init_list (keyboard.drv) - START trace:dll:fill_init_list (keyboard.drv) - END trace:dll:fill_init_list (mmsystem.dll) - START trace:dll:fill_init_list (mmsystem.dll) - END trace:dll:NE_CallDllEntryPoint Calling mmsystem.dll DllEntryPoint, cs:ip=1187:0ac1 err:module:load_builtin_dll loaded .so for L"W32SYS.DLL" but got L"w32skrnl.dll" instead - probably 16-bit dll fixme:ole:CoRegisterMessageFilter stub wine: Unhandled exception (thread 0021), starting debugger... trace:dll:fill_init_list (krnl386.exe) - START trace:dll:fill_init_list (krnl386.exe) - END trace:dll:fill_init_list (system.drv) - START trace:dll:fill_init_list (system.drv) - END Usage: winedbg [--auto] [--gdb] cmdline I'm very curious that the patch mentioned or something like it never made it into the source tree. I will integrate it myself the weekend (or as soon as friday) and see for myself. If this patch can work, I could switch ALOT of EE and CSE students over to Linux. Is there a work around that does not require a rebuild? Thanks in advance. Peter

2 1

Re: Acknowledgement page
by Brian Vincent 08 Sep '04

08 Sep '04

On Sun, 5 Sep 2004 00:34:48 +0200, Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote: > Hmm, just found that some other major developers are missing: > Aric Stewart (or is that "Codeweavers"?), Marcus Meissner, > Eric Poeuch (and that was 3 out of 5 author tries that I did). Should have explained that bit.. anyone listed on the Who's Who page doesn't show up here. This list will fall right under that on the introduction page.. but perhaps I need to add a reference back to the Who's Who page. -Brian

2 1

Simple bugzilla question
by Ann and Jason Edmeades 08 Sep '04

08 Sep '04

Hiya, I've just set up a temporary Linux system to try to get back into doing some wine development following a break and thought I'd start by looking at some bugzilla bugs for now. I'm sure there used to be a page which showed the lifespan of a bug but for the life of me I cant see it. My understanding is I accept it and assign to myself, then fix it, then what... Do I put the bug in fixed state and submit the patch or leave that change to the raised? Jason

2 1

Re: Allow assignment of olefonts to other olefonts
by Mike Hearn 08 Sep '04

08 Sep '04

Alexandre, is there anything wrong with this patch? > ChangeLog: > Allow assignment of olefonts to other olefonts

2 2

Installing Platform SDK on Wine
by Dan Kegel 08 Sep '04

08 Sep '04

After (more or less) installing IE6 on Wine, I tried installing the Platform SDK. Looks like their Setup.exe program invokes IE and some ActiveX control. And it looks like I don't know how to install the msi packages without their setup.exe (maybe someone else knows?). This was with Wine-20040813, I think. I'm trying to get a valid windows.h for use with cl out of this. I may punt and just use the windows.h that comes with wine -- it doesn't work off the bat, but maybe it's easier to fix (possibly by just adding some -D's to the commandline) than the real platform sdk install. - Dan p.s. here's how I tried to install the Platform SDK #!/bin/sh # Download and install Platform SDK # See # http://www.eggheadcafe.com/ng/microsoft.public.vstudio.development/post2716… and # http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm set -ex # Platform SDK for file in \ PSDK-FULL.1.cab PSDK-FULL.2.cab PSDK-FULL.3.cab PSDK-FULL.4.cab PSDK-FULL.5.cab PSDK-FULL.6.cab \ PSDK-FULL.7.cab PSDK-FULL.8.cab PSDK-FULL.9.cab PSDK-FULL.10.cab PSDK-FULL.11.cab PSDK-FULL.12.cab \ PSDK-FULL.13.cab ; do wget -c http://download.microsoft.com/download/platformsdk/sdk/update/win98mexp/en-… done # Extract. Requires 1.4 GB free space! # We could download Extract.exe from the above dir, and use wine to run it, but # may as well use the native command. cabextract -d ~/.wine/c/psdk *.cab # Install. Tries to invoke IE. Doesn't work for me... cd ~/.wine/c/psdk wine Setup.exe # Directly install part of it. Doesn't work for me either; just chews CPU? cd setup wine msiexec /i CoreSDK-x86.msi -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

1 0

Re: define RPC_NO_WINDOWS_H to prevent rpc.h from including windows.h
by Alexandre Julliard 08 Sep '04

08 Sep '04

Mike McCormack <mike(a)codeweavers.com> writes: > ChangeLog: > * define RPC_NO_WINDOWS_H to prevent rpc.h from including windows.h Why do you need this? -- Alexandre Julliard julliard(a)winehq.org

2 4

Re: Wine and industrial communication like OPC
by Rickard Svensson 08 Sep '04

08 Sep '04

> > > > Now I also got some questions from your answers: > > > > * Did I understand correctly. Wine doesn't have a built in support for DCom, to be abel to use Dcom I have to add the DCom support from Windows 98 to the Linux system? > > And the problem with that is the MS License, it stops me from distribute those XXX.dll with a Linux product (hardware and software in this case.) > > It doesn't stop you, basically the license says "you must have a Windows > license to use this code". Because it's technically a part of Windows, see? Yyyy! I hate license issues! I can see that for many people this wouldn't be an issue, because they probably have some old Win 98 CD/Licens somewhere (if they even care). But for a company that would like to send it as part of an embedded computer with Linux I can se a lot of problems. > However a Windows license is quite cheap relative to $3000-$4000 for the > APIs so maybe this isn't a problem. But that was per development project, not per system we want to use OPC in. > You could even buy copies of Windows 98 off ebay or something for > ultra-cheap living. The license can be for any version of Windows AFAIK. That could perhaps be an idea.... What does AFAIK stand for? > The difficulty may be that nobody has tested network DCOM servers on > Wine as far as I know, even using Microsofts implementation. So you'd be > doing some pioneering work :) That is good ;-) In the industry we are a lot of people who really question the total madness of letting the OPC standard be that depended on Windows, when it is supposed to be a "free" organization. My hope if I can get this to work is to publish a site on the net so all who want to use Linux in the industrial computing can do that quite easy... But then we have the license issues to :-( > - Wines own, builtin code. This is incomplete and cannot do what you want. > > - Microsofts DCOM implementation > > Wine *does* have support for MSRPC, and I think it's wire compatible > with Windows these days and capable of making simple RPCs. However the > RPC runtime (rpcrt4.dll) is just the first layer of DCOM, all the rest > don't work right yet. Ok, now I understand, and also why I got confused before. And there is a lot of work needed to make DCom to work in Wine? Is someone working on it or is it something that not is that important in other cases? Thanks a lot Mike for you answer! /Rickard -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

5 4

Re: Fix bin2res Help Text
by Dimitrie O. Paun 07 Sep '04

07 Sep '04

On Mon, Sep 06, 2004 at 02:37:05AM +0100, Robert Shearman wrote: > " /* BINRES idb_std_small.bmp */\n" > - " {}\n" > + " IDB_STD_SMALL BITMAP idb_std_small.bmp\n" > + " /* {\n" > + " } */\n" What's wrong with the current help. I thought BINRES is the marker... -- Dimi.

1 0

More winecfg todos
by Mike Hearn 07 Sep '04

07 Sep '04

On Thu, 29 Jul 2004 23:19:11 -0500, Alexandre Julliard wrote: > Log message: > James Hawkins <truiken(a)gmail.com> > Under the Drives tab, remove the 'Windows Drive' section. You probably want to increase the size of the drive mappings list so it fills the tab, currently there is just a lot of empty space at the top of the pane now you removed the old stuff. Also we should kill the autodetect button. This is done by wineprefixcreate these days, or should be. Other things are: - Drive editing seems broken. The list box only updates the second time I hit edit. err:winecfg:applyDriveChanges unable to set volume label for devicename of 'H:\', label of '' - Browse in the "Add/Edit drive" dialog is a WRITEME - Build system isn't right: I did a cvs update but the res files weren't recreated properly. I had to do a make clean to get the gui updates. - "Add Application" has poor usability: we always use a file browser dialog box even though the most common use case is just "foo.exe", ie the user knows the name and doesn't care about the location. Worse we start in the c:\windows\desktop folder for some reason, meaning users might accidentally select a .lnk file! Ditto for Libraries tab. - The Add/Remove application buttons are *way* too big! - Obviously, once audio autodetection has been moved into the drivers we need to kill the audio tab. - Libraries tab just has generally poor usability, actually. The first item in the radio group is "Builtin" meaning that's the one users are most likely to select, it should be "builtin, native" followed by "native, builtin" - We ask the user to understand a magic * symbol to set the default - what is up with that? - There are no helpful default entries in the drop down box for setting a DLL override, and when you add one the tree does not expand so to actually *set* it you have to expand the tree then select the new override. - We have way too many (eg, more than zero) tree controls in this app. - Drive mappings list is really unclear, there's no separation between the "Drive X:" label and the unix path its mapped to. Basically I'd recommend reading the GNOME HIG: http://developer.gnome.org/projects/gup/hig/ it's a very informative read. Obviously we have to use Win32 UI conventions at least at first, but there's a lot of generically good advice there. Well worth reading for anybody who is going to work on winecfg. thanks -mike

4 4

Re: Create DLL stub files in c:\windows\system
by Hans Leidekker 07 Sep '04

07 Sep '04

On Saturday 4 September 2004 14:25, Mike Hearn wrote: > Make apps that search for the DLL files directly happy by creating empty > files for each shipped library There are applications (eDonkey is one of them IIRC) that call LoadLibray() themselves on a number of DLLs. Could be that they do their own linking as part of some anti-debugging technique, I don't know, but it's perfectly legal for application to do that anyway. For these apps having empty DLL files will not be enough. I actually was able to fool the app by putting MinGW cross compiled Wine DLLs in the system directory until it needed kernel32.dll, which doesn't compile. I had to resort to a native win2k kernel32.dll to get it past this but this may still be a good alternative to your empty DLL files. -Hans

8 17

Re: windos: fix EXTENDED COUNTRY INFORMATION
by Vincent Béron 07 Sep '04

07 Sep '04

Le mar 07/09/2004 à 06:10, Markus Amsler a écrit : [snip] > *** wine/dlls/winedos/int21.c Tue Aug 24 17:45:23 2004 > --- wine-20040615/dlls/winedos/int21.c Fri Aug 6 11:57:04 2004 > *************** > *** 2116,2123 **** > static void INT21_ExtendedCountryInformation( CONTEXT86 *context ) > { > BYTE *dataptr = CTX_SEG_OFF_TO_LIN( context, context->SegEs, context->Edi ); > ! BYTE buffsize = CX_reg (context); > ! > TRACE( "GET EXTENDED COUNTRY INFORMATION, subfunction %02x\n", > AL_reg(context) ); Please send your patches in diff unified (diff -u) format. Vincent

1 0

Re: Wine Developer Cheatsheet, v1
by Rolf Kalbermatter 07 Sep '04

07 Sep '04

"Diego 'Flameeyes' =?ISO-8859-1?Q?Petten=F2?=" wrote: >I have only a doubt: > >> - Is it possible to implement the ANSI version by converting to unicode >> then calling the wide version, rather than duplicate it? > >How can I convert an ansi string to a unicode one and reverse? So I can redo >the patch with the calls :) Typically you use MultiByteToWideChar() for any input strings and then WideCharToMultiByte() for possible output strings. You can look at shlwapi/path.c and other files in there to see how this is usually done. Depending on the place where you do it, it might be preferable to use dynamically allocated buffers instead of using stack space as Wine is already using quite a lot of stack. Principle: WCHAR *textW; INT countW = MultiByteToWideChar(CP_ACP, 0, textA, -1, NULL, 0); if((textW = HeapAlloc(GetProcessHeap(), 0, countW * sizeof(WCHAR)))) { MultiByteToWideChar(CP_ACP, 0, textA, -1, textW, countW); /* Do the Widechar call */ HeapFree(GetProcessHeap(), 0, textW); } Rolf Kalbermatter

4 4

RE: iostream and msvcrt?
by Scott Snell 07 Sep '04

07 Sep '04

Hi Dimi, Thanks for helping out. I made the changes you suggested to the gcc-mingw.mak file for STLPort. When I go make it does a: wineg++ -I../stlport -W -Wno-sign-compare -Wno-unused -Wno-uninitialized -mno-cygwin -O2 -D_STLP_USE_DYNAMIC_LIB dll_main.cpp -c -o ../lib/obj/MINGW32/ReleaseD/dll_main.o which throws up a world of errors, such as: In file included from ../stlport/cstdlib:25, from ../stlport/stl/debug/_debug.c:160, from ../stlport/stl/debug/_debug.h:418, from ../stlport/utility:40, from dll_main.cpp:35: /usr/include/c++/3.3.2/cstdlib:97: error: `div' not declared /usr/include/c++/3.3.2/cstdlib:102: error: `ldiv' not declared /usr/include/c++/3.3.2/cstdlib: In function `ldiv_t std::div(long int, long int)': I'm sure its something simple but I'm still not comfortable around gcc/winegcc. thanks, Scott. > -----Original Message----- > From: Dimitrie O. Paun [SMTP:dpaun@rogers.com] > > On Wed, Aug 18, 2004 at 11:32:33AM +0300, Boaz Harrosh wrote: > > > > > Better go with gcc-mingw.mak, as threading and OS is more Windows than > > Linux. See if they have a -nocygwin variant. > > Yes, it should work with the gcc-mingw.mak by changing > gcc -> winegcc > g++ -> wineg++ > > > >adding a path pointing to /include/wine/MSVCRT. > > > > > No, you shouldn't need that. You just need to make sure you pass > the -mno-cygwin flag to winegcc/wineg++. > > -- > Dimi.

3 2

Re: PathSearchAndQualify and other shlwapi fixes
by Robert Shearman 07 Sep '04

07 Sep '04

Diego 'Flameeyes' Pettenò wrote: >Ok thanks to Mike and Rofl I was able to clean the patch up (at least I hope >so :) > >ChangeLog: >- Write partially PathSearchAndQualify (there is a FIXME) with A->W call >[dlls/shlwapi/path.c] >- Add to PathCreateFromUrl support for file:/// urls (with 3 '/' ) >[dlls/shlwapi/path.c] >- Add to UrlCanonicalize the URL_FILE_USE_PATHURL flag's support. >[dlls/shlwapi/url.c] >- Add to UrlIs support for URLIS_DIRECTORY and URLIS_FILEURL flags >[dlls/shlwapi/url.c] >- Fixes UrlCreateFromPath [dlls/shlwapi/url.c] > > One patch for each atomic change please. It makes it easier to review and more likely to get the changes into CVS. Rob

1 0

Using winelib in python module
by Nikolay A. Liber 07 Sep '04

07 Sep '04

Hi All Have anybody tried to use winelib in python modules? I need to make python bindings to some propritary DLL that available as a binary only. I made shared library that simply dynamicaly loads that DLL using winelib mono hack. It works perfectly when I link it with simple C test program but crashes when I load in python module. Just a call to SharedWineInit() causes python to crash Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1075433600 (LWP 2477)] server_init_process () at ../../include/winnt.h:1543 1543 __asm__(".byte 0x64\n\tmovl (0x18),%0" : "=r" (teb)); (gdb) bt #0 server_init_process () at ../../include/winnt.h:1543 #1 0x40497ca7 in thread_init () at thread.c:141 #2 0xbfffc588 in ?? () #3 0x40039500 in dlerror () from /lib/tls/libdl.so.2 #4 0x00000000 in ?? () #5 0xbfffd830 in ?? () #6 0xbfffc588 in ?? () #7 0x404b6140 in forcedWinVersion () from /usr/local/lib/wine/ntdll.dll.so #8 0x4003af54 in ?? () from /lib/tls/libdl.so.2 #9 0x00001f98 in ?? () #10 0x00000000 in ?? () #11 0x00000000 in ?? () #12 0x404b7000 in ?? () #13 0x00001f98 in ?? () #14 0x4003003b in pthread_rwlockattr_setkind_np () from /lib/tls/libpthread.so.0 #15 0x400390b0 in dlsym () from /lib/tls/libdl.so.2 #16 0x4003af54 in ?? () from /lib/tls/libdl.so.2 #17 0xbfffd830 in ?? () #18 0xbfffd830 in ?? () #19 0xbfffc5f8 in ?? () #20 0x40039096 in dlsym () from /lib/tls/libdl.so.2 #21 0x0817fd70 in ?? () #22 0x404b4820 in __JCR_LIST__ () from /usr/local/lib/wine/ntdll.dll.so #23 0xbfffd830 in ?? () #24 0xbfffd820 in ?? () #25 0xbfffc5f8 in ?? () #26 0x40480e48 in __wine_process_init (argc=-1995430796, argv=0xe804245c) at loader.c:2036 Previous frame inner to this frame (corrupt stack?) (gdb) If there are any ways to initialize winelib from python module may be other than mono hack? Please answer by mail fw(a)tehn.ru Thank you

2 1

Re: Wine and industrial communication like OPC
by Rickard Svensson 07 Sep '04

07 Sep '04

----- Original Message ----- From: Juan Lang <juan_lang(a)yahoo.com> Date: Sun, 5 Sep 2004 21:59:37 -0700 (PDT) To: riq(a)mail.com Subject: Re: Wine and industrial communication like OPC > > * We want to make a OPC server, because other > > computers want to get information from our system. > > Is there a problem in make a DCOM server, is it the > > "no user can acsas port under 1024 on a Linux > > system" problem. > > It's a problem for lots of reasons. They add up to > this: this is unimplemented in Wine, and probably > won't be implemented any time soon. To bad, I ges that it wil take same time to inplement all the parts of DCom in Wine ;( > > * What I have heard I thought DCom uset RPC??? But > > Juan Lang wrote that Wine doesn't have support for > > RPC > > Did I? I certainly didn't mean it. But you'd need to > install the DCOM98 update to have any chance of > success at it for now, at least if I read the code > right. You wrote: < Date: Thu, 2 Sep 2004 08:27:49 -0700 (PDT) < From: Juan Lang <juan_lang(a)yahoo.com> < This method would allow us to act as a CIFS (TCP port 445) client. < Acting as an SMB (TCP port 139) client isn't handled by the CIFS < module, it's done by the SMBFS module. Not sure what Steve's < plans are here. < Anyway, any of you guys interested in seeing RPC work under Wine < (Greg, you still lurking around here?) might want to play around < with this if you have time. I might myself once I land somewhere < for a while, but no promises. But perhaps I grabd that out of contens, you ment in this case. Thanks a lot Juan for you answer! /Rickard -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

1 0

Re: RESEND: CreateDIBitmap: Don't create monochrome bitmaps
by Dmitry Timoshkov 07 Sep '04

07 Sep '04

"Huw D M Davies" <h.davies1(a)physics.ox.ac.uk> wrote: > + /* Need to check if the bitmap is monochrome, and if the > + two colors are really black and white */ > + if (is_dib_monochrome(pbi)) > + { > + /* Top-down DIBs have a negative height */ > + DWORD height = pbi->bmiHeader.biHeight; > + if (height < 0) height = -height; [skipped] > + /* If it's possible, create a monochrome bitmap */ > + > + DWORD height = fix_info->bmiHeader.biHeight; > + if (height < 0) height = -height; In the code above 'DWORD height' should be changed to 'LONG height' otherwise the test 'height < 0' will always fail. -- Dmitry.

1 0

D3D7: textures, mipmaps, DDSCAPS_COMPLEX
by andrejoh＠c2i.net 06 Sep '04

06 Sep '04

Hi! First some good news (for me at least): Cedega from CVS can now be used to play Anarchy Online! [1] To get this working, Marius Grigoriu had to implement support for DDSCAPS_COMPLEX in the Cedega code; this support seems to be lacking in Wine. I've had a look at the patch, and both the Cedega and Wine implementations -- they are quite similar, but do have some differences in the texture creation part. In particular, Cedega has a lot of additional code in create_texture, and the parts in Wine's version seems to reside in the function create_mipmaps in the Cedega file (dlls/ddraw/ddraw/main.c). As far as I've understood things, the Cedega DDraw code is under the AFPL license, and cannot be merged with the Wine LPGL code; thus I've not looked further into that (the changes seems to be related to cube map support). However, the patch from Marius is released under the X11 license, and can be applied to Wine with minor tweaking (due to support for compressed textures in the Wine code). Should this be applied to the Wine tree (depending on me having ported it correctly, of course)? For reference, I've included the related part from the original patch as well (see also [1]). Unfortunately, even with this patch, running AO under Wine crashes with some texture related code: First chance exception: divide by zero in 32-bit code (0x419c6d5c). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:003b GS:0033 EIP:419c6d5c ESP:4085e784 EBP:4085e7e4 EFLAGS:00210246( - 00 -RIZP1) EAX:00000000 EBX:00000002 ECX:00000000 EDX:00000000 ESI:4085e958 EDI:00000002 Stack dump: 0x4085e784: 4085e984 4085e928 40530088 0000007c 0x4085e794: 0010180f 00000100 00000100 00000200 0x4085e7a4: 00000000 00000000 00000000 00000000 0x4085e7b4: 50bb0000 00000000 00000000 00000000 0x4085e7c4: 00000000 00000000 00000000 00000000 0x4085e7d4: 00000000 00000020 00000041 00000000 Backtrace: =>1 0x419c6d5c _D3DXLoadTextureFromSurface@28+0x3e9 in randy31d (0x4085e7e4) 2 0x00007c00 (0x00000010) 3 0x00000000 (0x00000000) 0x419c6d5c _D3DXLoadTextureFromSurface@28 in randy31d: divl 0x40(%ebp),%eax Wine-dbg>bt Backtrace: =>1 0x419c6d5c _D3DXLoadTextureFromSurface@28+0x3e9 in randy31d (0x4085e7e4) 2 0x00007c00 (0x00000010) 3 0x00000000 (0x00000000) Doing "bt all" crashes the debugger with this message after getting a listing of one thread: wineserver: debugger.c:477: debugger_detach: Assertion `event->sender->debug_event == event' failed. I've been unable to figure out what happens here, but I assume it might be caused by an invalid texture surface. Hacking in the AO code base (as in disabling certain textures), I've been able to get all the way into the client, but with almost no rendering. Any further help would be greatly appreciated! [1] http://www.csh.rit.edu/~marius/aolinux/ -- Try Anarchy Online http://www.anarchy-online.com/content/downloads/tryout/ Netiquette guidelines ftp://ftp.rfc-editor.org/in-notes/rfc1855.txt How to quote properly http://www.i-hate-computers.demon.co.uk/ Hvordan sitere riktig http://home.online.no/~vidaandr/news/OBSquoting.html

1 0

Re: CreateDirectoryW improvement
by Uwe Bonnes 06 Sep '04

06 Sep '04

>>>>> "Wolfgang" == Wolfgang Schwotzer <wolfgang.schwotzer(a)gmx.net> writes: Wolfgang> Description: Return error ERROR_ALREADY_EXISTING if an Wolfgang> existing drive (e.g. 'C:') without '\\' is specified Wolfgang> ChangeLog: CreateDirectoryW: Return error Wolfgang> ERROR_ALREADY_EXISTING e.g. for path 'C:' Wolfgang> Index: dlls/kernel/path.c Wolfgang, having some test cases in our test suite for those problems is a good idea... Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Don't crash on failing DRIVER_FindFromHDrvr
by Uwe Bonnes 06 Sep '04

06 Sep '04

Hallo, I sent a patch to prevent wine from crashing last friday. It happend, when DRIVER_FindFromHDrvr returned NULL. No I found out, that I had sent that patch before last year. Eric answered > this doesn't seem right to me: either the loading fails and we shouldn't > get a valid handle, or it succeeds and we should be able to find it > there's must be something wrong elsewhere > could you please send a -debugmsg +driver,+module,+winmm to see what > happens ? and like before, I can't reproduce the error after reverting the patch: > the error no longer exists. I guess some registry entry was corrupt and a > successfull run corrected it later. > > However I see a lot of check after DRIVER_FindFromHDrvr() in other parts of > the code... If one dose "grep -3 DRIVER_FindFromHDrvr wine/dlls/winmm/*", every other usage of DRIVER_FindFromHDrvr is like if ((lpDrv = DRIVER_FindFromHDrvr(hDrvr)) != NULL) Why should expecting a NULL return be wrong? It happens, as the the crashes show. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 4

Re: Battlefield 1942 d3d8 crash
by Ann and Jason Edmeades 06 Sep '04

06 Sep '04

Does changing the line 575 (in device.d, dlls/d3d8) to be if (ppBackBuffer) IDirect3DSurface8Impl_AddRef((LPDIRECT3DSURFACE8) *ppBackBuffer); make any difference - Looks like the app is doing an odd way to work out how many back buffers there are. Jason

2 2

dlls/msvcrt/time.c picks up wrong CLOCKS_PER_SEC define
by Uwe Bonnes 06 Sep '04

06 Sep '04

Hallo, wine/include/msvcrt/time.h defines CLOCKS_PER_SEC conditionally: #ifndef CLOCKS_PER_SEC #define CLOCKS_PER_SEC 1000 #endif in wine/dlls/msvcrt/time.c, <time.h> is included and defines CLOCKS_PER_SEC unconditional before to 1000000l. So MSVCRT_clock returns a value 1000 times to high. How should this be fixed? Should wine/dlls/msvcrt/time.c do the define unconditional? Do we need to use a different define (e.g. MSVCRT_CLOCKS_PER_SEC) in MSVCRT_clock()? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: PROPSHEET: Fix wizard regression
by Filip Navara 06 Sep '04

06 Sep '04

Filip Navara wrote: > This fixes the regression caused by the Mike McCormack's patch and > solves the problem with Macromedia Flash MX in the correct way. There > is still other problem with Macromedia Flash MX when you check the > options on the "Publish Settings" if anyone wants to jump in and solve > that... > > Changelog: > - Revert incorrect change to tab control resizing from revision 1.109. > - Move the property sheet resizing code from PROPSHEET_CreatePage to > PROPSHEET_SetCurSel. It needs to be executed on every page change > because the application can modify it during the notifications. Use the attached patch instead please. Regards, Filip

1 0

Re: Wine Developer Cheatsheet, v1
by Mike Hearn 06 Sep '04

06 Sep '04

> That's is very interesting and useful, but I think there's two things that > can be improved: first the debug delay patch, I wasn't able to find it out > searching with gmane, maybe if you can add a link to the post on gmane it > should be better :) Yeah, it's a bit of a pain keeping track of useful patches that were never merged. Maybe we need a list somewhere. > The second thing is about the coding style. As I said before, I have a patch > for shlwapi which fixes some MSXML/Borland XML Components problems with the > builtin one, which wasn't accepted for some problem about the style and the > placement of the variables. I posted it as a bug at > http://bugs.winehq.org/show_bug.cgi?id=2385 . If you can add something > about the coding style I can fix it up and repost it for inclusion. A few things that jump out at me (not really reviewed the code itself): - No C++ // style comments, I'm afraid. They aren't portable enough. - Use HeapAlloc() over malloc(), as it says in the cheatsheet - Are you sure there is a debugstr_a?? I can't think what it would do, ANSI strings can just be printed by regular printf - You have to declare all the variables at the start of a block. Yes, it's a pain. Another C portability rule. So, can't do this: LPSTR foo = bar; StrCpyA(a, b); int i; They all have to go at the top. - Minor stylistic note: you can use strcpy rather than StrCpyA. But I doubt this was a problem. - Usually best to space stuff out, ie rather than this: if ( temp_out == temp_out2 ) { temp_in += 3; continue; } use this: if ( temp_out == temp_out2 ) { temp_in += 3; continue; } ... again I doubt Alexandre would reject the patch because of this. - //if ( *temp_in == '.' ) ... wine code generally doesn't do this. If you find it hard to match up a closing brace with the statement that opened it maybe you need ... *fanfare* EMACS! :) - Is it possible to implement the ANSI version by converting to unicode then calling the wide version, rather than duplicate it? The rest looks fine, I expect it was just the C portability stuff that tripped you up. Please do try again! thanks -mike

4 4

Re: RESEND: CreateDIBitmap: Don't create monochrome bitmaps
by Huw D M Davies 06 Sep '04

06 Sep '04

Hmm, actually this requires more work, because although CreateDIBitmap is now correct, the patch is messing up the toolbar icons in IE... Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Re: DestroyMenu: Check if the menu is still used (fix for bug 1486)
by Dmitry Timoshkov 06 Sep '04

06 Sep '04

"Michael Kaufmann" <hallo(a)michael-kaufmann.ch> wrote: > Some applications call DestroyMenu for menus that are still displayed in > a window. We need to check if a menu is still used and set the window's > menu handle to NULL if that's the case. > > This patch fixes the important bug 1486. > > Changelog: > - DestroyMenu: Check if the menu is still displayed and adjust the > window's menu handle There is a test case in Wine (dlls/user/tests/win.c,test_SetMenu) which shows that your patch is wrong. It was said many times already that the real fix for that bug is to move all user object management into wineserver and use the same handle allocation scheme as the one used for windows. -- Dmitry.

4 4

Possible fun project/todo list item?
by Mike Hearn 06 Sep '04

06 Sep '04

The OpenSSL library we use in wininet/netconnection.c is a very unstable library, with somewhat odd licensing as well. By unstable I'm talking about the interfaces it exports: unfortunately they break backwards compatibility very frequently with the result that a build of Wine compiled on one system may bail out when using SSL on another, as the soname/abi of OpenSSL it's looking for has changed *yet again*. This also means that some distros deliberately ship older versions and just backport security fixes, as upgrading OpenSSL to newer versions is quite painful. Fedora at least does this. If anybody is looking for work to do then, addressing this problem may be useful. Probably the best way forward is to talk to the GnuTLS people (http://www.gnu.org/software/gnutls/gnutls.html) and see if you can get written confirmation from them that they have a strong commitment to binary compatibility (at least, more than OpenSSL does). It also seems to be a fairly stable project: the new maintainer is more focussed on portability enhancements and a slow release cycle than making huge changes to the code. If so, it might be worth porting wininet over to GnuTLS, or alternatively, rather than remove the OpenSSL code just add code to use GnuTLS and then fall back to OpenSSL if it cannot be found (or vice-versa). One interesting thing about GnuTLS is that it has some OpenSSL compatibility code, but from a look at their website it seems that this is GPLd. Maybe we could get an exemption from them. The downside is that while OpenSSL is frequently going to not be found as it's the wrong version, GnuTLS is also not widely installed by default so it might not get us much in the short term. The good news is that Gaim packages are often built against it, so in any modern distro that packages Gaim (which is a very popular chat client) in its repositories, there's a good chance GnuTLS is packaged as well. thanks -mike

5 11

Battlefield 1942 d3d8 crash
by Robert Reif 06 Sep '04

06 Sep '04

I get the following crash when running the Battlefield 1942 single player demo from http://www.3dgamers.com/games/battlefield1942/ fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x40361cd8)->(00000000,00000008) trace:d3d:Direct3DCreate8 SDKVersion = dc, Created Direct3D object at 0x40362218 fixme:d3d_caps:IDirect3D8Impl_FillGLCaps found GL_VERSION ("1.5.1 NVIDIA 61.06")->(0x003d17da) fixme:d3d_caps:IDirect3D8Impl_FillGLCaps found GL_RENDERER ("GeForce FX 5200/AGP")->(0x0250) trace:d3d:IDirect3D8Impl_CreateDevice (0x40362218)->(Adptr:0, DevType: 1, FocusHwnd: 0x10022, BehFlags: 80, PresParms: 0x41fc40b8, RetDevInt: 0x41fc409c) trace:d3d:IDirect3D8Impl_AddRef (0x40362218) : AddRef from 1 trace:d3d:IDirect3DDeviceImpl_CreateStateBlock (0x40362498) : Type(1) trace:d3d:IDirect3D8Impl_CreateDevice (0x40362218)->(DepthStencil:(75,D3DFMT_D24S8), BackBufferFormat:(22,D3DFMT_X8R8G8B8)) trace:d3d:IDirect3D8Impl_CreateDevice Context created (HWND=0x10022, glContext=0x43044054, Window=41943042, VisInfo=0x43043de0) fixme:d3d:IDirect3DDevice8Impl_Reset (0x40362498) : stub trace:d3d:IDirect3DDevice8Impl_GetBackBuffer (0x40362498) : BackBuf 0 Type 0 returning (nil) wine: Unhandled exception (thread 0009), starting debugger... fixme:console:SetConsoleCtrlHandler (0x4074a8f8,1) - no error checking or testing yet WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x00000004 in 32-bit code (0x40df748b). In 32 bit mode. 0x40df748b IDirect3DSurface8Impl_AddRef [/home/wine/wine/dlls/d3d8/surface.c:59] in d3d8: movl 0x4(%esi),%eax 59 return ++(This->ref); 59 return ++(This->ref); Wine-dbg>>bt Backtrace: =>1 0x40df748b IDirect3DSurface8Impl_AddRef+0x23(iface=0x0) [/home/wine/wine/dlls/d3d8/surface.c:59] in d3d8 (0x4081e84c) 2 0x40dd7216 IDirect3DDevice8Impl_GetBackBuffer+0x76(iface=0x40362498, BackBuffer=0x0, Type=0x0, ppBackBuffer=0x41fc40a0) [/home/wine/wine/dlls/d3d8/device.c:577] in d3d8 (0x4081e864) 3 0x00848ec0 (0x00000000) Wine-dbg>

1 0

Re: Wine and industrial communication like OPC
by Rickard Svensson 06 Sep '04

06 Sep '04

Thank you, for all your answers! We have one employee who has worked a lot with Windows, and same with OPC. So I can provide same answers. * Mike Hearn - OPC is mostly used for data collection, and to a lesser degree to control industrial machines. * Juan Lang AND Robert Shearman - OPC doesn't use named pipes. OPC uses Dcom over TCP. * Mike Hearn - OPC doesn't need any new Windows (2000, XP) parts, and should work on Win 98 with the added Dcom support (not tested). * Mike Hearn - Price of OPC for Linux was when I looked at it for about a year ago 3000 - 4000$ per project you used their API in. And it only supported one of the OPC versions. Now I guess that the prices has been going down... Now I also got some questions from your answers: * Did I understand correctly. Wine doesn't have a built in support for DCom, to be abel to use Dcom I have to add the DCom support from Windows 98 to the Linux system? And the problem with that is the MS License, it stops me from distribute those XXX.dll with a Linux product (hardware and software in this case.) * We want to make a OPC server, because other computers want to get information from our system. Is there a problem in make a DCOM server, is it the "no user can acsas port under 1024 on a Linux system" problem. * What I have heard I thought DCom uset RPC??? But Juan Lang wrote that Wine doesn't have support for RPC /Rickard -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

2 1

Re: InternetReadFile, FTP and partial buffers
by Uwe Bonnes 06 Sep '04

06 Sep '04

>>>>> "Krzysztof" == Krzysztof Foltman <kfoltman(a)portal.onet.pl> writes: Krzysztof> Hi All, In the original WinInet FTP implementation, Krzysztof> InternetReadFile always returns complete buffers, except for Krzysztof> the last block. Some programs (probably ill-behaving ones, Krzysztof> but I wouldn't bet my head on it) rely on that fact, and stop Krzysztof> retrieving the file after the first incomplete block. I met the same problem for the HTTP implementation. The MSG_WAITALL flag sent to recv should always retrieve buffers of the requested size, if possible. Can you please try your problem with the MSG_WAITALL flag instead your patch? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ---------- Index: wine/dlls/wininet/internet.c =================================================================== RCS file: /home/wine/wine/dlls/wininet/internet.c,v retrieving revision 1.95 diff -u -w -r1.95 internet.c --- wine/dlls/wininet/internet.c 19 Aug 2004 19:02:17 -0000 1.95 +++ wine/dlls/wininet/internet.c 4 Sep 2004 22:09:59 -0000 @@ -1632,7 +1632,7 @@ { case WH_HHTTPREQ: if (!NETCON_recv(&((LPWININETHTTPREQW)lpwh)->netConnection, lpBuffer, - dwNumOfBytesToRead, 0, (int *)dwNumOfBytesRead)) + dwNumOfBytesToRead, MSG_WAITALL, (int *)dwNumOfBytesRead)) { *dwNumOfBytesRead = 0; retval = TRUE; /* Under windows, it seems to return 0 even if nothing was read... */

1 0

Re: Wine and industrial communication like OPC
by Juan Lang 06 Sep '04

06 Sep '04

Rickard wrote: > * Juan Lang AND Robert Shearman - OPC doesn't use > named pipes. OPC uses Dcom over TCP. > * Mike Hearn - OPC doesn't need any new Windows > (2000, XP) parts, and should work on Win 98 with the > added Dcom support (not tested). Cool! This has a chance of working then. > * Did I understand correctly. Wine doesn't have a > built in support for DCom, to be abel to use Dcom > I have to add the DCom support from Windows 98 to > the Linux system? Yes, that appears to be true. Wine's rpcrt4.dll only works between programs running in the same Wine instance. > * We want to make a OPC server, because other > computers want to get information from our system. > Is there a problem in make a DCOM server, is it the > "no user can acsas port under 1024 on a Linux > system" problem. It's a problem for lots of reasons. They add up to this: this is unimplemented in Wine, and probably won't be implemented any time soon. > * What I have heard I thought DCom uset RPC??? But > Juan Lang wrote that Wine doesn't have support for > RPC Did I? I certainly didn't mean it. But you'd need to install the DCOM98 update to have any chance of success at it for now, at least if I read the code right. --Juan __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail

1 0

shell32 unicodefy question
by Vitaliy Margolen 05 Sep '04

05 Sep '04

First of all I would like to check if there are any one working on this. Second Q: Some methods of IFSHelper interface defined as taking LPCSTR params. Is this right? I was unable to find any information in regards to this. And because this is exported interface I don't want to brake something that is already working. -- Best regards, Vitaliy

1 0

Re: Compile fix forinclude files from linux 2.6.7
by Marcus Meissner 05 Sep '04

05 Sep '04

On Sun, Sep 05, 2004 at 05:38:03PM +0200, Rein Klazes wrote: > Hi, > > Fix for bugzilla bug#2354, compile failure on Slackware 10. > > The include <linux/fd.h> uses since Linux 2.6.7 a macro defined in > <linux/compiler.h>. Compiler.h is new in linux 2.4.4, old but not very > old, so I added an autoconf check for such systems. > > Need to run autoheader & autoconf after applying. No, if it is missing __user, just #define __user at the beginning of the file. Or try not to use linux kernel headers at all. Ciao, Marcus

2 1

Re: Critical Sections Documentation Update
by Hans Leidekker 05 Sep '04

05 Sep '04

On Sunday 5 September 2004 13:26, Robert Shearman wrote: > - * Initialise a new RTL_CRITICAL_SECTION. > + * Initializes a new critical section. I'm afraid this critical section from your critical section patch will upset people in the critics' section ;-) -Hans

1 0

Re: weird ?clipping? errors
by Filip Navara 05 Sep '04

05 Sep '04

Filip Navara wrote: > James Hawkins wrote: > >>> If the error disappears, then you're dealing with a bug in Wine's >>> comctl32.dll. >>> >> >> >> I used native comctl32.dll and both of the errors disappeared, so I >> will take your advice and search around in comctl32. >> >> > It's regression in dlls/comctl32/propsheet.c that happend between > revision 1.105 and 1.112. To be more specific, it's this patch: Mike McCormack <mike(a)codeweavers.com <mailto:mike@codeweavers.com>> Adjust the tab contents to fix the propsheet between PSM_KILLACTIVE and PSM_SETACTIVE. Regards, Fi;lip

3 3

fixme:msi:MsiLocateComponentA installing dotnetredist.exe
by Dan Kegel 05 Sep '04

05 Sep '04

I installed wine-20040813 from source, then tried installing http://msdn.microsoft.com/visualc/vctoolkit2003/ (I think this gets a ways further than it did last time I tried it, yay.) Now it fails with the error I: Error installing Microsoft(R) .NET Framework. http://download.microsoft.com/download/e/b/2/eb247c2a-e6b3-4694-98a2-b27111… On the console, I saw only the four warnings/errors: fixme:msi:MsiInstallProductW L"/iH:\\IS3123.tmp\\netfx.msi" L"" fixme:msi:MSI_OpenDatabaseW open failed r = 80004005! Installation of /iH:\IS3123.tmp\netfx.msi () failed. err:dc:DCE_FreeWindowDCE [0x10026] GetDC() without ReleaseDC()! So I downloaded dotnetredist.exe and ran that by hand, and then ran the executable that unpacked. This failed with fixme:msi:MsiLocateComponentA "{A1B926EF-7FD9-11D2-A429-00A0C9E80AFB}" 0x4051ec84 00000105 fixme:msi:MsiLocateComponentA "{173A6EB3-6403-11D4-A53F-0090278A1BB8}" 0x4051ec84 00000105 That function, at least in my tree, is just a pseudostub: INSTALLSTATE WINAPI MsiLocateComponentA(LPCSTR szComponent, LPSTR lpPathBuf, DWORD *pcchBuf) { FIXME("%s %p %08lx\n", debugstr_a(szComponent), lpPathBuf, *pcchBuf); return INSTALLSTATE_UNKNOWN; } Sooo... what's the best way around this? Anyone tackle this before? Thanks, Dan -- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change

3 2

Wine bug with delphi Menus
by Robert van Herk 05 Sep '04

05 Sep '04

Hi people, I think I discovered a wine bug. In a delphi program, changing the visibility of a menuitem (TMenuItem) causes the whole menu of that form to stop working, when the program is run under Wine. Behind the screens, the setVisible of a menu item calls MenuChanged. This seems to put the menu in such a state that, in wine, all menu components stop doing anything. I've written a small application (455 kb EXE) to show what goes wrong. Would anybody be interested to help me in solving this bug? Would a message trace from Winsight (for example) be of any help? Greetings, Robert

2 1

Re: Running valgrind with Wine
by Saulius Krasuckas 05 Sep '04

05 Sep '04

On Sat, Sep 04 2004, Mike McCormack wrote: > Valgrind stopped working with Wine a while back due to the way Wine > reserves memory above address 0x80000000. > > The following patch allows valgrind to work with wine again. You need to > start wine-pthread or wine-kthread instead of starting the wine binary > depending on whether your system uses NPTL or not. eg. my system uses > kthreads so: > > valgrind wine-kthread notepad.exe I am very glad to hear this, Mike. Thanks. > I'm not sure if Alexandre wants to commit this or not, but it should be > of use to those that want to use valgrind again. Hm, still, for me valgrind doesn't work: [s2@katleriai wine]$ valgrind --tool=memcheck wine-pthread notepad.exe Executable range 0x77f00000-0x77f02370 is outside the acceptable range (nil)-0x52c00000 valgrind: do_exec(/usr/local/bin/wine-pthread) failed: Cannot allocate memory [s2@katleriai wine]$ Ideas?

2 5

regression: listbox stays disabled in created dialog-window
by Saulius Krasuckas 05 Sep '04

05 Sep '04

The [1] patch brings some regression. I have filled a bugreport: [2]. Here are two png screenshots: [3] [4], one made before the patch is applied, another made after the patch is applied. [1] http://www.winehq.org/hypermail/wine-cvs/2004/08/0341.html [2] http://bugs.winehq.org/show_bug.cgi?id=2454 [3] http://bugs.winehq.org/attachment.cgi?id=681&action=view [4] http://bugs.winehq.org/attachment.cgi?id=682&action=view

6 15

EINTR vs. WSAEINTR
by Shachar Shemesh 05 Sep '04

05 Sep '04

Hi list, When calling "select" (or any other socket function, for that purpose), there is a chance that a signal will arrive while we are blocking on the socket. This will cause the blocking function to return with EINTR. The usual recommendation is to retry the operation if that is the case. http://www.wlug.org.nz/EINTR Our current behavior, at least in "WS_select", is to convert it to WSAEINTR, and return the error. I think this behavior is wrong. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/wi… MSDN says that WSAEINTR is only returned if WSACancelBlockingCall is received during the wait. I have a program for which I can affect the source that fails because of a select call being interrupted. I'm wondering whether it's better to fix the program to retry on WSAEINTR, or to fix wine. One possible fix to Wine is to mask all signals right before calling "select", and restore the signal mask when returning. This will ensure that EINTR will not be received. Can someone more versed in winsock voice an opinion about whether this is indeed a problem in Wine? Shachar

1 0

Re: Running valgrind with Wine
by Mike Hearn 05 Sep '04

05 Sep '04

On Sun, 05 Sep 2004 12:55:33 +0900, Mike McCormack wrote: > - wine_init( argc, argv, error, sizeof(error) ); > + wine_init( argc, argv, error, sizeof(error), reserve ); It's worth noting that any change to this functions prototype breaks the Ardour/Wine VST plugin bridge. Last time this issue was raised the change was reverted. While we're technically not API stable yet, it's painfully obvious that 1.0 is still a long way away. Stability is a policy rather than a target, so we've got to start at some point ....

2 1

weird ?clipping? errors
by James Hawkins 05 Sep '04

05 Sep '04

Hi, After my last patch that fixed a stack-trasher was committed, the Kazaa Lite configuration wizard, KLConfigWizard.exe, can successfuly run to completion, but the user better not press the 'Back' button whilst running through the wizard, because he won't see anything anymore. So the problem is, if the user presses the back button on the wizard, any text or images etc that were originally on that frame of the wizard are now gone and cannot be seen. I have a couple of screenshots to show what im talking about. Take a look at [1]. This is what the user should see when he runs the program initially. You'll notice in [2] that the left hand side of the window does not show what should be shown as seen in [1]. After clicking 'Next' we're presented with [3]. This frame actually is complete (except for a weird ?font spacing? problem at the bottom), but when we press the 'Back' button to go back to the first frame, we have [4]. The entire window is now missing, and that is what happens on all of the windows when you try to go back to them. I've tried to examine the relay traces to see what could be happening, but I just dont know what im supposed to be looking for with this error. It seems to me to be a clipping problem, but that might not be it either. If you have any ideas about this, please let me know, because I'm sure this isnt the only program affected by this bug. [1] http://www.andrew.cmu.edu/user/jhawkins/klite-actual.jpg [2] http://www.andrew.cmu.edu/user/jhawkins/klite-1.jpg [3] http://www.andrew.cmu.edu/user/jhawkins/klite-2.jpg [4] http://www.andrew.cmu.edu/user/jhawkins/klite-3.jpg -- James Hawkins

3 3

Re: Fix Int21 block device read/write
by Eric Pouech 05 Sep '04

05 Sep '04

> This should probably be done by querying NT APIs for drive > attributes (which ones are those?), http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/bas… A+

1 0

Can WINE be made for DOS using GCC for DOS?
by Todd S. 05 Sep '04

05 Sep '04

Hello! My name is Todd, and I know this sounds like a stupid question, but if it was ever possible, could the "WINE" application ever be built with the "DOS" version of GCC/G++ so Windows programs can be executed from DOS-mode? Thanks. Regards, Todd Suess

5 4

Font mapping with wine 20040615
by Florian Zumbiehl 05 Sep '04

05 Sep '04

Hi, I sent this email a week or so ago to wine-users, but got no replies so far. As this possibly requires some deeper knowledge of wine, I'm reposting it here in the hope that some developer will be able to give me some hints. So here it goes: As font aliases as described in the documentation on http://www.winehq.com/ don't work anymore (which seems to be intended as I heard on #winehq), I'm looking for a way to influence the mapping from windows font requests to "Linux fonts" (i.e. X11/FreeType). I'm using the version packaged in Debian testing, 20040615. Any hints? Cya, Florian

1 0

Richedit control
by Mike McCormack 05 Sep '04

05 Sep '04

Hi All, I'm going to play with the richedit control to try get it to draw RTF documents with formatting. My plan is to write a program that can display but not edit, then let somebody else add the editting functionality afterwards :) Once I can get the attached program to work, the plan is to change the code in text-writer.c to add the formatting information to the richedit control via standard richedit messages. If anybody is already working on it, or wants to have a go, let me know. Mike #include <stdio.h> #include <windows.h> #include <winuser.h> #include <richedit.h> void fill_richedit( HWND hwnd ) { PARAFORMAT pf; CHARFORMAT cf; SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "this is a test\n"); // add text on the right memset( &pf, 0, sizeof pf ); pf.cbSize = sizeof pf; pf.dwMask = PFM_ALIGNMENT; pf.wAlignment = PFA_RIGHT; SendMessage( hwnd, EM_SETPARAFORMAT, FALSE, (LPARAM) &pf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "right\n"); // add text in the center memset( &pf, 0, sizeof pf ); pf.cbSize = sizeof pf; pf.dwMask = PFM_ALIGNMENT; pf.wAlignment = PFA_CENTER; SendMessage( hwnd, EM_SETPARAFORMAT, FALSE, (LPARAM) &pf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "centre\n"); // add text on the left memset( &pf, 0, sizeof pf ); pf.cbSize = sizeof pf; pf.dwMask = PFM_ALIGNMENT; pf.wAlignment = PFA_LEFT; SendMessage( hwnd, EM_SETPARAFORMAT, FALSE, (LPARAM) &pf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "left\n"); // add bold text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_BOLD; cf.dwEffects = CFE_BOLD; SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "bold "); // add italic text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_ITALIC | CFM_BOLD; cf.dwEffects = CFE_ITALIC; SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "italic "); // add underlined text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_ITALIC | CFM_BOLD | CFM_UNDERLINE; cf.dwEffects = CFE_UNDERLINE; SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "underline "); // add strikeout text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_ITALIC | CFM_BOLD | CFM_UNDERLINE | CFM_STRIKEOUT; cf.dwEffects = CFE_STRIKEOUT; SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "strikeout"); // add normal text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_BOLD | CFM_ITALIC | CFM_UNDERLINE | CFM_STRIKEOUT; SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) " normal\n"); // add red text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_COLOR; cf.crTextColor = RGB(255,0,0); SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "red "); // add green text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_COLOR; cf.crTextColor = RGB(0,255,0); SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "green "); // add blue text memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_COLOR; cf.crTextColor = RGB(0,0,255); SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "blue\n"); // try some fonts memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_FACE | CFM_SIZE; cf.yHeight = 300; strcpy(cf.szFaceName, "Tahoma"); SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "tahoma "); // try some fonts memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_FACE; strcpy(cf.szFaceName, "Helvetica"); SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "Helvetica "); // try some fonts memset( &cf, 0, sizeof cf ); cf.cbSize = sizeof cf; cf.dwMask = CFM_FACE; strcpy(cf.szFaceName, "Courier"); SendMessage( hwnd, EM_SETCHARFORMAT, SCF_SELECTION, (LPARAM) &cf); SendMessage( hwnd, EM_REPLACESEL, FALSE, (LPARAM) "Courier "); } LRESULT WINAPI ParentWindowProc (HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) { RECT r; HWND hwndRichedit = (HWND) GetWindowLong( hWnd, 0 ); char *cls; //cls = RICHEDIT_CLASS; //cls = "RICHEDIT10A"; cls = "RICHEDIT"; switch(msg) { case WM_CREATE: GetClientRect( hWnd, &r ); hwndRichedit = CreateWindow( cls, "", WS_CHILD | WS_VISIBLE | ES_MULTILINE | ES_SUNKEN, 0, 30, r.right-r.left, r.bottom - r.top - 30, hWnd, NULL, NULL, NULL ); fill_richedit( hwndRichedit ); SetWindowLong( hWnd, 0, (LONG) hwndRichedit ); break; case WM_CLOSE: DestroyWindow(hWnd); break; case WM_LBUTTONDOWN: InvalidateRect( hWnd, NULL, TRUE ); break; case WM_DESTROY: PostQuitMessage( 0 ); break; } return DefWindowProc(hWnd,msg,wParam,lParam); } /*********************************************************************** * * WinMain */ int PASCAL WinMain (HINSTANCE hInstance, HINSTANCE prev, LPSTR cmdline, int show) { WNDCLASS cls; char className[] = "parentclass"; /* To make sure className >= 0x10000 */ char winName[] = "Richedit control"; HWND hWnd; MSG msg; LoadLibrary("riched32"); cls.style = CS_HREDRAW | CS_VREDRAW | CS_GLOBALCLASS; cls.lpfnWndProc = ParentWindowProc; cls.cbClsExtra = 0; cls.cbWndExtra = 4; cls.hInstance = 0; cls.hIcon = LoadIcon (0, IDI_APPLICATION); cls.hCursor = LoadCursor (0, IDC_ARROW); cls.hbrBackground = GetStockObject (WHITE_BRUSH); cls.lpszMenuName = 0; cls.lpszClassName = className; if (!RegisterClass (&cls)) return FALSE; /* Setup windows */ hWnd = CreateWindow (className, winName, WS_OVERLAPPEDWINDOW , CW_USEDEFAULT, CW_USEDEFAULT, 300, 300, 0, NULL, hInstance, 0); ShowWindow (hWnd, show); UpdateWindow (hWnd); /* now enter mesage loop */ while( 0 != GetMessage( &msg, 0, 0, 0 ) ) { TranslateMessage( &msg ); DispatchMessage( &msg ); } return 0; }

2 2

"Incompatible Systemanalyzer detected"
by Uwe Bonnes 05 Sep '04

05 Sep '04

Hallo, some programm refuses to start. First it checks for the usual suspects: Call kernel32.CreateFileA(0040a89e "\\\\.\\SICE" Ret kernel32.CreateFileA() retval=ffffffff Call kernel32.CreateFileA(0040a8a7 "\\\\.\\NTICE" Ret kernel32.CreateFileA() retval=ffffffff Call advapi32.RegOpenKeyExA(80000002,0040a24e "Software\\NuMega\\SoftIce" Ret advapi32.RegOpenKeyExA() retval=00000002 Call kernel32.CreateFileA(0040a5a3 "\\\\.\\CMAPIENG" Ret kernel32.CreateFileA() retval=ffffffff Then it checks for GetModuleHandle and GetProcAddres Call kernel32.GetModuleHandleA(0040a572 "Kernel32.dll") Ret kernel32.GetModuleHandleA() retval=40450000 Call kernel32.GetProcAddress(40450000,0040a57f "LoadLibraryA") Ret kernel32.GetProcAddress() retval=40517bd0 ret=0040a60b and immediate hits an exception, which is handled: trace:seh:EXC_RtlRaiseException code=c0000005 flags=0 addr=0x4123a1 trace:seh:EXC_RtlRaiseException info[0]=00000001 trace:seh:EXC_RtlRaiseException info[1]=00000000 trace:seh:EXC_RtlRaiseException eax=00000000 ebx=405294ac ecx=00400000 edx=00400000 esi=ffffffa8 edi=00405000 trace:seh:EXC_RtlRaiseException ebp=0000a000 esp=4067ff10 cs=0073 ds=007b es=007b fs=003b gs=0033 flags=00010212 trace:seh:EXC_CallHandler calling handler at 0x410bcc code=c0000005 flags=0 trace:seh:EXC_CallHandler handler returned 0 0009:Call user32.MessageBoxA(00000000,004c6142 "Incompatible Systemanalyzer detected!\n(#2000)",004c5ac0 "Sparbuch 2004",00010010) ret=004c95eb Similar failure on the net also come up with an additional message: "Kernel32 call does not point into Kernel32.dll" Is this an misbehavoiur of wine we can (want) to fix? Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

3 3

Wine Developer Cheatsheet, v1
by Mike Hearn 05 Sep '04

05 Sep '04

Hi guys, Back in February at WineConf one of the issues (I) raised was that there's a lot of stuff you just have to know in order to hack Wine, and that raises the barrier to entry. So, I wrote this. If anybody has stuff they think should be added, let me know. If the community likes it, I'll submit it as a patch against the website: http://navi.cx/~mike/wine/developer-cheatsheet.html thanks -mike

4 3

Drowning in FIXMEs...
by Chris Rankin 04 Sep '04

04 Sep '04

Hi, I am almost running an old DOS-based application using wineconsole, but I am constantly being bombarded by FIXME messages from the DOSVM's Int33 calls for "Show mouse cursor" and "Hide mouse cursor". I have tracked the relevant code down to dlls/winedos/int33.c, but don't know how the DOSVM displays the mouse cursor. There must be a link somewhere between the coordinates in the mouse_info structure and the X11 display. Can anyone help me out here, please? Thanks, Chris ___________________________________________________________ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

2 4

Re:Re: (no subject)
by Pablo Szuster 04 Sep '04

04 Sep '04

Am Freitag, 3. September 2004 22:35 schrieb Pablo Szuster: > Hi, i´m trying to access a MSSQL server (in a windows machine in the > network) from a Visual Basic Application running under wine, using an ODBC > driver. Since there aren´t any MSSQL drivers for linux i decided to use de > native ones, so i installed mdac_typ.exe . Then i configured the DSN using > odbcad32.exe but when i tested the connection (configured using tcp/ip) an > error message appeared ("[Microsoft][ODBC SQL Server Driver][TCP/IP > Sockets] General network error. Check your network documentation"). Do i > have to install some network drivers for wine?? Has anyone been able to > connect to a MSSQL server remotely using odbc under wine?? > > __________________________________________________ > > Todavía no tenés tu Ciudad Internet Mail? Obtenelo ahora! - > http://webmail.ciudad.com.ar > > Descargá Gratis el nuevo Internet Explorer 6.0, el mejor software para > actualizar tu PC. http://www.ciudad.com.ar/ar/servicios/ie/ >>Did you set >>"odbc32" = "native" >>in the config file ? >>Bye Stefan yes, i tried both ways (native, builtin) without success!

1 0

Acknowledgement page
by Brian Vincent 04 Sep '04

04 Sep '04

I've put together a preview of a Wine acknowledgement page; you can find it here: http://www.theshell.com/~vinn/ack-preview.html Any thoughts / comments / concerns / criticisms? Notes: - This is based only off of the Changelog. The old changelog was referenced for the years listed, however if someone made a major contribution in 1997 you won't find them here. - Criteria used was, for the most part, objective. If you submitted 8 patches or more, you probably made this list. (If you didn't then it means I screwed up and you should tell me.) - After getting into it, I realized a bit late that I should have cut it off at about 12 patches.. that would have made this list about 100 names. - The area someone contributed to was just what I noticed scanning over the Changelog. I'm sure that someone probably had a major contribution to some area not listed here, so you should let me know if it needs correction. - Send me changes on or off list. I'll incorporate them and put together a real patch for Newman to integrate. Anything missing or wrong on this list is just a mistake on my part and not part of any sinister plot to undermine someone's work. Send me changes. -Brian

1 0

Darwine Display Driver
by Nikolas Dahn 04 Sep '04

04 Sep '04

Hi there everybody! First of all i have to admit that im quiet useless in coding, im just a user with _minimal_ programing knowledge, so this might sound like trash which we all should forget as soon as we can ;) When reading the article about porting wine to mac os and the related difficulties it came into my mind to create a borderless x window (best of all just the content) and have carbon/cocoa create an empty window with borders where the x-content is linked and centered to (similar to an bordered control-layer i think). I dont know how to do this or whether it is even possible, but for me it sounds some kind of logical... oO if this isnt the fact, just ignore me :) Cheers Nikolas Dahn -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

1 0

Re: ADVAPI32: preserve the last error value set by the CSP in CryptAcquireContext
by Robert Shearman 04 Sep '04

04 Sep '04

Mike McCormack wrote: > > ChangeLog: > * preserve the last error value set by the CSP in CryptAcquireContext > >------------------------------------------------------------------------ > >Index: dlls/advapi32/crypt.c >=================================================================== >RCS file: /home/wine/wine/dlls/advapi32/crypt.c,v >retrieving revision 1.51 >diff -u -r1.51 crypt.c >--- dlls/advapi32/crypt.c 30 Aug 2004 23:57:18 -0000 1.51 >+++ dlls/advapi32/crypt.c 4 Sep 2004 01:09:44 -0000 >@@ -476,6 +476,8 @@ > } > /* FALLTHROUGH TO ERROR IF FALSE - CSP internal error! */ > error: >+ /* must preserve the last error returned by the CSP here */ >+ r = GetLastError(); > if (pProv) > { > FreeLibrary(pProv->hModule); >@@ -486,6 +488,7 @@ > CRYPT_Free(provname); > CRYPT_Free(temp); > CRYPT_Free(imagepath); >+ SetLastError( r ); > return FALSE; > } > > This seems wrong. Which function is calling SetLastError? I believe there was a problem a while ago with freeing bad pointers. I can't remember whether a fix went in for that. Rob

2 1

WinInet and doubtful assertion in FTP_Connect
by Krzysztof Foltman 04 Sep '04

04 Sep '04

For some reason, FTP connections in WININET crash on assertion: assert( hIC->hdr.htype != WH_HINIT ); However, it seems the assertion is either wrong, or confusing (if its intention was to point out that FTP code is unimplemented). FTP_Connect is called from two places, InternetConnectW and InternetOpenUrlW. As for InternetConnectW, it won't call FTP_Connect unless htype is set to WH_HINIT. As for InternetOpenUrlW, I'm not sure what htype does it expect. However, it's supposed to use HINTERNET handles coming out of InternetOpen, which sets htype to WH_HINIT. After changing != to ==, InternetConnect works (to a degree). Don't know about InternetOpenUrl, but theoretically it should too. Chris

1 0

(no subject)
by Pablo Szuster 04 Sep '04

04 Sep '04

Hi, i´m trying to access a MSSQL server (in a windows machine in the network) from a Visual Basic Application running under wine, using an ODBC driver. Since there aren´t any MSSQL drivers for linux i decided to use de native ones, so i installed mdac_typ.exe . Then i configured the DSN using odbcad32.exe but when i tested the connection (configured using tcp/ip) an error message appeared ("[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets] General network error. Check your network documentation"). Do i have to install some network drivers for wine?? Has anyone been able to connect to a MSSQL server remotely using odbc under wine?? __________________________________________________ Todavía no tenés tu Ciudad Internet Mail? Obtenelo ahora! - http://webmail.ciudad.com.ar Descargá Gratis el nuevo Internet Explorer 6.0, el mejor software para actualizar tu PC. http://www.ciudad.com.ar/ar/servicios/ie/

2 1

Re: Wine and industrial communication like OPC
by Juan Lang 04 Sep '04

04 Sep '04

Mike (at yet another email address) wrote: > Wines sockets support is good though, far better > than its builtin DCOM. Based on what I know of the > DCOM network protocol, I don't think we'd have any > problems with it. I can think of a couple, but they may be able to be worked around: - incoming connections (DCOM servers) won't be supported. If this guy's clients are going with WinCE that won't be an issue, it doesn't support them either AFAIK. - only DCOM over TCP is likely to be supported. DCOM over named pipes definitely wouldn't be. --Juan _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush

5 7

Re: Wine Emulation: Swapping functions
by Alexandre Julliard 04 Sep '04

04 Sep '04

"Pierre d'Herbemont" <stegefin(a)free.fr> writes: > Hi Alexandre, > > This patch allows to load a PE exe to memory. You may notice that > there is no "mass" byte swapping. The technics used here is a bit > developer here: > http://stegefin.free.fr/wine/ > You might prefer a more conventional way of doing the byte swapping, > in this case tell me. We might still need this approach since it could > efficient for sharing data accross the LE exe and the BE winelib. It doesn't seem very efficient to trap on every memory access... Besides, I don't see how this can possibly work, there is no guarantee that the compiler is going to generate accesses that always match the size of the requested type, memcpy() being the obvious example. I think you are going in the wrong direction with this; the right way IMO is to compile Wine for x86 and run the whole Wine+app under the CPU emulator. Otherwise you'll have to write wrappers for each of the 15,000 APIs. -- Alexandre Julliard julliard(a)winehq.org

7 21

problem in using Winelib
by gupta.lokesh＠philips.com 03 Sep '04

03 Sep '04

Hi, I have been trying to use Winelib to build a very trivial Windows Application on Unix just to test the working of winelib. But it does not work according to the documentation at all. Here are the problems I found: - When I run winemaker in my project root directory, it runs successfully but in the end does not produce any configure script as said in the documentation but produces directly a Makefile - The Makefile must be manually tweaked to put in the WINE include files path and the WINE libraries path. - After changing the generated Makefile, when I run it, I see thousands of warnings related to ignoring of __stdcall__ attribute in some of the windows header files, but the build goes through - The generated executable always has a .so extension which gives a feeling that it is a shared library rather than an executable - When I run the above generated file, it simply dumps core without any messages "Segmentation Fault" - When I try to run the above application through GDB to debug it, it crashes even before reaching main - When I try to run the above application through winedbg to debug it, it simply hangs, nothing happens after that. If such a basic thing does not work with Winelib, then I hope that something is wrong with the way I have understood things and in my process of trying to do this. Can somebody help ?? By the way, the same kind of setup also did not work on Linux/Intel and Linux/Athlon combinations as well. So there must be something very wrong in the way I am doing it. I imagine that the Winelib user's guide documentation is totally out of date, in which case could somebody please forward me a document which can produce working executables. Best Regards Lokesh

2 1

Re: listview
by Rein Klazes 03 Sep '04

03 Sep '04

On Thu, 2 Sep 2004 17:28:31 -0400, you wrote: > ChangeLog: > Ulrich Czekalla <ulrich(a)codeweavers.com> > Handle WM_BUTTONDOWN operations before dragging test > Don't eat WM_LBUTTONUP message > > Index: dlls/comctl32/listview.c > =================================================================== > RCS file: /home/wine/wine/dlls/comctl32/listview.c,v > retrieving revision 1.393 > diff -u -r1.393 listview.c > --- dlls/comctl32/listview.c 25 Aug 2004 17:33:01 -0000 1.393 > +++ dlls/comctl32/listview.c 2 Sep 2004 21:21:32 -0000 > @@ -7927,6 +7927,7 @@ > else if (msg.message >= WM_LBUTTONDOWN && > msg.message <= WM_RBUTTONDBLCLK) > { > + DispatchMessageW(&msg); > break; > } This was discussed before. The problem here is that Windows/native comctl32 *does* eat the WM_LBUTTONUP message ending the mouse track. The reason why you miss the WM_LBUTTONUP message is that mouse tracking is started wrongly under Wine. Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 1

RE: Protected message
by Mike 03 Sep '04

03 Sep '04

1 0

OLE Problem?
by Adriano Bonat 03 Sep '04

03 Sep '04

Hello, im trying to run a program, but appear this error message: Invoking /usr/lib/wine/wine.bin SVLGER.EXE ... fixme:ole:CoRegisterMessageFilter stub fixme:ole:GetRecordInfoFromGuids (0x40b8e0,2,12,0,0x40b8f0,0x4465e8),stub! fixme:ole:CoRegisterMessageFilter stub Wine exited with a successful status Im using Debian, and configured Wine with Winetools, the software that im trying to run is a ERP build with VB in Windows NT. Any appointment of the patch for this problem? Thanks in advance, -Adriano Bonat

1 0

cleanup w->a cross calls in crypt
by James Hawkins 03 Sep '04

03 Sep '04

Hi, I have checked this patch over and over, but I would appreciate it if you guys could make sure it is ready to be committed. I tried to break up the changes into as many patches as I could, but these last few functions depend on CRYPT_GetProvKeyName and CRYPT_GetTypeKeyName which had to be unicodified as well. The tests for these functions will be sent in the next patch. -- James Hawkins

2 5

Possible fun project/todo list item?
by Juan Lang 02 Sep '04

02 Sep '04

Another approach would be to rework wininet to use SSPI (implemented in secur32.dll), and to write an SSP for SSL and TLS. You could write one that uses NSS if you like, or another that uses OpenSSL or GnuTLS. Not sure how "fun" that would be though <g>. --Juan __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

1 0

more debugger issues
by Chipzz 02 Sep '04

02 Sep '04

Hi all! As a saw a few updates to the debugger a couple of days ago, I decided to give the debugger another go. The problem with the stack trace is gone now, but now I get another problem when I attach to a running process, set a breakpoint and continue, the program crashes. When I in- stead don't set a breakpoint and continue, the program keeps running "fine": When setting the breakpoint: chipzz@Vector:~/.wine-clean/win/dotnet.inst$ winedbg fixme:console:SetConsoleCtrlHandler (0x4059e880,1) - no error checking or testing yet Wine-dbg>info process pid threads parent executable (all id:s are in hex) 00000008 4 00000000 'H:\.wine-clean\win\dotnet.inst\install.exe' Wine-dbg>attach 8 fixme:dbghelp:addr_to_linear Failed to linearize address 8000:00000000 (mode 0) In 32 bit mode. Wine-dbg>bt Backtrace: =>1 0x40107b4b __read+0x4b in libc.so.6 (0x40307c54) 2 0x401cc472 NTDLL_wait_for_multiple_objects+0x122 in ntdll (0x40307cf8) 3 0x401ca9dc vm86_return_end+0xc55 in ntdll (0x40307d1c) 4 0x40067678 (0x423bcc4c) 5 0x401cc472 NTDLL_wait_for_multiple_objects+0x122 in ntdll (0x423bccf0) 6 0x401cc4e6 NtWaitForMultipleObjects+0x66 in ntdll (0x423bcd18) 7 0x404e25a5 WaitForMultipleObjectsEx+0xb5 in kernel32 (0x423bce48) 8 0x40cd54cc X11DRV_MsgWaitForMultipleObjectsEx+0x5c in x11drv (0x423bcf80) 9 0x408d9294 MsgWaitForMultipleObjectsEx+0x134 in user32 (0x423bd128) 10 0x408d9351 MsgWaitForMultipleObjects+0x41 in user32 (0x423bd148) 11 0x4163b91a (0x40915980) 12 0x7d8920ec (0x83e58955) fixme:dbghelp:addr_to_linear Failed to linearize address 8000:00000000 (mode 0) 13 0x8000:0x0000 (0x11b7:0x0800) 14 0x8000:0x0800 (0x11b7:0x0000) Wine-dbg>break MessageBoxA err:dbghelp:pe_load_dbg_file -Unable to peruse .DBG file ole32.dbg ("H:\\.wine-clean\\win\\dotnet.inst") err:dbghelp:pe_load_dbg_file -Unable to peruse .DBG file oleaut32.dbg ("H:\\.wine-clean\\win\\dotnet.inst") err:dbghelp:pe_load_dbg_file -Unable to peruse .DBG file rpcrt4.dbg ("H:\\.wine-clean\\win\\dotnet.inst") err:dbghelp_msc:codeview_process_info Unknown CODEVIEW signature 53445352 in module msvcr80 fixme:dbghelp:symt_get_info Unsupported sym-tag SymTagPublicSymbol for get-type Many symbols with name 'MessageBoxA', choose the one you want (<cr> to abort): [1]: 0x408db030 MessageBoxA in user32 [2]: 0x40ad7760 MessageBoxA in shell32 [3]: 0x40107b00 __libc_read in libc.so.6 => 1 Breakpoint 1 at 0x408db030 MessageBoxA in user32 Wine-dbg>c First chance exception: page fault on read access to 0x00000040 in 32-bit code (0x4281009e). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:11af GS:0000 EIP:4281009e ESP:423be038 EBP:423be0a4 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:00000000 ECX:77710800 EDX:00000000 ESI:00000000 EDI:000000a0 Stack dump: 0x423be038: 79655066 796fc52b 00000000 000000a0 0x423be048: 00000000 00000000 40340000 00000002 0x423be058: 00000034 404bec3f 00000007 423be084 0x423be068: 70a948ad 00000409 00000001 403b62f8 0x423be078: ffffffff 79670df4 ffffffff 423be0b8 0x423be088: 70a95755 00000001 354ae8a4 423be044 0235: sel=11af base=40306000 limit=00001fff 32-bit rw- Backtrace: =>1 0x4281009e (0x423be0a4) 2 0x796fc558 (0x423be0dc) 3 0x796fc705 (0x423be12c) 4 0x796fd494 (0x423be1d0) 5 0x00750073 (0x00690056) 6 0x00000000 (0x00000000) 0x4281009e: movl 0x40(%eax),%eax Wine-dbg>c First chance exception: page fault on read access to 0x00000040 in 32-bit code (0x4281009e). ... etc. When not setting the breakpoint: chipzz@Vector:~/.wine-clean/win/dotnet.inst$ winedbg fixme:console:SetConsoleCtrlHandler (0x4059e880,1) - no error checking or testing yet Wine-dbg>attach 8 fixme:dbghelp:addr_to_linear Failed to linearize address 8000:00000000 (mode 0) In 32 bit mode. Wine-dbg>c Also, ctrl-c doesn't work to stop the program being debugged. Wien version is wine CVS Aug 23. Any help is appreciated! kr, Chipzz AKA Jan Van Buggenhout PS: Please cc me as I'm not on the list. -- ------------------------------------------------------------------------ UNIX isn't dead - It just smells funny Chipzz(a)ULYSSIS.Org ------------------------------------------------------------------------ "Baldric, you wouldn't recognize a subtle plan if it painted itself pur- ple and danced naked on a harpsicord singing 'subtle plans are here a- gain'."

2 3

WineHQ - Hosted by PayPal
by Tero Tamminen 02 Sep '04

02 Sep '04

Hi! Sorry if this is wrong list or something, but I saw this bug (if this is feature, not a bug, ignore this mail) in front page of WineHQ. Also with quick search with Google I didn't find this reported before. On the right side, there is "Hosted by" and empty link to codeweavers (<a href="http://www.codeweavers.com/"></a>). After that there is PayPal link. Because <a href="http://www.codeweavers.com/"></a> is empty, it seems that this site is hosted by PayPal (which should come after codeweavers, I think). This could be said more clearly I think, but if you go to the front page, you'll notice it. Anyway, have a nice day and so on... -- Tero Tamminen

5 5

Re: wine/ windows/painting.c dlls/user/painting.c
by Rein Klazes 02 Sep '04

02 Sep '04

On Wed, 25 Aug 2004 19:46:11 -0500, you wrote: > Log message: > GetUpdateRgn should clip the returned region to the client area. > Changed GetUpdateRect and ExcludeUpdateRgn to call GetUpdateRgn. > Moved these 3 functions to dlls/user/painting.c. This has the effect that a program that like agent does this: case WM_PAINT: if( GetUpdateRect(hWnd, ...) { hdc = BeginPaint(hWnd,...); } causes a lot of: err:msg:DispatchMessageA BeginPaint not called on WM_PAINT for hwnd 0x1002c! Is it not possible to restrict the update region to the client area in the first place? Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 4

make crosstest link error
by Francois Gouget 02 Sep '04

02 Sep '04

Running make crosstest in dlls/mlang/tests I get: i586-mingw32msvc-gcc mlang.cross.o testlist.cross.o -o mlang_crosstest.exe -lole32 -lgdi32 -lkernel32 -lntdll -luuid mlang.cross.o(.text+0x469e): In function `func_mlang': /home/fgouget/wine/dlls/mlang/tests/mlang.c:618: undefined reference to `IID_IMultiLanguage2' mlang.cross.o(.text+0x46b5):/home/fgouget/wine/dlls/mlang/tests/mlang.c:618: undefined reference to `CLSID_CMultiLanguage' make: *** [mlang_crosstest.exe] Error 1 I have checked out the mingw-w32api-2.5-8hl.i586.rpm package from http://mirzam.it.vu.nl/mingw/ but unfortunately I still get the error. >From what I can see, these GUIDs should be defined in libole32.a. So I guess the mingw-w32api package is in for an update... -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.

2 2

Hidden message
by Mike 02 Sep '04

02 Sep '04

1 0

Re: stub AtlModuleUpdateRegistryFromResourceD [resend]
by Alexandre Julliard 01 Sep '04

01 Sep '04

Stefan Leichter <Stefan.Leichter(a)camLine.com> writes: > +/*********************************************************************** > + * AtlUpdateRegistryFromResourceD [ATL71.@] (.NET) > + * > + */ > +HRESULT WINAPI AtlUpdateRegistryFromResourceD(HINSTANCE hInst, LPCOLESTR lpszRes, > + BOOL bRegister, /* struct _ATL_REGMAP_ENTRY* */ void* pMapEntries, /* IRegistrar* */ void* pReg) This is confusing, because AtlUpdateRegistryFromResourceD is not exported from atl.dll. You should either avoid that function completely, or create a new atl71.dll that exports it (but that doesn't seem really necessary at this point). -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Binary relocatability part 1
by Alexandre Julliard 01 Sep '04

01 Sep '04

Mike Hearn <mike(a)navi.cx> writes: > +dnl This is used for binary relocatability > +if echo $libdir | grep '^\${exec_prefix}' >/dev/null; then > + RPATH="-Wl,-rpath,'\$\${ORIGIN}/..'`echo $libdir | sed 's/\${exec_prefix}//'`" > +fi This is still making assumptions about the contents of bindir and libdir. What you need is a generic way to find a relative path from any directory to any other. Also this needs to be done at make time, not in configure. -- Alexandre Julliard julliard(a)winehq.org

2 3

Wine and industrial communication like OPC
by Rickard Svensson 01 Sep '04

01 Sep '04

Hello! I have some questions about Wine and how/if it can be used with industrial communication like OPC (MicroSoft Com/DCom objects, DDE and more) My short question is: Can I use Wine to make OPC communication work on a Linux system. OPC "OLE for Process Control" A "general" standard for communication in industrial systems, that unfortunately is totally depending on Windows(DCOM) I work on a small company in Sweden who make industrial computers for the industry, and when we a few years ago had to choose operating system for our new model I got them to choose Linux. And almost everything is perfect, we have had a working product for almost a year now, and everything is good. But now our company needs to support OPC, this is a big problem that makes a lot of people in the company start saying things like WinCE or Win XP embedded. On www.opcfoundation.org ther are same companys how have made Unix OPC clients, but the license costs are hi. Ther is also OPC true XML that is now a real product, that looks promising. I'am in need to make/use same kind of OPC api(Wine DCom) for Linux, a api like that woode make many companys in the industrial computer intressted. Or as a backup I could have a Win program running in Wine on the Linux machine talking with the main app on the same computer and talking OPC to other machines that need that. I hope Wine and/or you can help me in this case. It would be a tragedy if we had to switch operating system just because of this. /Rickard -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm

3 3

Re: Add a test showing that GDI should not scale bitmap font metrics
by Huw D M Davies 01 Sep '04

01 Sep '04

On Wed, Sep 01, 2004 at 05:44:19PM +0900, Dmitry Timoshkov wrote: > Hello, > > I had a wild guess whether GDI actually scales or not metrics for > a bitmap font if a requested font size is not available and wrote > a test case for it. No, GDI *does not* scale bitmap font metrics. Well it does do integer scaling. So if you request System (whose normal size is 16) with 32 <= lfHeight < 48 you'll get a double sized font with all the metrics scaled by a factor of two. Wine doesn't do this yet. Your test shows that gdi doesn't do fractional scaling which is indeed correct. Huw. -- Huw Davies huw(a)codeweavers.com

2 3

Re: mixing SHELL32.DLL and SHFOLDER.DLL
by Juan Lang 01 Sep '04

01 Sep '04

Salius wrote: > I am sure shfolder.dll from win98se installation > calls GetProcAddress() to get the address of > SHGetFolderPathW @ shell32.dll. Moreover, my > shell32.dll doesn't export SHGetSpecialFolderPath* > by a name, also. Hm. I'm sorry, I wasn't clear enough. From MSDN on SHGetFolderPath: This function is a superset of SHGetSpecialFolderPath, included with earlier versions of the Shell. On systems preceeding those including Shell32.dll version 5.0 (Windows Millennium Edition (Windows Me) and Windows 2000), SHGetFolderPath was obtained through SHFolder.dll, distributed with Microsoft Internet Explorer 4.0 and later versions. SHFolder.dll always calls the current platform's version of this function. If that fails, it will try to simulate the appropriate behavior. So, I think your patch is a good first step, to use GetProcAddress rather than letting the linker do it. A next step would be, I think, to do what I suggested: if this fails, try to GetProcAddress for SHGetSpecialFolderPath, since this was available on older versions of shell32. You might have to search by ordinal if searching by name fails. So, I don't think my suggestion is that different from Juergen's, just that I suggest an implementation of "try to simulate the appropriate behavior" if the function is not in fact in shell32. --Juan _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush

3 3

E-mail adress
by Davide Giannotti 31 Aug '04

31 Aug '04

I'm trying to fight spam like anybody else, and first thing is to remove mail adresses from every page on the internet. A google search on my adress shows only 2 pages where i compare, they both come frome wine archive: http://www.winehq.com/hypermail/wine-devel/2003.04.txt http://www.spinics.net/lists/wine/msg08863.html Is there a way to make them remove from there? Just a suggestion: i'm conscious that mail adress need to be post into such a mailing list, but wouldn't be good to keep a script running that alter them into something like 'myname {at} mydomain' ? Just a little sacrifice for everybody to help fighting spam. Think about.. pls... -- Davide Giannotti ITS Planet s.n.c davide.giannotti {at} itsplanet.com www.itsplanet.com

3 2

Re: Set last error values compatible with Win9x implementation of GetFileVersionInfoSize
by Uwe Bonnes 31 Aug '04

31 Aug '04

>>>>> "Dmitry" == Dmitry Timoshkov <dmitry(a)baikal.ru> writes: Dmitry> Hello, installer of Quicken depends on last error values set by Dmitry> GetFileVersionInfoSize and expects them to be set to something Dmitry> different than ERROR_RESOURCE_DATA_NOT_FOUND set on NT Dmitry> platforms. Dmitry> I hope that there is no need to introduce several code paths Dmitry> depending on the GetVersion return value. A test programm for our test suite will easily show (and document) that behaviour. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Re: KERNEL32: implement CallNamedPipe
by Dmitry Timoshkov 31 Aug '04

31 Aug '04

"Mike McCormack" <mike(a)codeweavers.com> wrote: > + r = WaitNamedPipeW( lpNamedPipeName, nTimeout ); > + if( !r ) > + return r; win2k kernel32 does not do WaitNamedPipeW. > + handle = CreateFileW( lpNamedPipeName, GENERIC_READ|GENERIC_WRITE, > + 0, NULL, OPEN_EXISTING, 0, NULL ); > + if( !handle ) > + return FALSE; CreateFileW returns INVALID_HANDLE_VALUE on failure, not 0. > + r = WriteFile( handle, lpOutput, dwOutputSize, &count, NULL ); > + if( r ) > + r = ReadFile( handle, lpInput, dwInputSize, lpBytesRead, NULL ); win2k kernel32 calls SetNamedPipeHandleState and TransactNamedPipe (not implemented in Wine) here. > + CloseHandle( handle ); > + > + return r; > } -- Dmitry.

1 0

Re: Add some padding in WINPROC_wrapper
by Mike McCormack 31 Aug '04

31 Aug '04

Uwe Bonnes wrote: > Changelog > windows/winproc.c: WINPROC_wrapper > Add some padding between saved registers and the winproc > arguments. Some winprocs may trash the register area. > > As Mike Hearn suggested, adding some padding helped with my problem with > WebPACK_42wp30_full_installer.exe. I hope, I found the right way to add that > padding. It may work for one application, but it doesn't look like a propper fix. I'd suggest there's probably something else going on that's causing stack corruption. Mike

3 7

Re: wineserver epoll
by Alexandre Julliard 31 Aug '04

31 Aug '04

Shachar Shemesh <wine-patches(a)shemesh.biz> writes: > After much talk, the patch seems ready for commit. Since there are many > systems with slightly older glibc that have the header but do not have > the implementation in glibc, or that have a stub implementation that is > guaranteed to fail, we are calling the kernel functions directly. This > also allows compiling on older systems than the code actually ships to. > > Accordingly, the autoconf checks for epoll_create in glibc were dropped. That's wrong; if the libc function exists you should use it, direct system calls should only be used as a fallback. And when using system calls you must not depend on the libc header, you have to define the structures yourself. -- Alexandre Julliard julliard(a)winehq.org

5 7

Debug Channels trashed
by Uwe Bonnes 31 Aug '04

31 Aug '04

Hallo, I am trying to run the WebPACK_42wp30_full_installer.exe : http://direct.xilinx.com/direct/webpack/42wp3/\ : WebPACK_42wp30_full_installer.exe (a 110 MByte Download). Running it crashes quite early, while testing the debug channels: err:font:ReadFontDir Can't open directory "/usr/X11R6/lib/X11/fonts/TrueType" err:font:ReadFontDir Can't open directory "/usr/X11R6/lib/X11/fonts/TT" wine: Unhandled exception (thread 0009), starting debugger... fixme:console:SetConsoleCtrlHandler (0x405ac2f0,1) - no error checking or testing yet WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0xc0685566 in 32-bit code (0x40710c60). In 32 bit mode. 0x40710c60 WINPROC_CallWndProc [/home/wine/wine/dlls/user/../../windows/winproc.c:232] in user32: testb $0x8,0x0(%eax) 232 if (TRACE_ON(relay)) 232 if (TRACE_ON(relay)) Wine-dbg>Backtrace: =>1 0x40710c60 WINPROC_CallWndProc+0x70(wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/winproc.c:232] in user32 (0x4067fb7c) 2 0x4071578d CallWindowProcA+0xed(func=0x4078656c, hwnd=0x10022, msg=0x110, wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/winproc.c:3123] in user32 (0x4067fba0) 3 0x406eb083 DefDlgProcA+0x63(hwnd=0x10022, msg=0x110, wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/defdlg.c:451] in user32 (0x4067fbd0) 4 0x40710437 WINPROC_wrapper+0x17 in user32 (0x4067fbf4) 5 0x40710c4c WINPROC_CallWndProc+0x5c(wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/winproc.c:230] in user32 (0x4067fc30) 6 0x4071578d CallWindowProcA+0xed(func=0x406eb020, hwnd=0x10022, msg=0x110, wParam=0x1002c, lParam=0x0) [/home/wine/wine/dlls/user/../../windows/winproc.c:3123] in user32 (0x4067fc54) 7 0x40725b8f call_window_proc+0x11f(lparam=0x0, unicode=0x0, same_thread=0x1) [/home/wine/wine/dlls/user/message.c:1461] in user32 (0x4067fcb8) 8 0x4072839e SendMessageTimeoutA+0x1be(hwnd=0x10022, msg=0x110, wparam=0x1002c, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x4067fd3c) [/home/wine/wine/dlls/user/message.c:1968] in user32 (0x4067fd18) 9 0x40728425 SendMessageA+0x35(hwnd=0x10022, msg=0x110, wparam=0x1002c, lparam=0x0) [/home/wine/wine/dlls/user/message.c:2012] in user32 (0x4067fd44) 10 0x406efc5c DIALOG_CreateIndirect+0x107c(dlgProc=0x4012df, param=0x0, unicode=0x0, modal=0x1) [/home/wine/wine/dlls/user/../../windows/dialog.c:672] in user32 (0x4067fe54) 11 0x406f04be DialogBoxParamA+0x4e(hInst=0x400000, name=0x12c, owner=0x0, dlgProc=0x4012df, param=0x0) [/home/wine/wine/dlls/user/../../windows/dialog.c:821] in user32 (0x4067fe78) 12 0x0040184d (0x004137a2) It seems the location of the debug channels is picked up from the ebx register Wine-dbg>disass 0x40710c52 0x40710c52 WINPROC_CallWndProc [../windows/winproc.c:231] in user32: call 0x40707c70 WIN_RestoreWndsLock [/home/wine/wine/dlls/user/../../windows/user.c:183] in user32 0x40710c57 WINPROC_CallWndProc [../windows/winproc.c:232] in user32: movl 0x190(%ebx),%eax 0x40710c5d WINPROC_CallWndProc [../windows/winproc.c:232] in user32: addl $24,%esp 0x40710c60 WINPROC_CallWndProc [../windows/winproc.c:232] in user32: testb $0x8,0x0(%eax) I wonder what can trash the testing of the debug channels. I ran with +heap to look for heap corruption, but couldn't find something. Uncommenting the offending code > if (TRACE_ON(relay)) > DPRINTF( "%04lx:Ret window proc %p (hwnd=%p,msg=%s,wp=%08x,lp=%08lx) retval=%08lx\n", > GetCurrentThreadId(), proc, hwnd, SPY_GetMsgName(msg, hwnd), wParam, lParam, retvalue ); makes the application proceed. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

4 5

Linux registry
by Robert van Herk 31 Aug '04

31 Aug '04

Not knowing how much off topic this would be, I just thought I paste a link here: http://registry.sourceforge.net/ These people seem to be implementing a kinda Windows registry clone into Linux, but then secure, stable 'n' stuff... Since the many registry implementation discussions here, I thought, why not throw this into the discussion too? It might be worth to take a look here and perhaps think about using some of their stuff. Greetings, Robert van Herk

3 2

Re: SHAllocShared fixes
by Alexandre Julliard 30 Aug '04

30 Aug '04

Francois Gouget <fgouget(a)free.fr> writes: > This actually calls for two more notes: > * This looks very much what one would get by calling the corresponding > functions in shlwapi (which seems much more complete). However in > shell32 there is talk of sending messages around (WM_USER+2) so maybe > it's the same concept but a different implementation? The WM_USER+2 thing is something a specific caller was doing, it's not part of the function itself. I think the shell32 functions should simply forward to the shlwapi ones. -- Alexandre Julliard julliard(a)winehq.org

1 0

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

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 key handles... -- Alexandre Julliard julliard(a)winehq.org

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

RE: RICHEDIT: use buffers rather than linked lists for input and out buffers
by Ge van Geldorp 27 Aug '04

27 Aug '04

> From: Mike McCormack > > This patch writes the output of the RTF parser into the edit > control in > 1024 byte chunks, and reads the input via a char[1024] buffer, rather > than a linked list of single characters. Not that it should matter very much, but the MS control always seems to read the input in 4096 byte chunks. Maybe you could enlarge InputBuffer from 0x400 to 0x1000? Ge van Geldorp.

1 0

Remote operations -- need for advice
by Alexander Yaworsky 27 Aug '04

27 Aug '04

I'm thinking how to implement CreateRemoteThread and besides fix memory management functions. The complete (afaik) list includes: RtlCreateUserThread NtAllocateVirtualMemory NtFreeVirtualMemory NtProtectVirtualMemory NtQueryVirtualMemory NtLockVirtualMemory (do nothing?) NtUnlockVirtualMemory (do nothing?) NtFlushVirtualMemory NtMapViewOfSection NtUnmapViewOfSection Suggested implementation. Let's add two groups of handlers to the wineserver, something like remote_operation_xxxx and remote_operation_xxxx_complete. remote_operation should do the following: 1) suspend_for_ptrace(); 2) inject a piece of code into required process and start its execution; 3) resume_after_ptrace(); 4) place calling thread into suspended state (or into some wait state?) remote_operation_complete should prepare reply and resume thread suspended by remote_operation. Injected code should call required function and then remote_operation_complete in context of required process. The question is: how to correctly get address of function? imho possible solutions are: 1) assume ntdll loaded at the same address for all processes -- unreliable; 2) get dll base address from per-process dll list and parse ELF by hand -- too complicated (?); 3) pass relative offsets and add them later to the ntdll's base address -- unreliable a bit: ntdll may be replaced, although, it is unlikely; 4) extend the struct process (server/process.h) and the request init_process with pointers to required functions -- most reliable and simple but looks ugly. What do you think?

6 11

Localizing shell32/shv_item_cmenu.c:ISvItemCm_fnQueryContextMenu
by Tobias Burnus 27 Aug '04

27 Aug '04

Hello, if I right click in the file open dialog, select a file and right click, I get a context menu with English menu items. Expected: I'll get a localized menu (e.g. in German). Any idea how to get a localized version? From dlls/shell32/shv_item_cmenu.c ------------------------------------ * ISvItemCm_fnQueryContextMenu() */ static HRESULT WINAPI ISvItemCm_fnQueryContextMenu( [...] _InsertMenuItem(hmenu, indexMenu++, TRUE, FCIDM_SHVIEW_OPEN, MFT_STRING, "&Open", MFS_ENABLED); _InsertMenuItem(hmenu, indexMenu++, TRUE, FCIDM_SHVIEW_EXPLORE, MFT_STRING, "&Explore", MFS_ENABLED|MFS_DEFAULT); } [...] ------------------------------------ Tobias PS: the _InsertMenuItem function, defined in the same file, uses InsertMenuItemA, one might want to change this to InsertMenuItemW.

2 1

Re: RESEND 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: > This is a resend of this patch...it's been through a couple times. If > there is anything keeping the patch from being committed, please let > me know. Thanks. One problem I see is that you never close the key handles that you open. -- Alexandre Julliard julliard(a)winehq.org

1 0

Something broke winetest?
by Paul Millar 26 Aug '04

26 Aug '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Looks like something broke building cross-compiled tests last night. I now get: [paulm@quisquiliae tests]$ make i686-mingw32msvc-gcc dpa.o imagelist.o subclass.o tab.o testlist.o -o comctl32_test.exe -lcomctl32 -luser32 -lgdi32 imagelist.o(.text+0x1077): In function `DoTest3': /home/paulm/Testing/wine-cross-source/dlls/comctl32/tests/imagelist.c:265: undefined reference to `ImageList_DrawIndirect@4' imagelist.o(.text+0x10b7):/home/paulm/Testing/wine-cross-source/dlls/comctl32/tests/imagelist.c:267: undefined reference to `ImageList_DrawIndirect@4' imagelist.o(.text+0x10f6):/home/paulm/Testing/wine-cross-source/dlls/comctl32/tests/imagelist.c:269: undefined reference to `ImageList_DrawIndirect@4' imagelist.o(.text+0x1132):/home/paulm/Testing/wine-cross-source/dlls/comctl32/tests/imagelist.c:271: undefined reference to `ImageList_DrawIndirect@4' imagelist.o(.text+0x1186):/home/paulm/Testing/wine-cross-source/dlls/comctl32/tests/imagelist.c:277: undefined reference to `ImageList_DrawIndirect@4' imagelist.o(.text+0x11ba):/home/paulm/Testing/wine-cross-source/dlls/comctl32/tests/imagelist.c:279: more undefined references to `ImageList_DrawIndirect@4' follow distcc[21076] ERROR: compile on localhost failed make: *** [comctl32_test.exe] Error 1 [paulm@quisquiliae tests]$ Which causes comctl32_test.exe not to be built, so the build of winetest.exe fails. Do others get this too? Cheers, Paul. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBLIJM/9JwS78PA+kRAjN+AKCUTBxmUZlJQnPvUKZWuM2n8rGBVgCaA7Wz qE5hC6AGHcijndK6umrZygQ= =vivD -----END PGP SIGNATURE-----

3 3

Non-perfect epoll patch
by Shachar Shemesh 26 Aug '04

26 Aug '04

Hi all, Attached is a non-perfect patch for review. This is a migration of the wineserver to use epoll instead of poll (if it's available). current known issue with this patch: 1. Will not compile if HAVE_SYS_EPOLL_H is not 1 (i.e. - won't compile if epoll not available at compile time) 2. Segfaults on wine exit. 3. Lots of debug asserts. Comments welcome. 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.573 diff -u -r1.573 configure --- configure 17 Jul 2004 00:52:37 -0000 1.573 +++ configure 24 Aug 2004 12:03:32 -0000 @@ -6727,6 +6727,79 @@ fi +echo "$as_me:$LINENO: checking for epoll_create in -lepoll" >&5 +echo $ECHO_N "checking for epoll_create in -lepoll... $ECHO_C" >&6 +if test "${ac_cv_lib_epoll_epoll_create+set}" = set; then + echo $ECHO_N "(cached) $ECHO_C" >&6 +else + ac_check_lib_save_LIBS=$LIBS +LIBS="-lepoll $LIBS" +cat >conftest.$ac_ext <<_ACEOF +/* confdefs.h. */ +_ACEOF +cat confdefs.h >>conftest.$ac_ext +cat >>conftest.$ac_ext <<_ACEOF +/* end confdefs.h. */ + +/* Override any gcc2 internal prototype to avoid an error. */ +#ifdef __cplusplus +extern "C" +#endif +/* We use char because int might match the return type of a gcc2 + builtin and then its argument prototype would still apply. */ +char epoll_create (); +int +main () +{ +epoll_create (); + ; + return 0; +} +_ACEOF +rm -f conftest.$ac_objext conftest$ac_exeext +if { (eval echo "$as_me:$LINENO: \"$ac_link\"") >&5 + (eval $ac_link) 2>conftest.er1 + ac_status=$? + grep -v '^ *+' conftest.er1 >conftest.err + rm -f conftest.er1 + cat conftest.err >&5 + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); } && + { ac_try='test -z "$ac_c_werror_flag" || test ! -s conftest.err' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; } && + { ac_try='test -s conftest$ac_exeext' + { (eval echo "$as_me:$LINENO: \"$ac_try\"") >&5 + (eval $ac_try) 2>&5 + ac_status=$? + echo "$as_me:$LINENO: \$? = $ac_status" >&5 + (exit $ac_status); }; }; then + ac_cv_lib_epoll_epoll_create=yes +else + echo "$as_me: failed program was:" >&5 +sed 's/^/| /' conftest.$ac_ext >&5 + +ac_cv_lib_epoll_epoll_create=no +fi +rm -f conftest.err conftest.$ac_objext \ + conftest$ac_exeext conftest.$ac_ext +LIBS=$ac_check_lib_save_LIBS +fi +echo "$as_me:$LINENO: result: $ac_cv_lib_epoll_epoll_create" >&5 +echo "${ECHO_T}$ac_cv_lib_epoll_epoll_create" >&6 +if test $ac_cv_lib_epoll_epoll_create = yes; then + cat >>confdefs.h <<_ACEOF +#define HAVE_LIBEPOLL 1 +_ACEOF + + LIBS="-lepoll $LIBS" + +fi + + echo "$as_me:$LINENO: checking for res_9_init in -lresolv" >&5 echo $ECHO_N "checking for res_9_init in -lresolv... $ECHO_C" >&6 if test "${ac_cv_lib_resolv_res_9_init+set}" = set; then @@ -16190,6 +16263,7 @@ + for ac_func in \ _lwp_create \ _lwp_self \ @@ -16202,6 +16276,7 @@ _vsnprintf \ chsize \ clone \ + epoll_create \ finite \ fpclass \ fstatfs \ @@ -16435,6 +16510,7 @@ + for ac_header in \ arpa/inet.h \ arpa/nameser.h \ @@ -16495,6 +16571,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.285 diff -u -r1.285 configure.ac --- configure.ac 6 Jul 2004 21:01:19 -0000 1.285 +++ configure.ac 24 Aug 2004 12:01:22 -0000 @@ -140,6 +140,8 @@ AC_CHECK_LIB(xpg4,_xpg4_setrunelocale) dnl Check for -lpoll for Mac OS X/Darwin AC_CHECK_LIB(poll,poll) +dnl Check for -lepoll +AC_CHECK_LIB(epoll,epoll_create) dnl Check for -lresolv for Mac OS X/Darwin AC_CHECK_LIB(resolv,res_9_init) dnl Check for -lpthread @@ -1036,6 +1038,7 @@ _vsnprintf \ chsize \ clone \ + epoll_create \ finite \ fpclass \ fstatfs \ @@ -1146,6 +1149,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.190 diff -u -r1.190 config.h.in --- include/config.h.in 18 Jun 2004 19:36:26 -0000 1.190 +++ include/config.h.in 24 Aug 2004 12:05:42 -0000 @@ -80,6 +80,9 @@ /* Define to 1 if you have the <elf.h> header file. */ #undef HAVE_ELF_H +/* Define to 1 if you have the `epoll_create' function. */ +#undef HAVE_EPOLL_CREATE + /* Define to 1 if you have the `finite' function. */ #undef HAVE_FINITE @@ -248,6 +251,9 @@ /* Define if you have the curses library (-lcurses) */ #undef HAVE_LIBCURSES +/* Define to 1 if you have the `epoll' library (-lepoll). */ +#undef HAVE_LIBEPOLL + /* Define if you have libgif/libungif including devel headers */ #undef HAVE_LIBGIF @@ -608,6 +614,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.21 diff -u -r1.21 fd.c --- server/fd.c 22 May 2004 03:15:04 -0000 1.21 +++ server/fd.c 24 Aug 2004 21:20:53 -0000 @@ -33,6 +33,12 @@ #ifdef HAVE_SYS_POLL_H #include <sys/poll.h> #endif +#ifdef HAVE_SYS_EPOLL_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> @@ -48,6 +54,9 @@ #include "winreg.h" #include "winternl.h" +#undef NDEBUG +#include <assert.h> + /* Because of the stupid Posix locking semantics, we need to keep * track of all file descriptors referencing a given file, and not * close a single one until all the locks are gone (sigh). @@ -255,51 +264,107 @@ /****************************************************************/ -/* poll support */ +/* poll and epoll support */ + +/* Vars used by both */ +static int active_users; /* current number of active users */ +/* Vars used by poll */ 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 */ -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 */ +/* 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 */ + +#if defined(HAVE_EPOLL_CREATE) && defined(HAVE_SYS_SYSCALL_H) +/* To prevent wine from not loading on non-epoll supporting platforms, + * we need to dynamically call the epoll functions */ +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 +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; +} +#endif + + /* 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) + if( epoll_fd>=0 ) /* We are using the epoll interface */ { - ret = freelist - poll_users; - freelist = (struct fd **)poll_users[ret]; + /* No poll array when using epoll - always return 1 */ + ret=1; } else - { - if (nb_users == allocated_users) + { /* We are using the poll interface */ + if (freelist) { - 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) ))) + ret = freelist - poll_users; + freelist = (struct fd **)poll_users[ret]; + } + else + { + if (nb_users == allocated_users) { - if (allocated_users) - poll_users = newusers; - else - free( newusers ); - return -1; + 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; } - 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; + ret = nb_users++; + } + pollfd[ret].fd = -1; + pollfd[ret].events = 0; + pollfd[ret].revents = 0; + poll_users[ret] = fd; + } active_users++; + return ret; } @@ -307,15 +372,37 @@ 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]; + 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 */ + if(!(_epoll_ctl(epoll_fd, EPOLL_CTL_DEL, fd->unix_fd, &event)==0 || errno==ENOENT)) + { + int err; + err=errno; + } + } + } + else + { + 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]; + } 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); +} /* server main poll() loop */ void main_loop(void) @@ -341,16 +428,44 @@ } if (!active_users) break; /* last user removed by a timeout */ } - ret = poll( pollfd, nb_users, diff ); - if (ret > 0) + if( epoll_fd>=0 ) { - int i; - for (i = 0; i < nb_users; i++) + /* 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 (pollfd[i].revents) + /* 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 ) { - fd_poll_event( poll_users[i], pollfd[i].revents ); - if (!--ret) break; + free(epoll_revents); + epoll_revents=new_revents; + epoll_revents_size=active_users; + } + } + + ret = epoll_wait(epoll_fd, epoll_revents, epoll_revents_size, diff ); + while( (ret--)>0 ) + { + fd_poll_event((struct fd *)epoll_revents[ret].data.ptr, epoll_revents[ret].events); + } + } + else + { + /* No epoll support - use poll */ + ret = poll( pollfd, nb_users, diff ); + if (ret > 0) + { + int i; + for (i = 0; i < nb_users; i++) + { + if (pollfd[i].revents) + { + fd_poll_event( poll_users[i], pollfd[i].revents ); + if (!--ret) break; + } } } } @@ -835,18 +950,46 @@ /* 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 */ + 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.ptr=fd; + + assert(fd->unix_fd>=0); + + if( events != -1 ) + { + int epoll_res; + if( (epoll_res=_epoll_ctl(epoll_fd, EPOLL_CTL_MOD, fd->unix_fd, &event )!=0) && errno==ENOENT ) + { + /* For one reason or another this file descriptor isn't being watched at the moment. Just add it */ + assert(_epoll_ctl(epoll_fd, EPOLL_CTL_ADD, fd->unix_fd, &event )==0); + } + else + assert(epoll_res==0); + } + else + { + /* Stop waiting on this fd completely */ + assert(_epoll_ctl(epoll_fd, EPOLL_CTL_DEL, fd->unix_fd, &event )==0); + } } - else if (pollfd[user].fd != -1 || !pollfd[user].events) + else { - pollfd[user].fd = fd->unix_fd; - pollfd[user].events = events; + int user = fd->poll_index; + assert( poll_users[user] == fd ); + if (events == -1) /* stop waiting on this fd completely */ + { + pollfd[user].fd = -1; + pollfd[user].events = POLLERR; + pollfd[user].revents = 0; + } + else if (pollfd[user].fd != -1 || !pollfd[user].events) + { + pollfd[user].fd = fd->unix_fd; + pollfd[user].events = events; + } } } Index: server/file.h =================================================================== RCS file: /home/sun/sources/cvs/wine/server/file.h,v retrieving revision 1.16 diff -u -r1.16 file.h --- server/file.h 16 Apr 2004 04:31:35 -0000 1.16 +++ server/file.h 24 Aug 2004 13:34:21 -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 24 Aug 2004 15:49:33 -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 );

2 3

Patch for CreateDIBitmap: Don't create monochrome bitmaps (help wanted)
by Michael Kaufmann 26 Aug '04

26 Aug '04

Hi all, I need some help in fixing a bug in CreateDIBitmap. I've attached a patch, but unfortunately it introduces new bugs. The function CreateDIBitmap creates a monochrome device-dependent bitmap if it's possible. But that's very bad, because BitBlt and StretchBlt handle monochrome bitmaps in a different way than color bitmaps (copied from MSDN): "If *StretchBlt* must convert a monochrome bitmap to a color bitmap, it sets white bits (1) to the background color and black bits (0) to the foreground color. The foreground and background colors of the device context with color are used." So SetTextColor and SetBkColor can change the colors of the (formerly device independent) bitmap, and that's not what we want. The attached patch fixes this bug (don't create monochrome bitmaps anymore), but it seems that other code in WINE depends on the old behavior. The mouse cursor is now completely garbage. Can anybody help me finding the remaining bugs? Test Program (DIB-Testcase.zip): --------------------------------- I've created a test program that shows the problem. It also shows a bug in Windows! It displays two bitmaps, both should be black and white. WINE displays them red on green (I've set these colors with SetTextColor/SetBkColor). The images differ only in a single byte. I've used the program bmpdump ( http://david.tribble.com/programs.html ) to analyze them. In the color table of the bitmaps, the rgbReserved member of a RGBQUAD structure is 0x00 for the left bitmap and 0xFF for the right bitmap. This shouldn't make a difference. But Windows creates a monochrome bitmap for the left one, and a color bitmap for the right one! Does anyone understand this behavior? Regards Michael Index: dlls/gdi/dib.c =================================================================== RCS file: /home/wine/wine/dlls/gdi/dib.c,v retrieving revision 1.3 diff -u -r1.3 dib.c --- dlls/gdi/dib.c 12 Aug 2004 20:02:39 -0000 1.3 +++ dlls/gdi/dib.c 23 Aug 2004 14:45:03 -0000 @@ -779,7 +779,6 @@ UINT coloruse ) { HBITMAP handle; - BOOL fColor; DWORD width; int height; WORD bpp; @@ -789,79 +788,10 @@ if (DIB_GetBitmapInfo( header, &width, &height, &bpp, &compr ) == -1) return 0; if (height < 0) height = -height; - /* Check if we should create a monochrome or color bitmap. */ - /* We create a monochrome bitmap only if it has exactly 2 */ - /* colors, which are black followed by white, nothing else. */ - /* In all other cases, we create a color bitmap. */ - - if (bpp != 1) fColor = TRUE; - else if ((coloruse != DIB_RGB_COLORS) || !data) fColor = FALSE; - else - { - if (data->bmiHeader.biSize == sizeof(BITMAPINFOHEADER)) - { - RGBQUAD *rgb = data->bmiColors; - DWORD col = RGB( rgb->rgbRed, rgb->rgbGreen, rgb->rgbBlue ); - - /* Check if the first color of the colormap is black */ - if ((col == RGB(0,0,0))) - { - rgb++; - col = RGB( rgb->rgbRed, rgb->rgbGreen, rgb->rgbBlue ); - /* If the second color is white, create a monochrome bitmap */ - fColor = (col != RGB(0xff,0xff,0xff)); - } - /* Note : If the first color of the colormap is white - followed by black, we have to create a color bitmap. - If we don't the white will be displayed in black later on!*/ - else fColor = TRUE; - } - else if (data->bmiHeader.biSize == sizeof(BITMAPCOREHEADER)) - { - RGBTRIPLE *rgb = ((BITMAPCOREINFO *)data)->bmciColors; - DWORD col = RGB( rgb->rgbtRed, rgb->rgbtGreen, rgb->rgbtBlue ); - if ((col == RGB(0,0,0))) - { - rgb++; - col = RGB( rgb->rgbtRed, rgb->rgbtGreen, rgb->rgbtBlue ); - fColor = (col != RGB(0xff,0xff,0xff)); - } - else fColor = TRUE; - } - else if (data->bmiHeader.biSize == sizeof(BITMAPV4HEADER)) - { /* FIXME: correct ? */ - RGBQUAD *rgb = data->bmiColors; - DWORD col = RGB( rgb->rgbRed, rgb->rgbGreen, rgb->rgbBlue ); - - /* Check if the first color of the colormap is black */ - if ((col == RGB(0,0,0))) - { - rgb++; - col = RGB( rgb->rgbRed, rgb->rgbGreen, rgb->rgbBlue ); - /* If the second color is white, create a monochrome bitmap */ - fColor = (col != RGB(0xff,0xff,0xff)); - } - /* Note : If the first color of the colormap is white - followed by black, we have to create a color bitmap. - If we don't the white will be displayed in black later on!*/ - else fColor = TRUE; - } - else - { - ERR("(%ld): wrong/unknown size for data\n", - data->bmiHeader.biSize ); - return 0; - } - } - - /* Now create the bitmap */ - if (!(dc = DC_GetDCPtr( hdc ))) return 0; - if (fColor) - handle = CreateBitmap( width, height, GetDeviceCaps( hdc, PLANES ), + handle = CreateBitmap( width, height, GetDeviceCaps( hdc, PLANES ), GetDeviceCaps( hdc, BITSPIXEL ), NULL ); - else handle = CreateBitmap( width, height, 1, 1, NULL ); if (handle) {

2 3

Re: Don
by Ivan Leo Puoti 26 Aug '04

26 Aug '04

>Maybe, yes. How long does it take? I didn't time it but it does take some time. >I think I killed it after about 5 >minutes of constant thrashing. Maybe you should just leave it and see how long it takes. >Possibly it's something to do with using the FC2 kernel instead of a >stock one ? I don't know much about the FC2 kernel, maybe you should try with the real thing www.kernel.org Ivan.

1 0

broken freecell
by gslink 26 Aug '04

26 Aug '04

Has anyone noticed that one of the patches in either the July or August release broke the Microsoft Freecell. It used to be that when the full screen button was pressed the Freecell window expanded to fill the screen. Now the fill is only in the vertical. Dragging appears to work but results in a ghost border when the full screen button in Freecell is pushed and the window snaps back to original size in the horizontal.

2 1

Document dosdevices/unc/
by Tobias Burnus 26 Aug '04

26 Aug '04

Hello, I found an email by Fergal Daly (http://www.mail-archive.com/wine-devel@winehq.org/msg08815.html) which kind of patches configuring.sgml to document dosdevices/unc. I transformed it into a proper patch for configuring.sgml Tobias

1 1

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