- Wine-devel - list.winehq.org

MSI (MS Installer)
by Scott Cote 10 Dec '02

10 Dec '02

I've found that many of the test applications I've tried installing failed due to the lack of MSIEXEC. If it is implemented, could you tell me where to find it? If not, I'd like to contribute, could you tell me if any work has been done and who to coordinate with? Thanks, -Scott

10 12

test
by Tom 10 Dec '02

10 Dec '02

I sent two emails about 15 min ago and they have not shown up.. So this is just a test.. Sorry Tom

1 0

Warning fix in msvcrt_test
by Vincent Béron 10 Dec '02

10 Dec '02

Another thing noticed while compiling the tests on MSVC... In the msvcrt_test project, the link finishes with this warning: LINK : warning LNK4098: defaultlib "LIBCMTD" conflicts with use of other libs; use /NODEFAULTLIB:library It's pretty easy to fix it manually (and the warning doesn't seem to cause harm), but it would be nice of Patrik to incorporate what this patch does (the project's file is a generated file, so the patch cannot be directly applied to CVS). Vincent --- wine/dlls/msvcrt/tests/msvcrt_test.dsp 2002-12-10 09:33:46.000000000 -0500 +++ wine/dlls/msvcrt/tests/msvcrt_test.dsp 2002-12-10 11:06:21.000000000 -0500 @@ -38,6 +38,7 @@ # PROP Use_Debug_Libraries 1 # PROP Output_Dir "Output\Win32_MSVC_Headers" # PROP Intermediate_Dir "Output\Win32_MSVC_Headers" +# PROP Ignore_Export_Lib 0 # PROP Target_Dir "" # ADD BASE CPP /nologo /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_MBCS" /D "_LIB" /YX /FD /GZ /c # ADD CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /I ..\..\..\Output\\Win32_MSVC_Headers /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "_MSVCRT_TEST_" /D "__WINE_USE_MSVCRT" /D __WINETEST_OUTPUT_DIR=\"Output\\Win32_MSVC_Headers\" /D "__i386__" /D "_X86_" /D inline=__inline /FR /FD /GZ /c @@ -48,7 +48,7 @@ # ADD BSC32 /nologo LINK32=link.exe # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /debug /machine:I386 /pdbtype:sept -# ADD LINK32 /nologo msvcrt.lib /subsystem:console /debug /machine:I386 /pdbtype:sept +# ADD LINK32 msvcrt.lib /nologo /subsystem:console /debug /machine:I386 /nodefaultlib:"libcmtd.lib" /pdbtype:sept !ELSEIF "$(CFG)" == "msvcrt_test - Win32 Wine Headers" @@ -61,6 +62,7 @@ # PROP Use_Debug_Libraries 1 # PROP Output_Dir "Output\Win32_Wine_Headers" # PROP Intermediate_Dir "Output\Win32_Wine_Headers" +# PROP Ignore_Export_Lib 0 # PROP Target_Dir "" # ADD BASE CPP /nologo /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_MBCS" /D "_LIB" /YX /FD /GZ /c # ADD CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /I ..\..\..\Output\\Win32_Wine_Headers /I ..\..\..\include /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "_MSVCRT_TEST_" /D "__WINE_USE_MSVCRT" /D __WINETEST_OUTPUT_DIR=\"Output\\Win32_Wine_Headers\" /D "__i386__" /D "_X86_" /D inline=__inline /FR /FD /GZ /c @@ -71,7 +71,7 @@ # ADD BSC32 /nologo LINK32=link.exe # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /subsystem:console /debug /machine:I386 /pdbtype:sept -# ADD LINK32 /nologo msvcrt.lib /subsystem:console /debug /machine:I386 /pdbtype:sept +# ADD LINK32 msvcrt.lib /nologo /subsystem:console /debug /machine:I386 /nodefaultlib:"libcmtd.lib" /pdbtype:sept !ENDIF

1 0

Recent wrc changes break mingw
by Steven Edwards 10 Dec '02

10 Dec '02

Mingw lacks getopt.h so we are now broken on mingw. Should I rip the needed support and add it to libwine or is there a better way? gcc -c -I. -I. -I../../include -I../../include -D__MINGW__ -D_WINDOWS -DWINE_NO WINSOCK -Wall -mpreferred-stack-boundary=2 -D__WINE__ -D_REENTRANT -o wrc.o wrc .c wrc.c:62:20: getopt.h: No such file or directory wrc.c:287: elements of array `long_options' have incomplete type wrc.c:288: warning: excess elements in struct initializer wrc.c:288: warning: (near initialization for `long_options[0]') wrc.c:288: warning: excess elements in struct initializer wrc.c:288: warning: (near initialization for `long_options[0]') wrc.c:288: warning: excess elements in struct initializer wrc.c:288: warning: (near initialization for `long_options[0]') wrc.c:288: warning: excess elements in struct initializer wrc.c:288: warning: (near initialization for `long_options[0]') wrc.c:289: warning: excess elements in struct initializer wrc.c:289: warning: (near initialization for `long_options[1]') wrc.c:289: warning: excess elements in struct initializer wrc.c:289: warning: (near initialization for `long_options[1]') wrc.c:289: warning: excess elements in struct initializer wrc.c:289: warning: (near initialization for `long_options[1]') wrc.c:289: warning: excess elements in struct initializer wrc.c:289: warning: (near initialization for `long_options[1]') wrc.c:290: warning: excess elements in struct initializer wrc.c:290: warning: (near initialization for `long_options[2]') wrc.c:290: warning: excess elements in struct initializer wrc.c:290: warning: (near initialization for `long_options[2]') wrc.c:290: warning: excess elements in struct initializer wrc.c:290: warning: (near initialization for `long_options[2]') wrc.c:290: warning: excess elements in struct initializer wrc.c:290: warning: (near initialization for `long_options[2]') wrc.c:291: warning: excess elements in struct initializer wrc.c:291: warning: (near initialization for `long_options[3]') wrc.c:291: warning: excess elements in struct initializer wrc.c:291: warning: (near initialization for `long_options[3]') wrc.c:291: warning: excess elements in struct initializer wrc.c:291: warning: (near initialization for `long_options[3]') wrc.c:291: warning: excess elements in struct initializer wrc.c:291: warning: (near initialization for `long_options[3]') wrc.c:292: warning: excess elements in struct initializer wrc.c:292: warning: (near initialization for `long_options[4]') wrc.c:292: warning: excess elements in struct initializer wrc.c:292: warning: (near initialization for `long_options[4]') wrc.c:292: warning: excess elements in struct initializer wrc.c:292: warning: (near initialization for `long_options[4]') wrc.c:292: warning: excess elements in struct initializer wrc.c:292: warning: (near initialization for `long_options[4]') wrc.c:293: warning: excess elements in struct initializer wrc.c:293: warning: (near initialization for `long_options[5]') wrc.c:293: warning: excess elements in struct initializer wrc.c:293: warning: (near initialization for `long_options[5]') wrc.c:293: warning: excess elements in struct initializer wrc.c:293: warning: (near initialization for `long_options[5]') wrc.c:293: warning: excess elements in struct initializer wrc.c:293: warning: (near initialization for `long_options[5]') wrc.c:294: warning: excess elements in struct initializer wrc.c:294: warning: (near initialization for `long_options[6]') wrc.c:294: warning: excess elements in struct initializer wrc.c:294: warning: (near initialization for `long_options[6]') wrc.c:294: warning: excess elements in struct initializer wrc.c:294: warning: (near initialization for `long_options[6]') wrc.c:294: warning: excess elements in struct initializer wrc.c:294: warning: (near initialization for `long_options[6]') wrc.c:295: warning: excess elements in struct initializer wrc.c:295: warning: (near initialization for `long_options[7]') wrc.c:295: warning: excess elements in struct initializer wrc.c:295: warning: (near initialization for `long_options[7]') wrc.c:295: warning: excess elements in struct initializer wrc.c:295: warning: (near initialization for `long_options[7]') wrc.c:295: warning: excess elements in struct initializer wrc.c:295: warning: (near initialization for `long_options[7]') wrc.c:296: warning: excess elements in struct initializer wrc.c:296: warning: (near initialization for `long_options[8]') wrc.c:296: warning: excess elements in struct initializer wrc.c:296: warning: (near initialization for `long_options[8]') wrc.c:296: warning: excess elements in struct initializer wrc.c:296: warning: (near initialization for `long_options[8]') wrc.c:296: warning: excess elements in struct initializer wrc.c:296: warning: (near initialization for `long_options[8]') wrc.c:297: warning: excess elements in struct initializer wrc.c:297: warning: (near initialization for `long_options[9]') wrc.c:297: warning: excess elements in struct initializer wrc.c:297: warning: (near initialization for `long_options[9]') wrc.c:297: warning: excess elements in struct initializer wrc.c:297: warning: (near initialization for `long_options[9]') wrc.c:297: warning: excess elements in struct initializer wrc.c:297: warning: (near initialization for `long_options[9]') wrc.c:298: warning: excess elements in struct initializer wrc.c:298: warning: (near initialization for `long_options[10]') wrc.c:298: warning: excess elements in struct initializer wrc.c:298: warning: (near initialization for `long_options[10]') wrc.c:298: warning: excess elements in struct initializer wrc.c:298: warning: (near initialization for `long_options[10]') wrc.c:298: warning: excess elements in struct initializer wrc.c:298: warning: (near initialization for `long_options[10]') wrc.c: In function `main': wrc.c:330: warning: implicit declaration of function `getopt_long' make[2]: *** [wrc.o] Error 1 make[2]: Leaving directory `/g/src/wine-dev/wine/tools/wrc' make[1]: *** [wrc] Error 2 make[1]: Leaving directory `/g/src/wine-dev/wine/tools' make: *** [tools] Error 2 isolation(a)PH33R /g/src/wine-dev/wine $ __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

2 2

Accented Characters
by Richard Allen 10 Dec '02

10 Dec '02

Hello all. I've been trying to get accented characters to work propperly in wine. For those who dont know, accented characters are beasts like "áéýúíó" We obtain them by pressing the dead key (mute_acute in my case) and then the key we want accented. I'm using CVS as of yesterday. [ra(a)xo winecvs]$ cat wine/VERSION Wine version 20021125 As far as I can tell, dlls/x11drv/keyboard.c seems to be where my problem is. [ra(a)xo ra]$ wine /home/ra/.wine/c_drive/Program\ Files/mIRC/mirc.exe fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (Icelandic keyboard layout) for scancode mapping. Please define your layout in windows/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information. Now, keyboard.c does have a definition for the Icelandic keyboard, but as far as I can tell it's only used to recognize what keymap is in action, and not to define it ?. I've experimented with it, things like changing the "2" key to a "b" but it did not change the keyboard layout. The warning above is just because the definition in wine for the IS keymap doesnt match the one thats shipping with XFRee86 completely ? Anyway. my battle for the accented characters continues. The keyboard handling in wine is unlike anything I've ever seen before. Can anyone give me a quick runthru on how keyboard handling really works in wine, and prehaps help fix this ? Also, how are accented characters (dead keys) working in other languages ? Is this a problem limited to Icelandic or to accented characters in general ? Thanks in advance for any help :) -- Rikki. -- RHCE, RHCX, HP-UX Certified Administrator. -- Solaris 7 Certified Systems and Network Administrator. Bell Labs Unix -- Reach out and grep someone. Those who do not understand Unix are condemned to reinvent it, poorly.

2 1

Conformance tests --MSVC Headers 2 of 2
by Tom 10 Dec '02

10 Dec '02

Build Log --------------------Configuration: ntdll_test - Win32 MSVC Headers-------------------- Command Lines Creating temporary file "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2C.tmp" with contents [ /nologo /MTd /W3 /Gm /GX /ZI /Od /I "..\..\..\Output\\Win32_MSVC_Headers" /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "_NTDLL_TEST_" /D "__WINE_USE_MSVCRT" /D __WINETEST_OUTPUT_DIR=\"Output\\Win32_MSVC_Headers\" /D "__i386__" /D "_X86_" /D inline=__inline /FR"Output\Win32_MSVC_Headers/" /Fo"Output\Win32_MSVC_Headers/" /Fd"Output\Win32_MSVC_Headers/" /FD /GZ /c "C:\include\wine\dlls\ntdll\tests\error.c" "C:\include\wine\dlls\ntdll\tests\rtlbitmap.c" "C:\include\wine\dlls\ntdll\tests\rtlstr.c" ] Creating command line "cl.exe @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2C.tmp" Creating temporary file "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2D.tmp" with contents [ /nologo /subsystem:console /incremental:yes /pdb:"Output\Win32_MSVC_Headers/ntdll_test.pdb" /debug /machine:I386 /out:"Output\Win32_MSVC_Headers/ntdll_test.exe" /pdbtype:sept .\Output\Win32_MSVC_Headers\error.obj .\Output\Win32_MSVC_Headers\generated.obj .\Output\Win32_MSVC_Headers\rtlbitmap.obj .\Output\Win32_MSVC_Headers\rtlstr.obj .\Output\Win32_MSVC_Headers\testlist.obj ] Creating command line "link.exe @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2D.tmp" Output Window Build Log --------------------Configuration: oleaut32_test - Win32 MSVC Headers-------------------- Command Lines Creating temporary file "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2E.tmp" with contents [ /nologo /MTd /W3 /Gm /GX /ZI /Od /I "..\..\..\Output\\Win32_MSVC_Headers" /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "_OLEAUT32_TEST_" /D "__WINE_USE_MSVCRT" /D __WINETEST_OUTPUT_DIR=\"Output\\Win32_MSVC_Headers\" /D "__i386__" /D "_X86_" /D inline=__inline /FR"Output\Win32_MSVC_Headers/" /Fo"Output\Win32_MSVC_Headers/" /Fd"Output\Win32_MSVC_Headers/" /FD /GZ /c "C:\include\wine\dlls\oleaut32\tests\vartest.c" ] Creating command line "cl.exe @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2E.tmp" Creating temporary file "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2F.tmp" with contents [ oleaut32.lib /nologo /subsystem:console /incremental:yes /pdb:"Output\Win32_MSVC_Headers/oleaut32_test.pdb" /debug /machine:I386 /out:"Output\Win32_MSVC_Headers/oleaut32_test.exe" /pdbtype:sept .\Output\Win32_MSVC_Headers\vartest.obj .\Output\Win32_MSVC_Headers\testlist.obj ] Creating command line "link.exe @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2F.tmp" Output Window Build Log --------------------Configuration: ntdll_test - Win32 MSVC Headers-------------------- Command Lines Creating temporary file "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2C.tmp" with contents [ /nologo /MTd /W3 /Gm /GX /ZI /Od /I "..\..\..\Output\\Win32_MSVC_Headers" /D "_DEBUG" /D "WIN32" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "_NTDLL_TEST_" /D "__WINE_USE_MSVCRT" /D __WINETEST_OUTPUT_DIR=\"Output\\Win32_MSVC_Headers\" /D "__i386__" /D "_X86_" /D inline=__inline /FR"Output\Win32_MSVC_Headers/" /Fo"Output\Win32_MSVC_Headers/" /Fd"Output\Win32_MSVC_Headers/" /FD /GZ /c "C:\include\wine\dlls\ntdll\tests\error.c" "C:\include\wine\dlls\ntdll\tests\rtlbitmap.c" "C:\include\wine\dlls\ntdll\tests\rtlstr.c" ] Creating command line "cl.exe @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2C.tmp" Creating temporary file "C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2D.tmp" with contents [ /nologo /subsystem:console /incremental:yes /pdb:"Output\Win32_MSVC_Headers/ntdll_test.pdb" /debug /machine:I386 /out:"Output\Win32_MSVC_Headers/ntdll_test.exe" /pdbtype:sept .\Output\Win32_MSVC_Headers\error.obj .\Output\Win32_MSVC_Headers\generated.obj .\Output\Win32_MSVC_Headers\rtlbitmap.obj .\Output\Win32_MSVC_Headers\rtlstr.obj .\Output\Win32_MSVC_Headers\testlist.obj ] Creating command line "link.exe @C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\RSP2D.tmp" Output Window

1 0

what to do with include/wine/obj_base.h?
by Ove Kaaven 10 Dec '02

10 Dec '02

I've submitted a patch to move the API prototypes out of obj_base.h, and I'd now be ready to submit unknwn.idl and unknwn.h, which would also supersede the interfaces defined in there, but I'm unsure about what to do with the remainder of it, namely the ICOM_* macros in there. Note that there's a shortcoming of those macros, they don't handle array arguments. Such arguments are binary-compatible with pointer arguments though, so it's not a serious shortcoming for Wine and widl (which could easily convert array args in IDL to pointer args in C), but it's a little ugly and may have source-compatibility issues if widl is used by Winelib code that implements interfaces with such method args. There are standard COM interfaces with this problem too, e.g. IPropertyStorage, but since such interfaces are implemented by Wine and not by app code, there's unlikely to be source-compatibility issues there. So the options include 1) keep using obj_base.h as it is, let widl use those macros as is (and convert array args to pointer args), include it into unknwn.h 2) move ICOM macros to include/objbase.h, and dispose of obj_base.h 3) make widl use the MS-style macros in objbase.h (but I'm not sure what to do about ICOM_MSVTABLE_COMPAT and ICOM_USE_COM_INTERFACE_ATTRIBUTE in this case) 4) make widl not use macros at all, but emit full C and C++ definitions directly (this is what midl.exe does, it seems) 5) make widl support any of the above with a command-line option, so that Wine headers uses 1 or 2, while Winelib apps get to use 3 or 4. 6) redesign the ICOM macros (but I doubt anyone's going to volunteer for that unless tied to a chair supervised by an ancient master of torture with a cat-o'-nine-tails in his toolbox, there's too much code to change)

4 5

Re: wine/dlls/winsock/socket.c: Force SO_REUSEADDR ...
by Martin Wilck 10 Dec '02

10 Dec '02

Hi, judging from the Traces these programs are rare examples of lame network programming. You find series of things that shouldn't be done, such as bind()ing in a client application, not closing down a socket cleanly but expecting the next bind() to the same address to succeed, polling the socket with ioctl (FIONREAD), etc. I am really asking myself if it's right to hack wine to violate the specs just for the sake of so poorly programmed applications. I'd be grateful for advice by experienced Wine hackers here. Perhaps we need to introduce Windows version-dependent behavior. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:Martin.Wilck(a)Fujitsu-Siemens.com D-33106 Paderborn http://www.fujitsu-siemens.com/primergy

2 1

Re: Janitorial Projects -- conformance tests --recruiting volunteers
by David Miller 10 Dec '02

10 Dec '02

I could probably run some tests under WinXP. I just need to compile the tests on windows, execute them, and post output to wine-devel? Is this correct?

7 12

Re: strcat+strcat+strcat == baaad"
by Jeff Smith 10 Dec '02

10 Dec '02

You caught me... I thought something like this existed. I would say that by default, Auto should be 0. I think this would be best for the average user. They are probably even less likely than me to read the debugging documentation (and want to change a registry setting like this). -- Jeff S >From: Eric Pouech <eric.pouech(a)wanadoo.fr> > >>Can we do something like throw up a message box before loading the >>debugger, >>asking if we want to debug? Or perhaps there should be a command-line >>option to >>the debugger that presents said dialog, then use that option when starting >>the >>debugger in the event of an crash. >RTFM >hints: AeDebug, Auto >A+ _________________________________________________________________ STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail

1 0