Re: Houston, we have a problem...
On Thu, 12 Dec 2002, Dimitrie O. Paun wrote: Configure finished. Do 'make depend make' to compile Wine. cd `dirname dlls/__depend__` make depend make[1]: Entering directory `/opt/dimi/dev/wine/wine/dlls' cd `dirname advapi32/__depend__` make depend make[2]: Entering directory `/opt/dimi/dev/wine/wine/dlls/advapi32' cd `dirname tests/__depend__` make depend make[3]: Entering directory `/opt/dimi/dev/wine/wine/dlls/advapi32/tests' ../../../tools/makedep -I../../../../wine.src/dlls/advapi32/tests -I. -I../../../../wine.src/include -I../../../include -C../../../../wine.src/dlls/advapi32/tests registry.c testlist.c ../../../../wine.src/dlls/advapi32/tests/testlist.c: No such file or directory Ah, you're building out of tree too g. You need to recompile makedep. For instance: rm ../../../tools/makedep.o make depend Now I must say that I wonder why this was not done automatically. Shouldn't the .c.o dependency kick in automatically in tools/Makefile.in? Maybe you can solve this one? -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0
Re: Conformance tests on Win95 (was NT)
I could at least try, I also have a second computer, like P90 or so. It's just used for burning CDs while I can continue working on the other. I'm not sure about the Win95 version, but I will have a look and try this evening. Ok, I had a run. They pretty much match the results for Win95 on this page: http://fgouget.free.fr/wine/tests-en.shtml So I only post the differences. Oh yeah, I'd appreciate too if output was sent to stdout instead of stderr. :) Microsoft Windows 95 (4.00.950a) - advapi32_test.exe registry [GPF]: error in Advapi32_test.exe at 014f:004010c9 - dsound_test.exe dsound dsound.c:56:Testing Primärer Audiotreiber - dsound.c:70: DirectSound Caps: flags=0x091f secondary min=100 max=10 dsound.c:100: PrimaryBuffer Caps: flags=0x0005 size=32768 dsound.c:113: tag=0x0001 22050x8x2 avg.B/s=44100 align=2 dsound.c:129: status=0x dsound.c:56:Testing SoundBlaster AWE32 Direct Sound Driver [220] - SB16.VXD dsound.c:70: DirectSound Caps: flags=0x091f secondary min=100 max=10 dsound.c:100: PrimaryBuffer Caps: flags=0x0005 size=32768 dsound.c:113: tag=0x0001 22050x8x2 avg.B/s=44100 align=2 dsound.c:129: status=0x dsound: 27 tests executed, 0 marked as todo, 0 failures. - kernel32_test.exe atom atom.c:55:WARNING: Unicode atom APIs are not supported on this platform atom: 163850 tests executed, 0 marked as todo, 0 failures. - kernel32_test.exe codepage codepage.c:40: Test failed: any negative value should work as strlen() + 1 codepage: 2 tests executed, 0 marked as todo, 1 failure. - kernel32_test.exe file file.c:631: Test failed: WriteFile error 183 file.c:632: Test failed: expected number of bytes written 0 file.c:633:Current offset = 0100 file.c:634: Test failed: expected file offset 21 file.c:639: Test failed: WriteFile error 87 file.c:640: Test failed: expected number of bytes written 0 file.c:642: Test failed: expected file offset 517 file.c:656: Test failed: ReadFile error 0 file.c:657: Test failed: expected number of bytes read 0 file.c:658:Current offset = file.c:659: Test failed: expected file offset 21 file.c:661: Test failed: pattern match failed file: 487224 tests executed, 0 marked as todo, 10 failures. - kernel32_test.exe locale locale.c:126: Test failed: GetTimeFormat with len=2 got xxÌÌ instead of AMxx locale.c:181: Test failed: GetDateFormat got xxÌÌÒ instead of Saxx locale.c:199: Test failed: GetDateFormatW allowed flags and format locale.c:205: Test failed: GetDateFormatW did not detect null buffer pointer. locale.c:208: Test failed: GetDateFormatW did not permit null buffer pointer when counting. locale.c:224: Test failed: Day of week correction failed locale.c:312: Test failed: GetNumberFormat with len=2 got xxÌÌW instead of 2,xx locale.c:270: Test failed: GetCurrencyFormat got xxÌÌW instead of $23.53 locale: 54 tests executed, 0 marked as todo, 8 failures. - msvcrt_test.exe scanf scanf: 6 tests executed, 0 marked as todo, 0 failures. - ntdll_test.exe error ntdll_test.exe rtlbitmap ntdll_test.exe rtlstr [Test files not in zip] - shell32_test.exe shlfileop shlfileop.c:225: Test failed: Can't copy many files shlfileop.c:226: Test failed: The file is not copied - many files are specified as a target shlfileop.c:234: Test failed: Can't copy many files shlfileop.c:244: Test failed: Can't copy many files shlfileop.c:245: Test failed: The file is not copied - many files are specified as a target shlfileop.c:329: Test failed: Move many files shlfileop.c:341: Test failed: Can't move many files shlfileop.c:342: Test failed: The file is not moved - many files are specified as a target shlfileop.c:354: Test failed: Can not move many files shlfileop.c:355: Test failed: The file is not moved. Many files are specified shlfileop.c:356: Test failed: The directory not is moved. Many files are specified shlfileop.c:371: Test failed: The dir is moved shlfileop: 121 tests executed, 0 marked as todo, 12 failures. - shlwapi_test.exe clist shlwapi_test.exe shreg [Error]: Needed dll Shlwapi.dll not found - user32_test.exe win Many tests failed.(just the ending captured) ... win.c:160:created popup 0368 win.c:62: Test failed: Wrong result for GetParent expected 0080 win.c:170:created owned popup 036C win.c:60: Test failed: Wrong result for GWL_HWNDPARENT expected 03C8 win.c:60: Test failed: Wrong result for GWL_HWNDPARENT expected 03C8 win.c:62:
make checklink broken?
Am I missing something, or is make checklink broken? It seems only to run for a few directories now, whereas the rest show nothing to do. Here's a chunk of the output: ... make[2]: Entering directory `/var/src/wine/dlls/winmm/wineoss' make[2]: Nothing to be done for `checklink'. make[2]: Leaving directory `/var/src/wine/dlls/winmm/wineoss' make[2]: Entering directory `/var/src/wine/dlls/winnls' gcc -o checklink -Wl,-rpath,../../dlls -Wl,-rpath,../../library -Wl,-rpath,../../unicode ../../library/checklink.c winnls32.spec.o winnls.o winnls32.dll.dbg.o -L../../dlls -L../../library -lwine -lm rm -f checklink make[2]: Leaving directory `/var/src/wine/dlls/winnls' make[2]: Entering directory `/var/src/wine/dlls/winsock' gcc -o checklink -Wl,-rpath,../../dlls -Wl,-rpath,../../library -Wl,-rpath,../../unicode ../../library/checklink.c ws2_32.spec.o async.o socket.o ws2_32.dll.dbg.o -L../../dlls -L../../library -lwine -lm rm -f checklink make[2]: Leaving directory `/var/src/wine/dlls/winsock' make[2]: Entering directory `/var/src/wine/dlls/winspool' make[2]: Nothing to be done for `checklink'. make[2]: Leaving directory `/var/src/wine/dlls/winspool' make[2]: Entering directory `/var/src/wine/dlls/wintrust' make[2]: Nothing to be done for `checklink'. make[2]: Leaving directory `/var/src/wine/dlls/wintrust' make[2]: Entering directory `/var/src/wine/dlls/wow32' make[2]: Nothing to be done for `checklink'. make[2]: Leaving directory `/var/src/wine/dlls/wow32' make[2]: Entering directory `/var/src/wine/dlls/wsock32' make[2]: Nothing to be done for `checklink'. make[2]: Leaving directory `/var/src/wine/dlls/wsock32' make[2]: Entering directory `/var/src/wine/dlls/glu32' make[2]: Nothing to be done for `checklink'. make[2]: Leaving directory `/var/src/wine/dlls/glu32' make[2]: Entering directory `/var/src/wine/dlls/d3d8' make[2]: Nothing to be done for `checklink'. make[2]: Leaving directory `/var/src/wine/dlls/d3d8' ... -- gmt
any one have korean XIM support patch?
hello everyone: I just working hard to improve / implement the XIM support in wine based on the work of Mike McCormack. His original patch support Japanese, thus I think mime will work with japanese too. While I heared that there was a patch for korean XIM support, I think I'd better check with it to ensure my patch support korean too. Anyone know / has it? Could you send me a copy? I am Chinese, so now I only test my patch with Chinese input method. thanks liuspider __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Fwd: any one have korean XIM support patch?
hello everyone: I just working hard to improve / implement the XIM support in wine based on the work of Mike McCormack. His original patch support Japanese, thus I think mime will work with japanese too. While I heared that there was a patch for korean XIM support, I think I'd better check with it to ensure my patch support korean too. Anyone know / has it? Could you send me a copy? I am Chinese, so now I only test my patch with Chinese input method. thanks liuspider __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Wine conformance testing on native platforms
On December 12, 2002 10:22 am, Luke Stras wrote: It's a bunch of extra work, but what I'm thinking is this: for every platform, link back to the appropriate wine-devel message from the archives which contains the most recent test results. I was actually hoping the Francois monitors this reports, and keeps his nice page (http://fgouget.free.fr/wine/tests-en.shtml) up to date, which should be exactly what you need, and a lot nicer than looking at the raw reports. [1] Flight vibration test for my baby coming up on Friday! I'm expecting the worst. Good luck! What is it, BTW? -- Dimi.
NT conformance update
Changes in NT conformance test results from 2002/12/10 to 2002/12/11. Original test results are available at http://www.winehq.com/hypermail/wine-devel/2002/12/0423.html dsound_test: - new, passed successfully kernel32_test: - file.c:578 - DeleteFile test now passess successfully - path.c:568, 569, 591, 592, 656, 657 now pass - path.c:242 et. al - check?-? now pass - path.c:822-908 now pass msvcrt_test: - test 'msvcrt' does not exist any more I think that's everything a vgrep returns, anyways. I've put up the test results from both days, as well as a diff, up at: http://www.utias.toronto.edu/~stras/wine/ I will try to keep this updated regularly, as the available test suite changes. I'm too busy right not to compile my own tests, so I have to rely on Francois to compile tests for me. -- Luke Stras [EMAIL PROTECTED] The meek can have the Earth; the rest of us have other plans --Henry Spencer
Re: Wineboot
On December 11, 2002 03:51 pm, Shachar Shemesh wrote: I have vulenteered to do likewise. I have not, however, managed to get any statement from Andy regarding the current state, or any other replies. If he replies to this email, great. If not, I suggest we work on it together. I also did not get any response to my (potentially silly) proposal: http://www.winehq.com/hypermail/wine-devel/2002/11/0494.html -- Dimi.
Re: Wineboot
At 10.42 12/12/2002 -0500, you wrote: On December 11, 2002 03:51 pm, Shachar Shemesh wrote: I have vulenteered to do likewise. I have not, however, managed to get any statement from Andy regarding the current state, or any other replies. If he replies to this email, great. If not, I suggest we work on it together. I also did not get any response to my (potentially silly) proposal: http://www.winehq.com/hypermail/wine-devel/2002/11/0494.html Personally, I would still prefer an external utility, to mimic the case when the installer asks you do you want me to reboot now? and you say no, I'll do it later. In that case, I don't want to have file renamed, etc... until I decide it's time to perform a reboot (by invoking wineboot). So, in my opinion, the wine_need_reboot() function you name in that pseudo-code should return TRUE only after one of the reboot functions have been called (InitiateSystemShutdown, InitiateSystemShutdownEx, ExitWindowsEx). Alberto
Re: Wineboot
On December 12, 2002 11:16 am, Alberto Massari wrote: Personally, I would still prefer an external utility, to mimic the case when the installer asks you do you want me to reboot now? and you say no, I'll do it later. In that case, I don't want to have file renamed, etc... until I decide it's time to perform a reboot (by invoking wineboot). So, in my opinion, the wine_need_reboot() function you name in that pseudo-code should return TRUE only after one of the reboot functions have been called (InitiateSystemShutdown, InitiateSystemShutdownEx, ExitWindowsEx). Hmm, that message is a bit out of contest. It _is_ an external utility that does the reboot (it's the wineboot utility), the problem is when to invoke it. The reason I proposed to invoke it from the server rather than from the process is because: -- it seems that's the place that's equivalent to rebooting windows -- it avoids a bunch of nasty race conditions -- it is very simple So yeah, what you say does not conflict in any way with what I was proposing. Indeed, the wine_need_reboot() function should behave as you say. In fact, if we should exit the server of system shutdown for this to work as I see it... -- Dimi.
Re: Houston, we have a problem...
Francois Gouget [EMAIL PROTECTED] writes: Now I must say that I wonder why this was not done automatically. Shouldn't the .c.o dependency kick in automatically in tools/Makefile.in? Maybe you can solve this one? The depend: target doesn't depend on the tools, because that would slow things down a lot. makedep doesn't change often enough for this to be a real problem; and a make clean will fix it anyway. -- Alexandre Julliard [EMAIL PROTECTED]
Re: make checklink broken?
Greg Turner [EMAIL PROTECTED] writes: Am I missing something, or is make checklink broken? It seems only to run for a few directories now, whereas the rest show nothing to do. These days checklink only needs to run for dlls that have 16-bit files, the rest should be caught by the -z defs option. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Houston, we have a problem...
On December 12, 2002 11:38 am, Alexandre Julliard wrote: The depend: target doesn't depend on the tools, because that would slow things down a lot. makedep doesn't change often enough for this to be a real problem; and a make clean will fix it anyway. Speaking of makedep: we have this non-standard vs convention for include files, which is (1) potentially confusing, and (2) can cause problems in Winelib apps that have private headers that conflict with names of our headers. If I understand it correctly, the rationale is to be able to easily segregate the host system headers from the Win32 headers, as we don't want the former included in the dependencies for speed reasons (otherwise we would slow down make). But what about determining these are runtime. A simple stat in our include dir is fast, and should tell us whether we need to include the file in the dependencies or not. -- Dimi.
Re: Houston, we have a problem...
Dimitrie O. Paun [EMAIL PROTECTED] writes: Speaking of makedep: we have this non-standard vs convention for include files, which is (1) potentially confusing, and (2) can cause problems in Winelib apps that have private headers that conflict with names of our headers. This was changed a long time ago. The only difference now is that makedep complains if it cannot find a include and says nothing for a include, but otherwise they work just the same. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wine/tools mingwrap.c
On December 10, 2002 09:04 pm, Alexandre Julliard wrote: I think it's reasonable to require the user to specify an explicit include path if they install Wine in a non-standard directory. This shouldn't be a common case anyway. Well, this still does not work, because our msvcrt headers have includes like so: #include msvcrt/wctype.h and these fail miserably because msvcrt is not in the path. I think we should install msvcrt at the same level as wine (as in my original proposal), the chances of a conflict are virtually NULL. Either way, we need to fix this somehow. -- Dimi.
Re: Houston, we have a problem...
On December 12, 2002 12:51 pm, Alexandre Julliard wrote: This was changed a long time ago. The only difference now is that makedep complains if it cannot find a include and says nothing for a include, but otherwise they work just the same. In which case, shouldn't our includes use instead of ? Using is not 100% correct, let alone non standard. I know, minor point, but... :) -- Dimi.
Re: wine/tools mingwrap.c
Dimitrie O. Paun [EMAIL PROTECTED] writes: Either way, we need to fix this somehow. IMO our headers should be fixed, they shouldn't have the msvcrt prefix. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Wine conformance testing on native platforms
On Thu, 12 Dec 2002, Dimitrie O. Paun wrote: On December 12, 2002 10:22 am, Luke Stras wrote: It's a bunch of extra work, but what I'm thinking is this: for every platform, link back to the appropriate wine-devel message from the archives which contains the most recent test results. I was actually hoping the Francois monitors this reports, and keeps his nice page (http://fgouget.free.fr/wine/tests-en.shtml) up to date, which should be exactly what you need, and a lot nicer than looking at the raw reports. Yep, I'm trying to keep it up to date. It would be much less work if there were fewer errors btw (hint, hint). -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Lotto: A tax on people who are bad at math. -- unknown Windows: Microsoft's tax on computer illiterates. -- WE7U
Re: Houston, we have a problem...
Dimitrie O. Paun [EMAIL PROTECTED] writes: In which case, shouldn't our includes use instead of ? Using is not 100% correct, let alone non standard. I know, minor point, but... :) I guess they should, yes. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Houston, we have a problem...
On December 12, 2002 02:07 pm, Alexandre Julliard wrote: In which case, shouldn't our includes use instead of ? Using is not 100% correct, let alone non standard. I know, minor point, but... :) I guess they should, yes. A perfect job for a cool Perl script :) I haven't heard much from Patrik lately... g -- Dimi.
Re: wine/tools mingwrap.c
On December 12, 2002 02:07 pm, Alexandre Julliard wrote: IMO our headers should be fixed, they shouldn't have the msvcrt prefix. Fine. What about this: include/windows.h:#include msvcrt/excpt.h I have a patch removing the msvcrt/ prefix from the msvcrt/*.h files, but in Wine it's a bit tricky as we want to use some msvcrt, and libc. We can do this: #ifndef __WINE__ # include excpt.h #endif And in the Wine source where we need excpt.h we simply make sure we do #include msvcrt/excpt.h Comments? -- Dimi.
Re: Wineboot
On Thu, Dec 12, 2002 at 11:14:43AM -0500, Dimitrie O. Paun wrote: Hmm, that message is a bit out of contest. It _is_ an external utility that does the reboot (it's the wineboot utility), the problem is when to invoke it. Just wondering: Why is the reboot needed? Just because M$ does it or are there valid reasons for Wine to reboot as well? What are these reasons? Can they be fixed? Should they be fixed? Ciao Jörg -- Joerg Mayer [EMAIL PROTECTED] I found out that pro means instead of (as in proconsul). Now I know what proactive means.
Re: wine/tools mingwrap.c
Dimitrie O. Paun [EMAIL PROTECTED] writes: And in the Wine source where we need excpt.h we simply make sure we do #include msvcrt/excpt.h Comments? Actually there is no excpt.h in the standard unix includes, so it doesn't need to be in msvcrt/, it can be moved with the normal includes. -- Alexandre Julliard [EMAIL PROTECTED]
Re: wine/tools mingwrap.c
On December 12, 2002 03:24 pm, Alexandre Julliard wrote: Actually there is no excpt.h in the standard unix includes, so it doesn't need to be in msvcrt/, it can be moved with the normal includes. Do patch -p0 excpt.diff cp include/msvcrt/excpt.h include/excpt.h cvs rm -f include/msvcrt/excpt.h cvs add include/excpt.h ChangeLog Move excpt.h out of include/msvcrt/ as it does not conflict with any standard Unix header. Index: dlls/kernel/computername.c === RCS file: /var/cvs/wine/dlls/kernel/computername.c,v retrieving revision 1.4 diff -u -r1.4 computername.c --- dlls/kernel/computername.c 27 Nov 2002 21:38:06 - 1.4 +++ dlls/kernel/computername.c 12 Dec 2002 20:55:50 - @@ -38,7 +38,7 @@ #include winternl.h #include wine/unicode.h #include wine/exception.h -#include msvcrt/excpt.h +#include excpt.h #include wine/debug.h #include file.h Index: dlls/kernel/console.c === RCS file: /var/cvs/wine/dlls/kernel/console.c,v retrieving revision 1.11 diff -u -r1.11 console.c --- dlls/kernel/console.c 21 Nov 2002 23:45:31 - 1.11 +++ dlls/kernel/console.c 12 Dec 2002 20:55:50 - @@ -46,7 +46,7 @@ #include wine/exception.h #include wine/unicode.h #include wine/debug.h -#include msvcrt/excpt.h +#include excpt.h #include console_private.h WINE_DEFAULT_DEBUG_CHANNEL(console); Index: dlls/msvcrt/cppexcept.c === RCS file: /var/cvs/wine/dlls/msvcrt/cppexcept.c,v retrieving revision 1.4 diff -u -r1.4 cppexcept.c --- dlls/msvcrt/cppexcept.c 1 Nov 2002 01:50:51 - 1.4 +++ dlls/msvcrt/cppexcept.c 12 Dec 2002 21:03:34 - @@ -29,7 +29,7 @@ #include winternl.h #include msvcrt.h #include wine/exception.h -#include msvcrt/excpt.h +#include excpt.h #include wine/debug.h WINE_DEFAULT_DEBUG_CHANNEL(seh); Index: dlls/msvcrt/except.c === RCS file: /var/cvs/wine/dlls/msvcrt/except.c,v retrieving revision 1.22 diff -u -r1.22 except.c --- dlls/msvcrt/except.c1 Nov 2002 01:50:51 - 1.22 +++ dlls/msvcrt/except.c12 Dec 2002 21:03:21 - @@ -34,7 +34,7 @@ #include msvcrt.h #include msvcrt/setjmp.h -#include msvcrt/excpt.h +#include excpt.h #include wine/debug.h Index: dlls/ntdll/debugtools.c === RCS file: /var/cvs/wine/dlls/ntdll/debugtools.c,v retrieving revision 1.25 diff -u -r1.25 debugtools.c --- dlls/ntdll/debugtools.c 13 Nov 2002 19:38:17 - 1.25 +++ dlls/ntdll/debugtools.c 12 Dec 2002 20:55:51 - @@ -41,7 +41,7 @@ #include winbase.h #include winnt.h #include winternl.h -#include msvcrt/excpt.h +#include excpt.h WINE_DECLARE_DEBUG_CHANNEL(tid); Index: dlls/ntdll/exception.c === RCS file: /var/cvs/wine/dlls/ntdll/exception.c,v retrieving revision 1.50 diff -u -r1.50 exception.c --- dlls/ntdll/exception.c 10 Dec 2002 22:56:45 - 1.50 +++ dlls/ntdll/exception.c 12 Dec 2002 20:55:51 - @@ -33,7 +33,7 @@ #include miscemu.h #include wine/server.h #include wine/debug.h -#include msvcrt/excpt.h +#include excpt.h WINE_DEFAULT_DEBUG_CHANNEL(seh); Index: dlls/ntdll/loader.c === RCS file: /var/cvs/wine/dlls/ntdll/loader.c,v retrieving revision 1.7 diff -u -r1.7 loader.c --- dlls/ntdll/loader.c 12 Sep 2002 22:07:03 - 1.7 +++ dlls/ntdll/loader.c 12 Dec 2002 20:55:52 - @@ -22,7 +22,7 @@ #include module.h #include wine/exception.h -#include msvcrt/excpt.h +#include excpt.h #include wine/debug.h WINE_DEFAULT_DEBUG_CHANNEL(ntdll); Index: dlls/ntdll/sec.c === RCS file: /var/cvs/wine/dlls/ntdll/sec.c,v retrieving revision 1.31 diff -u -r1.31 sec.c --- dlls/ntdll/sec.c5 Dec 2002 19:56:16 - 1.31 +++ dlls/ntdll/sec.c12 Dec 2002 20:55:51 - @@ -42,7 +42,7 @@ #include winternl.h #include winreg.h #include ntdll_misc.h -#include msvcrt/excpt.h +#include excpt.h WINE_DEFAULT_DEBUG_CHANNEL(ntdll); Index: dlls/user/lstr.c === RCS file: /var/cvs/wine/dlls/user/lstr.c,v retrieving revision 1.24 diff -u -r1.24 lstr.c --- dlls/user/lstr.c15 Oct 2002 21:00:06 - 1.24 +++ dlls/user/lstr.c12 Dec 2002 20:55:54 - @@ -36,7 +36,7 @@ #include wine/winbase16.h #include wine/winuser16.h -#include msvcrt/excpt.h +#include excpt.h #include wine/debug.h Index: dlls/winedos/dosvm.c === RCS file: /var/cvs/wine/dlls/winedos/dosvm.c,v retrieving revision 1.31 diff -u -r1.31 dosvm.c --- dlls/winedos/dosvm.c
Obsolete APIs?
While checking the differences between the set of APIs exported by Windows dlls and the set of APIs exported by Wine's libraries I found some strange cases: * some APIs are exported on Windows 95 and/or NT4 but are not exported in more recent versions of Windows. For instance, GetRunTimes is exported by urlmon on Windows 95 and NT4, but there is no trace of it in Windows 98, Millenium, 2000 or XP. There is also no trace of it in the SDK headers. Some are exported only by NT4. What should I do with such APIs? Should I add them to Wine's spec files anyway? * Some APIs are exported at a specific ordinal in Windows 95, but are exported 'normally' in more recent versions of Windows. For instance, still in urlmon, on Windows 95 and NT4 I have: api95/urlmon-api.txt: 4 2D 00047D0B IsLoggingEnabledW apint4/urlmon-api.txt: 4 2D 00047E4A IsLoggingEnabledW Clearly the ordinal was manually specified since the ordinal of IsLoggingEnabledA is 46. However in the XP library these are exported in the usual alphabetical order: 49 30 000439E9 IsLoggingEnabledA 50 31 00043AC6 IsLoggingEnabledW Wine sides on XP for this one. Should we not care (after all Microsoft doesn't), or should we try to match the Windows 95 ordinal? I would vote for the second otherwise scripts diffing the export lists will complain about the difference every time we run them. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Good judgment comes from experience, and experience comes from bad judgment -- Barry LePatner
Re: wine/tools mingwrap.c
On 12 Dec 2002, Alexandre Julliard wrote: [...] Actually there is no excpt.h in the standard unix includes, so it doesn't need to be in msvcrt/, it can be moved with the normal includes. I'm not sure it's a good idea to mix the MSVCRT headers with the others. Sure there is no excpt.h header in the standard Unix headers. But there are many headers we cannot move: malloc.h, stdlib.h, string.h, etc. So we'll end up with some headers (conio.h, crtdbg.h, io.h) mixed in with the regular Wine headers, and some others which will be kept separate. Then there is the case of headers such as direct.h that exist on some Unix platforms and not on others. Then, what happens if a header similar to excpt.h includes a header such as stdlib.h. It will only work with msvcrt's stdlib.h thus causing trouble if the user is using the regular C library headers instead. So I'm not convinved that moving excpt.h is any better or cleaner than leaving it in the msvcrt directory. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Lotto: A tax on people who are bad at math. -- unknown Windows: Microsoft's tax on computer illiterates. -- WE7U
Re: wine/tools mingwrap.c
Francois Gouget [EMAIL PROTECTED] writes: Then, what happens if a header similar to excpt.h includes a header such as stdlib.h. It will only work with msvcrt's stdlib.h thus causing trouble if the user is using the regular C library headers instead. I don't see why it would only work with msvcrt, and if so it should be fixed. People should be able to choose between using the msvcrt headers or the standard Unix ones; if headers that don't exist on Unix are in msvcrt it forces everybody to use msvcrt headers. Now there may well be Windows-only headers like io.h that don't make sense outside of msvcrt, but I certainly don't see any reason to not use excpt.h along with the Unix headers. -- Alexandre Julliard [EMAIL PROTECTED]
Re: Wineboot
At 21.16 12/12/2002 +0100, Joerg Mayer wrote: On Thu, Dec 12, 2002 at 11:14:43AM -0500, Dimitrie O. Paun wrote: Hmm, that message is a bit out of contest. It _is_ an external utility that does the reboot (it's the wineboot utility), the problem is when to invoke it. Just wondering: Why is the reboot needed? Just because M$ does it or are there valid reasons for Wine to reboot as well? What are these reasons? Can they be fixed? Should they be fixed? The reboot in question is not the reboot of the Linux machine, it should be a command that executes the operation done by Windows upon startup. The need comes from APIs like MoveFileEx (when a special flag is used to say move or delete this file when the system starts, so I am sure this file is not in use), and from registry settings like Run and RunOnce. Ciao, Alberto Ciao Jörg -- Joerg Mayer [EMAIL PROTECTED] I found out that pro means instead of (as in proconsul). Now I know what proactive means.
Re: Cross-compiling the tests with MinGW
Francois Gouget wrote: Changelog: * documentation/testing.sgml Document how to cross-compile the tests with MinGW When I get the time I will submit mingw on Windows documentation. Could be a few more weeks. Thanks Steven
RE: Houston, we have a problem...
On December 12, 2002 02:07 pm, Alexandre Julliard wrote: In which case, shouldn't our includes use instead of ? Using is not 100% correct, let alone non standard. I know, minor point, but... :) I guess they should, yes. A perfect job for a cool Perl script :) Sure. Will try to look at in the next few days. I haven't heard much from Patrik lately... g You will here more from me soon. I'm going to have a long vacation around christmas where I will have much more time to work with Wine. Of course family and friends usually takes up more time than usual around christmas as well...
Re: wine/ tools/winebuild/winebuild.man.in tools/w ...
On Thursday 12 December 2002 10:34 am, Alexandre Julliard wrote: Dimitrie O. Paun [EMAIL PROTECTED] writes: Alexandre, mind if you explain in a few words the rationale for this one? Not that I have a problem with it, but I like to know where you're going... :) This is for import libraries; basically the import libs (actually the .def files) need to contain all functions, even the ones we don't want to import from ELF libraries, because the same files are used for the Windows libraries. So the check is now done at the time we import the library, not at the time we generate the import lib. Wow, it's like a whole new wine now! This wave of changes seems to be going over my head a bit, and your explanation doesn't seem to clear the fog for me... perhaps it's time I read some of the scary parts of the wine source and got a clue about how the wine compile/link/load sequence actually works? (I should note that, so far, ignorance of these parts of wine has been fine for me; presumably, this wave of changes doesn't make such knowledge any more necessary, but it does pique my curiosity.) For those of us who still don't get it, could you provide a bit more explanation here? (i.e.: as if to a child ;) ) By the above, do you mean, in some sense, that some symbols get resolved at run-time instead of at compile time? What are the expected consequences/benefits of this change? I'm sure it's all quite evident to you and the other old-timers around here, so sorry to be slow! Also, if I'm asking you to write a novel, just let me know what I need to read up on. Thanks!! -- gmt
Re: POSE (Palm OS Emulator) on WINE?
Hi Sylvain, thanks for your reply! Since this is a special case for sure, I'm really grateful. It runs on Linux, source is availble on their web site. (see the first link) Yes, that's correct for the 'standard' POSE, I've got it up and running since long. The problem is that _SONY_ doesn't provide their extensions for any other system but Windows. Their source tree has neither SrcUnix nor BuildUnix branches :-( And folks, please forgive me that I extent my call for help: the new simulator for PalmOS 5 does not work, too... :-} Cheers, Bodo
Re: Wineboot
Joerg Mayer wrote: On Thu, Dec 12, 2002 at 11:14:43AM -0500, Dimitrie O. Paun wrote: Hmm, that message is a bit out of contest. It _is_ an external utility that does the reboot (it's the wineboot utility), the problem is when to invoke it. Just wondering: Why is the reboot needed? Just because M$ does it or are there valid reasons for Wine to reboot as well? What are these reasons? In a nutshell - some operations are delayed until reboot due to file locks, running processes, services and drivers, and a host of other reasons. The reasons you don't see such things in Unix are: a. Seperate functionality is better seperated into seperate process, thus making restarting a specific aspect of the system easier. b. Files are never locked, and therefor can always be replaced. Can they be fixed? Maybe. That's a pretty serious question and one for two minor startups. Should they be fixed? I don't think so. Wine restart is far less painful than a Windows restart. Sometime in the future, maybe. Ciao Jörg -- Joerg Mayer [EMAIL PROTECTED] I found out that pro means instead of (as in proconsul). Now I know what proactive means.
Key capturing and dxgrab
If you run with dxgrab on and a game is fullscreen or in a wine desktop window the mouse is stuck there, even though some keystokes can get passed into the window manager and focus can be lost. I was thinking that a solution to this would be to enable dxgrab when the wine window was given focus and to disable dxgrab when the user wanted to change focus using alt-tab(seems like a natural default key combination). This would allow a dxgrab window in a wine desktop window but also let the desktop be useable for other things without requiring the app to be closed before mouse control was returned. Where in wine would should they keystroke interception be perfomed? Does such functionality already exist through windows api calls(I wasn't able to find much info on the web through a google search)? Thanks, Chris
Re: Win2000 Conformance Test Results...
Hmmm, I meant to send this two days ago... On Tue, 10 Dec 2002, David Fraser wrote: [...] for kernel32_test path, I got this additional error (before all the others) I have made tons of fixes to the kernel/path test and it should now work much better. I just uploaded the new version of the tests compiled from my sources. One can download them from the usual URL: http://fgouget.free.fr/wine/winetests.zip [...] process: 116 tests executed, 0 marked as todo, 4 failures. Exactly the same except I have 10 messages interspersed with these, saying: tests/process.c: 1 tests executed, 0 marked as todo, 0 failures. Why these extra messages? Because this executable invokes itself to test CreateProcess. And each time it exits it prints statistics about how many tests passed and failed, although the child processes are not actually performing any test. So these messages can be ignored. h:\wine\wine\dlls\shlwapi\tests\shreg.c:218: Test failed: (6) h:\wine\wine\dlls\shlwapi\tests\shreg.c:219: Test failed: (6,43) h:\wine\wine\dlls\shlwapi\tests\shreg.c:220: Test failed: (3435973836) [...] Same but I get 0 for all your 3435973836 which is 0x. Must be a debug/release build thing - variable not being initialized. Should not be the case. The code does: dwType = -1; dwRet = SHQueryValueExA( hKey, Test3, NULL, dwType, NULL, dwSize); ok( dwType == REG_SZ, (%lu) , dwType); So we should either get -1 or something that makes sense, not 0x. This needs to be investigated more. Should we print out some of these results in hex as well to make life easier? We should print them in just one format, decimal or hex, whichever makes more sense. I will now be concentrating on working out what is wrong with these tests :) Yep, I think this is priority number one now. Running the tests on more platforms would only return pretty much the same list of bugs again and again. -- Francois Gouget [EMAIL PROTECTED]http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy
Prototype implementation of a shared memory winserver
Hi, in the quest for speed parity in multimedia applications TransGaming has investigated a few options in dealing with the nasty overhead of the present wineserver implementation. I have just recently posted a prototype patch for a shared memory wineserver, to the ReWind project, (http://sourceforge.net/mailarchive/forum.php?thread_id=1413925forum_id=8836) which, in a small benchmarking suite, has shown some remarkable performance gains. The concept for the shm wineserver came about during discussions at the OLS in 2002 and remained a concept until a little while ago we had enough time to create a working prototype. TransGaming is donating this code to the ReWind project in the hopes that it will encourage other Wine developers to continue to share code under the more open BSD/X11 style license and to help overcome the remaining issues with this approach. Rather than make a really long technical email, we decided that a bit of a paper would be more appropriate (it also has links to the patches). The paper can be found at http://www.transgaming.com/papers/shmserver.html Regards, Peter Hunnisett [EMAIL PROTECTED]
WinME conformance tests - 12 Dec 02
From Kevin Podgursky [EMAIL PROTECTED] Compared to http://fgouget.free.fr/wine/tests-en.shtmlDec 12, 02 Advapi32/registry - crashed - last messages in terminal:registry.c:123: Test failed: type 2 is not REG_SZregistry.c:134: Test failed: expected ERROR_SUCCESS, got 234registry.c:135: Test failed: val_count set to 20 instead of 4registry.c:136: Test failed: data_count set to 24 instead of 7registry.c:137: Test failed: type 2 is not REG_SZregistry.c:138: Test failed: value is 'xx' instead of Testregistry.c:139: Test failed: data is 'xx' instead of foobarregistry.c:153: Test failed: expected ERROR_MORE_DATA, got 0registry.c:155: Test failed: data_count set to 2 instead of 7*sizeof(WCHAR)registry.c:156: Test failed: type 1234 is not REG_SZregistry.c:167: Test failed: expected ERROR_MORE_DATA, got 0registry.c:169: Test failed: data_count set to 20 instead of 7*sizeof(WCHAR)registry.c:170: Test failed: type 1234 is not REG_SZregistry.c:181: Test failed: expected ERROR_MORE_DATA, got 0registry.c:182: Test failed: val_count set to 20 instead of 4registry.c:183: Test failed: data_count set to 2 instead of 7*sizeof(WCHAR)registry.c:184: Test failed: type 1234 is not REG_SZregistry.c:185: Test failed: value is not 'Test'registry.c:196: Test failed: val_count set to 20 instead of 4registry.c:197: Test failed: data_count set to 20 instead of 7*sizeof(WCHAR)registry.c:198: Test failed: type 1234 is not REG_SZregistry.c:199: Test failed: value is not 'Test'registry.c:200: Test failed: data is not 'foobar' dsound/dsound passed kernel/alloc - same results as for Win95 kernel/atomF:\Tempkernel32_test.exe atom - hmm does this mean passed or unsupported?atom.c:55:WARNING: Unicode atom APIs are not supported on this platformatom: 163850 tests executed, 0 marked as todo, 0 failures. kernel/codepageF:\Tempkernel32_test.exe codepagecodepage.c:40: Test failed: any negative value should work as strlen() + 1codepage: 2 tests executed, 0 marked as todo, 1 failure. kernel/directory - passed kernel/drive - passed kernel/environ - passed kernel/file - same comments as Win95 - line numbers differentF:\Tempkernel32_test.exe filefile.c:631: Test failed: WriteFile error 183file.c:632: Test failed: expected number of bytes written 0file.c:633:Current offset = 0100file.c:634: Test failed: expected file offset 21file.c:639: Test failed: WriteFile error 87file.c:640: Test failed: expected number of bytes written 0file.c:642: Test failed: expected file offset 517file.c:656: Test failed: ReadFile error 0file.c:657: Test failed: expected number of bytes read 0file.c:658:Current offset = file.c:659: Test failed: expected file offset 21file.c:661: Test failed: pattern match failedfile: 487224 tests executed, 0 marked as todo, 10 failures. kernel/format_msgSame as for Win95 kernel/generated - passed kernel/localeF:\Tempkernel32_test.exe localelocale.c:126: Test failed: GetTimeFormat with len=2 got xx¦¦ instead of AMxxlocale.c:181: Test failed: GetDateFormat got xx¦¦- instead of Saxxlocale.c:199: Test failed: GetDateFormatW allowed flags and formatlocale.c:205: Test failed: GetDateFormatW did not detect null buffer pointer.locale.c:208: Test failed: GetDateFormatW did not permit null buffer pointer when counting.locale.c:224: Test failed: Day of week correction failed locale.c:312: Test failed: GetNumberFormat with len=2 got xx¦¦W instead of 2,xxlocale.c:270: Test failed: GetCurrencyFormat got xx¦¦W instead of $23.53locale: 54 tests executed, 0 marked as todo, 8 failures. kernel/pathF:\Tempkernel32_test.exe pathpath.c:738: Test failed: GetLongPathNameA returned 'F:\shortdir\pathtest.pth' instead of 'C:\shortdir\pathtest.pth'path.c:889:TMP=F:\TEMPpath.c:900:TMP=C:\WINDOWSpath.c:910:TMP=C:\path.c:920:TMP=C:path: 1772 tests executed, 0 marked as todo, 1 failure. kernel/process - passed kernel/threadF:\Tempkernel32_test.exe threadthread.c:273: Test failed: SuspendThread did not obey access restrictionsthread.c:275: Test failed: ResumeThread did not obey access restrictionsthread.c:323: Test failed: TerminateThread did not obey access restrictionsthread.c:393: Test failed: SetThreadPriority did not obey access restrictionsthread.c:395: Test failed: GetThreadPriority did not obey access restrictionsthread.c:403: Test failed: GetExitCodeThread did not obey access restrictionsthread.c:430: Test failed: SetThreadPriorityBoost Failedthread.c:432: Test failed: GetThreadPriorityBoost Failedthread.c:434: Test failed: SetThreadPriorityBoost Failedthread.c:436: Test failed: GetThreadPriorityBoost Failedthread: 103 tests executed, 0 marked as todo, 10 failures. msvcrt/scanf - passed netapi32/access -crash with message boxThe NETAPI32_TEST.EXE file is
Re: wine/ tools/winebuild/winebuild.man.in tools/w ...
Greg Turner [EMAIL PROTECTED] writes: I'm sure it's all quite evident to you and the other old-timers around here, so sorry to be slow! Also, if I'm asking you to write a novel, just let me know what I need to read up on. Thanks!! The idea is to mimic the way import libraries work under Windows, so that's what you should look into. Basically the Microsoft linker doesn't know how to link directly against a dll, so to use a dll you have to link against a stub static library that contains just a list of the functions exported by the dll. Under Unix the linker knows how to link against the same .so files that the dynamic loader uses at run time, so there is no need for separate import libraries. The benefit of import libraries is that it reduces dependencies in the build process, because you can generate all the import libraries first and then build the dlls in the order you like, since they no longer depend on each other. This also allows circular dependencies between dlls, a misfeature that Microsoft uses unfortunately. The main drawback is of course that it's easy for the dll and its import library to get out of sync and then you are in trouble, because the functions that you found at link time in the import lib do not exist at load time in the actual dll. The Unix way of having a single library is much cleaner, but of course we don't expect Microsoft to do things the clean way g The actual implementation is a bit different between Windows and Wine: under Windows the import library has to be in the standard library file format that the linker understands (xxx.lib, or libxxx.a for gcc), and it is generated from the dll .def file. Under Wine we don't need a real library since everything is done inside winebuild without involving the Unix linker, so we use the .def file directly and skip the intermediate step of building a library object file. Hope this helps... -- Alexandre Julliard [EMAIL PROTECTED]
Re: wine/ tools/winebuild/winebuild.man.in tools/w ...
The actual implementation is a bit different between Windows and Wine: under Windows the import library has to be in the standard library file format that the linker understands (xxx.lib, or libxxx.a for gcc), and it is generated from the dll .def file. Under Wine we don't need a real library since everything is done inside winebuild without involving the Unix linker, so we use the .def file directly and skip the intermediate step of building a library object file. So are we going to move away from using the *.spec files at some point and just use def's by themselves? I dont think this would work because of the stubs functions and I'm sure there is more about the .spec system I dont understand. Thanks Steven __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: wine/ tools/winebuild/winebuild.man.in tools/w ...
Steven Edwards [EMAIL PROTECTED] writes: So are we going to move away from using the *.spec files at some point and just use def's by themselves? I dont think this would work because of the stubs functions and I'm sure there is more about the .spec system I dont understand. Right, it wouldn't work because of the stubs and the relay debugging support. What I'm thinking of doing at some point is to allow using a .def as alternative to a .spec, for cases where you don't need the extra features, like when porting an existing dll to Winelib. But for Wine itself we'll probably stick to .spec for the time being. -- Alexandre Julliard [EMAIL PROTECTED]
New Contributions / Donations page
Hello, The Contrib page at : http://www.winehq.com/about/index.php?contrib is in need of updating and I would like to do this :) I would like to split this page into two pages 1) Contributing to web maintenance, graphics, documentation, testing, bug triaging and coding. 2) Monetary or equipment donations Any one want to Volinteer to help do this ? Tom
Re: wine/ tools/winebuild/winebuild.man.in tools/w ...
wow, I got a novel after all! Thanks for the helpful info. On Thursday 12 December 2002 07:38 pm, Alexandre Julliard wrote: The main drawback is of course that it's easy for the dll and its import library to get out of sync and then you are in trouble, because the functions that you found at link time in the import lib do not exist at load time in the actual dll. The Unix way of having a single library is much cleaner, but of course we don't expect Microsoft to do things the clean way g perhaps not... but now I understand how somebody can link a win32 app and run it on all the pseudo-incompatible windows platforms. The actual implementation is a bit different between Windows and Wine: under Windows the import library has to be in the standard library file format that the linker understands (xxx.lib, or libxxx.a for gcc), and it is generated from the dll .def file. Under Wine we don't need a real library since everything is done inside winebuild without involving the Unix linker, so we use the .def file directly and skip the intermediate step of building a library object file. Hope this helps... Indeed it has, thanks. I'll definitely check out some of the source for this -- in particular, the parts that got patched recently, if only to skim and get the overall process memorized, so I don't feel like I'm breaking things everytime I touch the makefiles (and, of course, I will look into those .lib file's, which I've been ignoring for as long as I can remember ;) ) -- gmt
Re: Wineboot
Personally, I would still prefer an external utility, to mimic the case when the installer asks you do you want me to reboot now? and you say no, I'll do it later. In that case, I don't want to have file renamed, etc... until I decide it's time to perform a reboot (by invoking wineboot). So, in my opinion, the wine_need_reboot() function you name in that pseudo-code should return TRUE only after one of the reboot functions have been called (InitiateSystemShutdown, InitiateSystemShutdownEx, ExitWindowsEx). So yeah, what you say does not conflict in any way with what I was proposing. Indeed, the wine_need_reboot() function should behave as you say. In fact, if we should exit the server of system shutdown for this to work as I see it... If the reboot gets delayed and I just quit the program, is the reboot still called at wine exit? Or would it be better if wine checks on every start if there are things necessary to complete (copy files...)? Maybe already too late. bye Fabi
Re: wine/ tools/winebuild/winebuild.man.in tools/w ...
Alexandre Julliard wrote: Right, it wouldn't work because of the stubs and the relay debugging support. What I'm thinking of doing at some point is to allow using a .def as alternative to a .spec, for cases where you don't need the extra features, like when porting an existing dll to Winelib. But for Wine itself we'll probably stick to .spec for the time being. If wer'e on the subject, maybe we can enhance the stub files to contain, for each function, the versions of windows for which it is exported? Right now we have a slight anomality where even if we define the windows version as win95, we still export functions only available under Windows NT. Shachar
