- wine-devel - winehq.org

Re: ADVAPI32: SHA functions
by Dmitry Timoshkov 17 Sep '04

17 Sep '04

"Filip Navara" <xnavara(a)volny.cz> wrote: > --- /dev/null Fri Sep 17 17:41:26 2004 > +++ dlls/advapi32/crypt_sha.c Thu Sep 16 22:34:13 2004 This is the first crypt_sha.c, with an API implementation. > --- /dev/null Fri Sep 17 17:41:59 2004 > +++ dlls/advapi32/crypt_sha.c Fri Sep 17 16:20:32 2004 This is the second crypt_sha.c, with an API test. It seems that this crypt_sha.c was supposed to go in the tests subdirectory. -- Dmitry.

1 0

Re: Lostwages add seti@home link
by hatky 17 Sep '04

17 Sep '04

May I ask in what way does a person running seti@home helps wine? Not that I am against the project but you make it sound as a needed contribution to wine, well I don't see it helping wine too much except some extra attention from random sources, and it isn't even open source, mybe some other place? Resources -> others ? I would say links -> others but we don't have that :) And another thing please update the seti@home group home page to winehq.org from the winehq.com it has, thanks. On Friday 17 September 2004 02:17, Ivan Leo Puoti wrote: > Add a link to our seti@home team in the contirbuting page. > > Ivan. -- Hatky, Worshiper of wine (http://www.winehq.org/), Impossible is only an opinion.

1 0

Re: Cryptographic functions
by Juan Lang 16 Sep '04

16 Sep '04

Patching advapi32.spec to add the stubs looks correct. Go ahead and submit to wine-patches. --Juan _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com

4 6

Re: winedos:MCB implementation
by Alexandre Julliard 16 Sep '04

16 Sep '04

Markus Amsler <markus.amsler(a)oribi.org> writes: > Please let me know, if there's something wrong with the patch (design > problems, naming conventions, formating, ...). The main problem is that you now have both the MCB and the DOSMEM code trying to allocate memory in the same area, that won't work. What you probably want is to make the DOSMEM functions call out to the MCB ones. -- Alexandre Julliard julliard(a)winehq.org

2 2

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

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