Re: MSYS touch.exe timestamp resolution issue on Wine-1.6
On 2013-10-12 23:28, Alan W. Irwin wrote: > Under MSYS bash.exe if I use the touch command I only get 1-second > resolution when reading the results. > > bash.exe-3.1$ touch touch1.test touch2.test > bash.exe-3.1$ ls --full-time touch*.test > -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.0 -0700 touch1.test > -rw-r--r-- 1 wine 544 0 2013-10-12 13:57:58.0 -0700 touch2.test > > Would somebody be willing to make the above test for MSYS on > the Microsoft version of Windows (which I don't have access to) to see > if time stamps are being read with 1-second resolution as above. That test > should help distinguish whether this is a Wine issue or else an MSYS > issue. I tested this on Windows 7, with MSYS 1.0.18, and I get the exact same experience. ls --full-time has a one second resolution (on NTFS, I expect a two second resolution on FAT, at least for some FAT variations). > I have also done some tests with the MSYS find.exe and make.exe > commands, and in all cases touch2.test is not newer than touch1.text. > This can be an important issue for the make command where one-second > time resolution can potentially screw up file dependencies. > > If I use the equivalent Linux ls (and find and make) commands to read the > time stamps on the above files, then touch2.test is newer than touch1.text, > e.g., Same here if I use an equivalent Cygwin ls, i.e. the actual time stamps are more fine grained than MSYS is capable of detecting. > wine@raven> ls --full-time touch*.test > -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.39100 -0700 touch1.test > -rw-r--r-- 1 wine wine 0 2013-10-12 13:57:58.40800 -0700 touch2.test > > So I think this implies the MSYS touch.exe command is writing > high-resolution (i.e., millisecond) time stamps, and it is only > reading that high-resolution time stamp that seems to be an > issue for MSYS on Wine. Indeed. Since Cygwin has a different view, the situation should improve with MSYS 2. Cheers, Peter
Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine
On 2013-06-28 23:37, Hin-Tak Leung wrote: > --- On Fri, 28/6/13, Alan W. Irwin wrote: > > ... However, because of the Cygwin fork >> bug, Cygwin on >> Wine has largely been untested for the last three years so >> this could >> be a good opportunity to do such testing for the combination >> of Cygwin >> (with the fork fix) and recent Wine in case some Wine >> regression is >> discovered by such testing. > > what You really don't get it. setup.exe is simply *not* a necessity > for putting a cygwin installation under wine. There are many other ways of > installing cygwin into wine without running cygwin's installer. The easiest > is simply to copy the entire installed directory, plus importing a few > registry entries, from a genuine windows box which has cygwin on. > > (There are many people who bundles bits of cygwin with their software for > windows, for years; so if you are a full-time windows user, you might even > gain some bits of cygwin without knowing it, and without ever having seen the > official cygwin installer or even heard of it) . The problem is that even if > you manage to put it on, many part of cygwin don't work correctly under wine. > > Please don't confuse issues with running the official installer, and issues > with running the cygwin system (or part of) itself. You have been told *many > times*, in that thread, that setup.exe itself does not depend on cygwin, and > use no part of it. Running the official installer invokes child processes that do indeed require a functioning Cygwin DLL. I.e. post-install scripts (and pre- remove scripts, but we're talking about the initial install so that's out of scope). The registry entries you speak about are a thing of the past, if you are referring to mount points. Cheers, Peter
Re: [wine-devel] Re: Bug 24018 which appears to be a showstopper for running Cygwin on Wine
On 2013-06-29 18:33, Alan W. Irwin wrote: > Those have been mentioned before here, and I have looked at them. > Cygwin is a very large collection of software so the number of bugs > that are reported does not seem excessive to me, and for my personal > needs (building and testing software on the Cygwin platform) I will > only be using a subset of Cygwin so I may avoid encountering > some of these bugs. Furthermore, some of these bugs (e.g., > problems resizing a GUI) are not showstoppers, and most of them are > quite old. At the same time the latest Wine is far superior to > Wine-1.4 so some of those bugs may have just disappeared. I hope to > find out about the actual status of Cygwin on Wine > bugs once I can get setup.exe to work on Wine. I would like to point out that it seems that the current bug does not appear to be *in* setup.exe, but rather occurs when setup.exe runs a bash post-install script, where the bash.exe that interprets the script depends on cygwin1.dll. If my analysis is correct, the bug would occur also when duplicating the actions of setup.exe manually. You would have to also duplicate the actions of all post-install scripts, which is certainly more work and more error-prone than duplicating the download and unpacking of a few tarballs. Cheers, Peter
Re: configure --with-osmesa fails to link
On 24/08/12 18:17, Alexandre Julliard wrote:
libOSMesa should be built without shared-glapi, we can't use it
otherwise.
I rebuilt media-libs/mesa-8.1_rc1_pre20120814 without shared-glapi, but
even then I get link errors during configure. Seems to be a missing
dependency on C++ runtime.
I've had to resort to the attached hack to get configure for wine64 to
complete on Gentoo x64. I'm not submitting this as a patch, because I'm
not anywhere near sure whether this is the right way of actually solving
the underlying issue. Unfortunately, I can't configure wine32, even with
this hack, because the 32-bit packages for 64-bit Gentoo are supplied as
pre-compiled binaries and osmesa is disabled in those.
Can I build wine64 --with-osmesa and WoW wine32 --without-mesa and still
expect things to work?
Best regards,
Peter Urbanec
diff --git a/configure.ac b/configure.ac
index b0b37ea..0e3e8d4 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1145,7 +1145,10 @@ This probably prevents linking to OpenGL. Try deleting the file and restarting c
if test "$ac_cv_header_GL_osmesa_h" = "yes"
then
-WINE_CHECK_SONAME(OSMesa,glAccum,,,[$X_LIBS $X_PRE_LIBS $XLIB -lm $X_EXTRA_LIBS])
+osmesa_save_CC=$CC
+CC=$CXX
+WINE_CHECK_SONAME(OSMesa,OSMesaCreateContext,,,[-lpthread $X_LIBS $X_PRE_LIBS $XLIB -lm $X_EXTRA_LIBS])
+CC=$osmesa_save_CC
fi
WINE_NOTICE_WITH(osmesa,[test "x$ac_cv_lib_soname_OSMesa" = "x"],
[libOSMesa ${notice_platform}development files not found (or too old), OpenGL rendering in bitmaps won't be supported.])
configure --with-osmesa fails to link
I just turned on --with-osmesa and configure fails for me: checking for -lOSMesa... not found configure: error: libOSMesa development files not found (or too old), OpenGL rendering in bitmaps won't be supported. This is an error since --with-osmesa was requested config.log output would suggest that perhaps the test is being treated as C code, but libOSMesa needs to link with C++ libs. configure:9067: checking for -lOSMesa configure:9092: gcc -o conftest -g3 -feliminate-unused-debug-symbols -O0 -mtune=core2conftest.c -lOSMesa -lSM -lICE -lXext -lX11 -lm >&5 /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: undefined reference to `operator delete[](void*)' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: undefined reference to `operator new(unsigned long)' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: undefined reference to `_glapi_get_proc_address' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: undefined reference to `operator delete(void*)' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: undefined reference to `_glapi_get_dispatch_table_size' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: undefined reference to `operator new[](unsigned long)' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: undefined reference to `__cxa_pure_virtual' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: undefined reference to `__gxx_personality_v0' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: undefined reference to `_glapi_get_context' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: undefined reference to `vtable for __cxxabiv1::__class_type_info' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: undefined reference to `_glapi_add_dispatch' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: undefined reference to `_glapi_check_multithread' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: undefined reference to `_glapi_tls_Context' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: undefined reference to `_glapi_set_context' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: undefined reference to `_glapi_set_dispatch' /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/libOSMesa.so: undefined reference to `_glapi_tls_Dispatch' collect2: ld returned 1 exit status This is on Gentoo x64 with: media-libs/mesa-8.1_rc1_pre20120814 (classic egl g3dvl gallium llvm nptl osmesa shared-glapi vdpau xvmc -bindist -d3d -debug -gbm -gles1 -gles2 -kernel_FreeBSD -openvg -pax_kernel -pic -r600-llvm-compiler -selinux -video_cards_i915 -video_cards_i965 -video_cards_intel -video_cards_nouveau -video_cards_r100 -video_cards_r200 -video_cards_r300 -video_cards_r600 -video_cards_radeon -video_cards_radeonsi -video_cards_vmware -wayland -xa -xorg) sys-devel/gcc-4.6.3 (cxx fortran graphite mudflap multilib nls nptl openmp -altivec -bootstrap -build -doc -fixed-point -gcj -go -gtk -hardened -libssp -multislot -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla) Any suggestions as to how this could be fixed? My autoconf skills are no match for this problem :-( Thanks.
Re: [PATCH] po: Update Swedish translation.
Hi I have a few questions/comments/suggestions on/for the change in the Swedish translation. On -28163-01--10 20:59, Lauri Kenttä wrote: > #: comdlg32.rc:292 > -#, fuzzy > msgctxt "Luminance" > msgid "&Lum:" > -msgstr "&Lum:" > +msgstr "&Val:" Can you explain 'Val' here? I don't understand it. I would assume 'Luminance' to be translated to 'Luminans', so Lum as abbreviation makes sense to me. > #: ieframe.rc:78 > -#, fuzzy > msgid "Searching for %s" > -msgstr "Egenskaper för %s" > +msgstr "Söker för %s" "Söker efter" would probably be better. > #: shell32.rc:215 > -#, fuzzy > msgid "Common Files" > -msgstr "Kopierar filer..." > +msgstr "" Perhaps 'Delade Filer'? > #: cmd.rc:331 > -#, fuzzy > msgid "Verify is %1\n" > -msgstr "Verifiera blev %s\n" > +msgstr "Verifiera blev %1\n" I would use 'är', 'blev' is more 'became' than 'is'. > #: cmd.rc:335 > -#, fuzzy > msgid "Volume label (11 characters, for none)?" > -msgstr "Diskvolymens namn (11 karaktärer, tryck enter för inget)?" > +msgstr "Diskvolymens namn (11 karaktärer, tryck för inget)?" 'Karaktärer' is the other kind of characters, the word here is 'tecken'. > #: explorer.rc:29 > #, fuzzy > @@ -10042,9 +9949,8 @@ msgid "Usage: hostname\n" > msgstr "" > > #: hostname.rc:28 > -#, fuzzy > msgid "Error: Invalid option '%c'.\n" > -msgstr "Fel: ogiltigt nyckelnamn\n" > +msgstr "Fel: Ogiltigt val '%c'.\n" I'm not sure about 'val' here. To me 'val' reads more like 'selection' than 'option'. > #: net.rc:41 > msgid "There are no entries in the list.\n" > @@ -10215,14 +10110,12 @@ msgstr "" > "---\n" > > #: net.rc:43 > -#, fuzzy > msgid "%1 %2 %3 Open resources: %4!u!\n" > -msgstr "%s %s %s Öppna resurser: %lu\n" > +msgstr "%1 %1 %1 Öppna resurser: %4!u!\n" I suppose that should be %1 %2 %3. > #: regedit.rc:88 > -#, fuzzy > msgid "Modify Binary Data..." > -msgstr "Ändra binärt data" > +msgstr "Ändra binärt data..." 'binärdata' is one word. > #: taskkill.rc:31 > -#, fuzzy > msgid "Error: Option %1 expects a command line parameter.\n" > -msgstr "Fel: Valet %s kräver en kommandoradsparameter.\n" > +msgstr "Fel: Valet %1 kräver en kommandoradsparameter.\n" > > #: taskkill.rc:32 > msgid "Error: Options /im and /pid are mutually exclusive.\n" > msgstr "Fel: Valen /im och /pid kan inte användas tillsammans.\n" > Val again. I don't really have any better suggestion, but it sounds strange to me. > #: winecfg.rc:146 > -#, fuzzy > msgid "" > "Wine can mimic different Windows versions for each application. This tab is > " > "linked to the Libraries and Graphics tabs to allow you to change systemwide > " > "or per-application settings in those tabs as well." > msgstr "" > -"Wine kan imitera olika Windows-versioner för varje program. Den här fliken > " > +"Wine kan imitera olika Windows-versioner för varje program. Den här fliken " > "är länkad till flikarna Bibliotek och Grafik för att låta dig ändra " > "inställningar i de flikarna också, antingen systembreda eller per program." > I believe 'systemövergripande' would be better than 'systembreda'. > > #: winecfg.rc:83 > -#, fuzzy > msgid "Audio test failed!" > -msgstr "Återställning av hårddisk misslyckades\n" > +msgstr "" Maybe "Ljudtest misslyckades!" ? > > #: winecfg.rc:85 > -#, fuzzy > msgid "(System default)" > -msgstr "Systemsökväg" > +msgstr "" Maybe "(Systemstandard)" ? > #: winefile.rc:197 > msgctxt "accelerator Fullscreen" > @@ -13528,9 +13355,8 @@ msgid "Error while selecting new font." > msgstr "Ett fel uppstod när ett nytt teckensnitt valdes." > > #: winefile.rc:95 > -#, fuzzy > msgid "Wine File Manager" > -msgstr "Winefile" > +msgstr "Wine Filhanteraren" "Wine Filhanterare", unless we want definite form "The Wine File Manager". > #: wordpad.rc:188 > -#, fuzzy > msgid "OLE storage documents are not supported." > -msgstr "Utökade attribut ej stödda\n" > +msgstr "" Maybe "OLE lagringsdokument stöds ej." ? //Jan-Peter
Re: [PATCH 2/3] winecoreaudio: Implement the lock-free callback design.
joerg-cyril.hoe...@t-systems.com skrev 2012-01-31 15:23: > Peter Rosin wrote: >>> Of the same vein, one liners like >>> EnterCS >>> This-> playing = StateStopped; >>> LeaveCS >>> are suspicious too. What does that guarantee? >> Perhaps that another thread doing as below isn't fooled into >> calling both one() and three()? > Right. The next question is: > What does that not guarantee (that you'd like to have)? It does not guarantee that I have money in my pocket. Seriously, I'm not sure in what way I'm supposed to not get what a CS does or doesn't do. Please spell it out! Cheers, Peter
Re: [PATCH 2/3] winecoreaudio: Implement the lock-free callback design.
joerg-cyril.hoe...@t-systems.com skrev 2012-01-30 18:30:
> Of the same vein, one liners like
> EnterCS
> This-> playing = StateStopped;
> LeaveCS
> are suspicious too. What does that guarantee?
Perhaps that another thread doing as below isn't fooled into
calling both one() and three()?
EnterCS
if (This-> playing == StateRunning) {
one();
}
two();
if (This-> playing == StateStopped) {
three();
}
LeaveCS
I don't know whether, or not, that has any bearing what-so-ever on
the patch under discussion...
Cheers,
Peter
Quick Question
Hi, Quick question, might be silly, but is there a version of Wine that can be installed on windows or linux to create apps for Mac? I just want to keep my mac clean and try run things in a dev environment, and apple are always so polite to make visualization a pain… Thank you very much for you help, Kind Regards, Peter Wilson
Separate list for bots
wine-devel has been seeing more and more robot generated messages. Would it make sense to create wine-bots list for buildbot, testbot and friends? Automated messages could go to author, wine-bots with Reply-To: and Followup-To: pointing at wine-devel That way wine-devel could be returned to humans again. :-)
Re: Where is the best place to report a fscanf bug found under wine-1.3.27?
Den 2011-08-30 20:18 skrev David Laight: > On Mon, Aug 29, 2011 at 06:43:41PM -0700, Alan W. Irwin wrote: >> double x; >> while(fscanf(stdin, " %le ", &x) == 1) > > You are using the wrong format, %le is for 'long double', this will > probably overwrite too much data. Nope, you are mistaken and the OP is correct. %e float %le double %Le long double Cheers, Peter
__CxxFrameHandler unsupported on wine64?
I have an application that requires MFC80.DLL. When I install only the MFC80.DLL file from the vcredist package, I end up with the following errors: wine: Call from 0x7fd606a3148b to unimplemented function MSVCR80.dll.__CxxFrameHandler, aborting So, I had a quick look at the wine source and found a comment in dlls/msvcrt/cppexcept.c that says: /* CxxFrameHandler is not supported on non-i386 */ I don't think that this is quite right, given that Microsoft's MFC80.DLL attempts to call __CxxFrameHandler. Is it more likely that wine only provides an i386 implementation? If so, is there any chance that someone may be able to provide x86_64 implementation in the near future? It's way over my head :-( Best regards, Peter Urbanec
Re: winex11.drv: Ensure that wintab xinput_handle is not NULL.
On 01/03/11 17:13, John Klehm wrote: Nice find on this code path being able to run without loading xinput. It was as a result of a user sending me some crash logs. I never managed to reproduce this issue. I don't even have access to a tablet to test. My patch was pretty much a result of "NULL pointers seen in the wild -> better check for them" reaction. In short GetCurrentPacket won't get called if xinput isn't loaded so I don't believe it needs the xinput check. Fair enough, I can remove that check and resend the patch. As for the AttachEventQueue and WTInfoW checks: I think we'd achieve the same end by having a loaded check in WTOpen just like we do in WTInfo. The benefit would be that we'd let the app know sooner that something was wrong. As it is right now we try to load but don't return 0 if we fail to load in dll/wintab32/context.c:WTInfoT: 370 if (gLoaded == FALSE) 371 LoadTablet(); 372 If we return 0 when loading fails in the dll/wintab32 WTInfo and WTOpen entry points we save the trouble of running through a bunch of function calls that are doomed to fail anyway. Even worse in most places in the wintab code we don't check if the winex11 calls succeed or fail. This would require modifications to LoadTablet and its winex11 buddy LoadTabletInfo so they could bubble up the failure. Sounds good. I'll get that done, but my testing is going to be limited due to the fact that I actually don't have a tablet to test with.
Why am I getting create_view out of memory?
I've got a heavily multithreaded 64-bit app that uses a lot of memory. After a while, I see this: fixme:virtual:create_view out of memory in virtual heap for 0x7f94465b-0x7f94466d6000 fixme:virtual:create_view out of memory in virtual heap for 0x7f944664-0x7f94466d3000 fixme:virtual:create_view out of memory in virtual heap for 0x7f944669-0x7f94466da000 fixme:virtual:create_view out of memory in virtual heap for 0x7f94466b-0x7f94466d5000 Could someone please explain to me what's going on here? Quick look at the code indicates that there is a 4MB heap used for "views" (I have no idea what these are) and presumably that heap is exhausted. Is this likely a resource leak somewhere? Some memory stats on the app I'm running: Process: PeakVirtualSize3f2baf000, VirtualSize 3eccd PeakWorkingSetSize 3762d6000, WorkingSetSize 3689ac000 PeakPagefileUsage 3f2baf000, PagefileUsage3eccd Global: TotalPhys 3eb4f2000, AvailPhys 0c4d8000 TotalPageFile 66b984000, AvailPageFile1733eb000 TotalVirtual7ffd, AvailVirtual 7ffc1330 Cheers, Peter Urbanec
Re: [3/3] comctl32/tests: Add a statusbar test for setting number of parts to zero.
On 26/02/11 04:12, Marvin wrote: http://testbot.winehq.org/JobDetails.pl?Key=9486 === W7PROX64 (64 bit status) === status.c:412: Test failed: Expected 1, got 0 Please ignore all 3 patches in the set. I will investigate Win behaviour a little closer and resubmit the patches once I learn more.
Re: gdi32: Fix 64-bit pointer issues when copying upside-down bitmaps.
On 26/02/11 00:05, Marcus Meissner wrote:
diff --git a/dlls/gdi32/dib.c b/dlls/gdi32/dib.c
index 0619304..595eb9b 100644
--- a/dlls/gdi32/dib.c
+++ b/dlls/gdi32/dib.c
@@ -885,7 +885,7 @@ INT WINAPI GetDIBits(
*/
if (bmp->dib->dsBmih.biHeight< 0)
{
-sbits += (srcwidthb * (abs(bmp->dib->dsBmih.biHeight) - 2 *
startscan - 1));
+sbits += (srcwidthb * (LONG)(abs(bmp->dib->dsBmih.biHeight) -
2 * startscan - 1));
Please enlighten us to the problem you are fixing? I see no 64bit pointer
relation...?
When running gdi32_test bitmap on Gentoo64, I see:
Unhandled exception: page fault on read access to 0x10024 in 64-bit
code (0x7f7f8a708530).
Backtrace:
=>0 0x7f7f8a708530 in libc.so.6 (+0x127530) (0x0022f9b0)
1 0x7f7f88b607c4 GetDIBits+0x11f9(hdc=0x25c, hbitmap=0x750,
startscan=0x1, lines=0x1, bits=0x22fa1c, info=0x22fa20, coloruse=0)
[/home/eyeon/source/wine/dlls/gdi32/dib.c:914] in gdi32 (0x0022f9b0)
2 0x7f7f891face5
test_GetDIBits_single_pixel_destination+0x2d2(bpp=0x10)
[/home/eyeon/source/wine/dlls/gdi32/tests/bitmap.c:3026] in gdi32_test
(0x0022f9b0)
3 0x7f7f891fb123 func_bitmap+0xc2()
[/home/eyeon/source/wine/dlls/gdi32/tests/bitmap.c:3082] in gdi32_test
(0x0022f9b0)
A little more tracing revealed that the above line without the (LONG)
cast turned sbits from 0x240004 to 0x10024, which in turn caused the
page fault in memcpy(). With the (LONG) cast in place, I see sbits
changing from 0x240004 to 0x24, as expected.
Using gcc (Gentoo 4.5.2 p1.0, pie-0.4.5) 4.5.2 with -O0
The addition of the cast fixes the issue and allows the winetest to succeed.
Cheers,
Peter Urbanec
wine64 issues in dlls/msvcr90/tests/msvcr90.c
As of a few days ago, I'm seeing the following errors when building wine64 with gcc (Gentoo 4.5.2 p1.0, pie-0.4.5) 4.5.2 dlls/msvcr90/tests/msvcr90.c:137:14: warning: 'do_call_func1' defined but not used dlls/msvcr90/tests/msvcr90.c:147:14: warning: 'do_call_func2' defined but not used dlls/msvcr90/tests/msvcr90.c: Assembler messages: dlls/msvcr90/tests/msvcr90.c:150: Error: invalid instruction suffix for `push' When building wine32, there seem to be no problems. Is anyone else seeing this when building wine64?
Re: gdi32/tests: Use virtual screen size instead of primary monitor screen size.
On 08/02/11 16:02, Marvin wrote: Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=9028 Your paranoid android. === WNT4WSSP6 (32 bit clipping) === clipping.c:438: Test failed: expected 0,0-0,0, got 0,0-800,600 It seems that GetSystemMetrics(SM_CXVIRTUALSCREEN) is supported on Win2k and later, but not on NT4. Presumably, on an NT4 system, the test could use GetSystemMetrics(SM_CXSCREEN) and it would work as long as there is only one monitor. What's the proper incantation I need to use to detect NT4 and execute platform specific test code?
Re: loader: Build the preloader for ARM
Den 2011-02-04 20:36 skrev Peter Rosin:
> Den 2011-02-04 17:41 skrev André Hentschel:
>> % and / both lead to external dependencies here...
>> maybe the euclidean algorithm helps, because -Os would need ugly changes to
>> configure i guess.
>>
>
> Finding gcd is a bit over the top...
>
> How about something like the following?
>
> Cheers,
> Peter
>
> unsigned int wld_modulo( const unsigned int a, const Elf32_Word b )
> {
> #ifdef __ARM_EABI__
> unsigned int r = 0;
> int i;
>
> for (i = sizeof(a) * 8 - 1; i >= 0; --i) {
> r <<= 1;
> if (a & (1U << i))
> r |= 1;
> if (r > b)
Ooops, bug. Should be "if (r >= b)"
> r -= b;
> }
>
> return r;
> ...
>
>
Cheers,
Peter
Re: loader: Build the preloader for ARM
Den 2011-02-04 17:41 skrev André Hentschel:
> Am 04.02.2011 17:26, schrieb Marcus Meissner:
>> On Fri, Feb 04, 2011 at 04:51:46PM +0100, André Hentschel wrote:
>>> Am 04.02.2011 16:31, schrieb Alexandre Julliard:
>>>> André Hentschel writes:
>>>>
>>>>> +unsigned int wld_modulo( const unsigned int a, const Elf32_Word b )
>>>>> +{
>>>>> +#ifdef __ARM_EABI__
>>>>> +unsigned int i;
>>>>> +if(b > a) return a;
>>>>> +for(i = 0; i * b < a + b; i++)
>>>>> +if(i * b > a - b) return (a - i * b);
>>>>> +return 0;
>>>>
>>>> That's very inefficient, there are better ways...
>>>>
>>>
>>> Thanks for having a look at it.
>>> The Problem is that i also can't use '/', otherwise it wants to link to
>>> __aeabi_uidiv .
>>> That leads to some Problems, so i'll try to find some better math solution
>>> and if that fails i maybe try it the assembler way...
>>
>> modulo would be "%" btw,
>>
>> return a%b;
>>
>> but this might generate external functions too... hmm, try -Os as option?
>>
>> Ciao, Marcus
>
> % and / both lead to external dependencies here...
> maybe the euclidean algorithm helps, because -Os would need ugly changes to
> configure i guess.
>
Finding gcd is a bit over the top...
How about something like the following?
Cheers,
Peter
unsigned int wld_modulo( const unsigned int a, const Elf32_Word b )
{
#ifdef __ARM_EABI__
unsigned int r = 0;
int i;
for (i = sizeof(a) * 8 - 1; i >= 0; --i) {
r <<= 1;
if (a & (1U << i))
r |= 1;
if (r > b)
r -= b;
}
return r;
...
Re: user32/gdi32: Fix for a crash in create_alpha_bitmap()
Hi Alexandre,
On Mon, 31 Jan 2011, Alexandre Julliard wrote:
And: from a design perspective it sounds very strange that a fast
track optimisation *silently* changes protection bits!
There's nothing silent about it, the protection bits have to match the
DIB state.
Hmm. In which way changes StretchDIBits() the DIB state? Or: why should
be a DIB, that is created using CreateDIBSection() as READWRITE,
silently change it's state into READONLY? (At least, msdn-docs don't
tell me anything about that... Can you provide me with a link? )
But, let's say for a moment, that this is true and the right(tm)
behaviour:
Then create_alpha_bitmap() (within user32/cursoricon.c) seems to be broken.
It does the following:
* create a DIBSection
alpha = CreateDIBSection( hdc, info, DIB_RGB_COLORS, &bits, NULL, 0)
* here we can savely expect bits to be writable (at least the
msdn-documentation says so)
* in certain cases (if we are provided with a src_info-pointer), we do
now:
StretchDIBits( hdc, 0, 0, bm.bmWidth, bm.bmHeight,
0, 0, src_info->bmiHeader.biWidth,
src_info->bmiHeader.biHeight,
color_bits, src_info, DIB_RGB_COLORS, SRCCOPY );
* after that, bits is *probably* non-writable (depending on fast path or
not) (I still find that *really* strange. Again: it depends on certain
parameters of this function, specifically: if in and out parameters do
match at enough places, the DIB bitmap *changes* it's state to
READONLY, in other cases it doesn't. If that isn't a big surprise, what
is? :) ).
* and here...
/* pre-multiply by alpha */
for (i = 0, ptr = bits; i < bm.bmWidth * bm.bmHeight; i++, ptr += 4)
{
unsigned int alpha = ptr[3];
ptr[0] = ptr[0] * alpha / 255;
ptr[1] = ptr[1] * alpha / 255;
ptr[2] = ptr[2] * alpha / 255;
}
* ... we write to the now readonly bits-array, which leads to a page
fault.
This is everything within wine code, the application only called
CreateIconFromResourceEx(), which then called create_alpha_bitmap() (so:
no, I don't think, the app is broken :) It only triggered a seldomly used
code path within wine. ).
Where is the page fault handler within wine and what should the page
fault handler actually do in that situation?
If we can't expect the "bits"-pointer to be writable after a call to
StretchDIBs(), create_alpha_bitmap() should be rewritten.
That wouldn't be a problem, if windows behaved exactly the same way.
(which it most likely does not, otherwise PNClient wouldn't crash,
right?).
I wouldn't be surprised if there was a way to crash it on Windows too,
that app is broken, it never gives the code a chance to handle the
exception. This is not how exception handlers are supposed to work.
Well, it doesn't crash on Windows and is actually rock solid there.
And: do you want to say, that there is a page fault handler within
wine, that can handle *that* case above?
We either have to rewrite create_alpha_bitmap() in a way, that doesn't
call StretchDIBits() in the fast path case and solves problems
differently or: we should fix it at the source (which I still think my
patch does, since it follows the rules of least surprise...).
In either way, I hope we can agree on the following:
a) the app is *not* broken (at least not regarding it's usage of
CreateIconFromResourceEx() )
b) wine code *is* broken here
c) we can work around the problem within create_alpha_bitmap() or
d) make StretchDIBits() a function a lot less surprising to call...
Of course this specific issue would be fixed by a DIB engine, but there are
other places where exceptions can happen internally, even on Windows.
At least, they seem to install the handler in such a clever way, that
no problems seem to occur within Windows (several different versions).
That said: I'd have prefered, if they didn't do that, since it made my
debugging session a lot longer...
Are you sure? 0 means: everything is transparent, and that sounds
like: we need an alpha channel, right?
0 means there's no alpha channel, which is what we are checking here.
Ouch! If that is really Windows behaviour, then it is really broken but
bug-to-bug compatible :)
Cheers,
Peter
Peter Schlaile
Re: user32/gdi32: Fix for a crash in create_alpha_bitmap()
Hi Alexandre, On Mon, 31 Jan 2011, Alexandre Julliard wrote: Peter Schlaile writes: Fix: X11DRV_SetDIBits() shouldn't silently change Bitmap protection, so we now restore the protection bits, that were present before instead of always changing to READONLY. No, it needs to be read-only so that we can detect further changes. so: what is your proposal to fix the problem? At least, wine reacts very differently than windows here :) Read: it crashes the application I mentioned in my previous mail: http://www.phononet.de/downloads/support/downloads/Aktueller_PNClient/PNCLIENT1.9.zip And: from a design perspective it sounds very strange that a fast track optimisation *silently* changes protection bits! That wouldn't be a problem, if windows behaved exactly the same way. (which it most likely does not, otherwise PNClient wouldn't crash, right?). And: my problem is, that I already spent three days in tracking this bug down, so, I'm not sure, if I find the time to write test code, that will demonstrate the difference between windows and wine. Should we move to bug tracker then? Additional minor fix: bmi_has_alpha() tests for alpha channel != 0, but should test for alpha channel != 255. No it shouldn't, 0 is correct. Are you sure? 0 means: everything is transparent, and that sounds like: we need an alpha channel, right? Don't get me wrong, if windows behaves like that, it's ok for me, too, but that really sounds strange. Cheers, Peter Peter Schlaile
Re: user32/gdi32: Fix for a crash in create_alpha_bitmap()
Hi Vitaliy, On Sun, 30 Jan 2011, Vitaliy Margolen wrote: On 01/30/2011 04:16 AM, Peter Schlaile wrote: Hi, find fix for a crash in create_alpha_bitmap() attached. If it's easy to reproduce please create a test that demonstrates the problem. hmm, don't know, the application that triggered it, can be downloaded here: http://www.phononet.de/downloads/support/downloads/Aktueller_PNClient/PNCLIENT1.9.zip It will fail on startup, because of that problem, showing a dialog box, that some of it's data has been damaged and offers you to close or restart. (The program installs it's own page fault exception handler, you can see the reason of the crash if you run wine with WINEDEBUG=+relay .) If you apply my patch, it will start up correctly, ask for a valid license key (which can be skipped) and show a search screen for CDs/DVDs published in Germany. Nevertheless: I hope, I explained pretty well, how and why the current code is wrong (aquiring a bitmap-pointer using CreateDIBSection, setting this bitmap to readonly using the fast track code path within StretchDIBits, writing to this bitmap again.). Additional minor fix: bmi_has_alpha() tests for alpha channel != 0, but should test for alpha channel != 255. This should be a separate patch. probably, but you will agree, that this is a rather trivial change... (and pretty obvious, too). Hope that's ok anyways. Cheers, Peter Peter Schlaile
Re: FYI: OpenCL/opencl.h from NVIDIA...
On 21/01/11 13:21, James McKenzie wrote:
As far as I knew from information I gathered here, the only OS that
supports OpenCL was MacOSX. Sorry for the misleading information.
I developed wine OpenCL support under Gentoo, using the Gentoo provided
NVidia drivers and NVidia CUDA packages. I'm not sure if anyone got it
working on OSX.
You should be able to:
1. Install the NVidia drivers
2. Install NVidia CUDA/OpenCL SDK
3. Make a link /usr/include/CL -> /opt/cuda/include/CL (or wherever you
installed the SDK)
After that, configure should find OpenCL and use it.
If you want RPMs or other distro specific packages, hassle your
distribution maintainers. (Or switch to Gentoo ;-)
Both AMD and Intel also have OpenCL implementations/SDKs available.
Their distro support varies.
Best regards,
Peter Urbanec
Re: [PATCH 2/2] opencl: Basic OpenCL 1.0 implementation. (try 2)
On 01/12/10 22:47, Alexandre Julliard wrote: Peter Urbanec writes: Second, I am anticipating that when wine OpenCL 1.1 support is added, we'll need to determine whether the host is using OpenCL 1.0 or 1.1, at runtime. How is that going to work? OpenCL 1.1 removed the clSetCommandQueueProperty API, which means that it's probably no longer going to be exported from the OpenCL 1.1 .so file. On the other hand, OpenCL 1.1 introduces a number of new APIs, such as SubBuffers and BufferRects that won't be in the OpenCL 1.0 .so file. I have no idea how the various vendors will deal with these changes, so my strategy was to implement a dynamic solution. The idea being that I can figure out whether an implementation is OpenCL 1.0 or 1.1 compliant, without having to get a list of platform IDs and then query the CL_PLATFORM_VERSION and parse the string. Perhaps I'm over-engineering this and I should just concentrate on current OpenCL 1.0 functionality and deal with OpenCL 1.1 when it hits mainstream. As it is, the current incarnation of the dynamic loading will fail in more or less the same way as a linked version would. Would you like me to resubmit the patch with the dynamic loading replaced with a simpler linked version? I guess once we see OpenCL 1.1 implementations in the real world, we can add dynamic loading only for the affected functions, if any. Best regards, Peter Urbanec
Re: [PATCH 2/2] opencl: Basic OpenCL 1.0 implementation. (try 2)
On 01/12/10 12:33, Roderick Colenbrander wrote: OpenCL is a little different of course, but I fear that not all OpenCL implementations will like wrapping. What OpenCL applications have you tried so far? The Nvidia GPU Computing SDK (or whatever it was called) has a ton of samples for both Cuda and OpenCL. Do all their OpenCL samples work? I added wine OpenCL support in order to get OpenCL functionality in eyeon Fusion 6.1 [*] and it works with both built-in tools and Fuses. I also tested with a number of (not all) samples from the Nvidia GPU Computing SDK. It works with the simple ones, like oclDeviceQuery.exe and oclBandwidthTest.exe as well as the more complex ones, like oclParticles.exe I only tested with Nvidia GT240 hardware, 260.19.x series drivers, but I will get a chance to test with an ATI FirePro V5800 at some point in the future. So far, I have only implemented support for the mandatory core OpenCL 1.0 functionality. In particular, native kernels (optional feature) are not supported and probably never will be. Extensions are not yet supported, they will each have to be dealt with on individual basis, but I suspect that features such as cl_khr_fp64 support should be doable. OpenGL sharing is also not supported yet - mainly because I don't know enough about wine OpenGL internals. I'm hoping that I will get some help with OpenGL sharing once the basic OpenCL implementation is in the wine tree. [*] http://www.eyeonline.com/Web/EyeonWeb/Products/fusion6/fusion6.aspx
Re: [PATCH 2/2] opencl: Basic OpenCL 1.0 implementation. (try 2)
On 30/11/10 21:15, Alexandre Julliard wrote: Why are you loading everything dynamically instead of simply linking to it? Couple of reasons. First, a machine may or may not have an OpenCL implementation installed and it may or may not have the required hardware. Second, I am anticipating that when wine OpenCL 1.1 support is added, we'll need to determine whether the host is using OpenCL 1.0 or 1.1, at runtime.
Re: [PATCH 1/2] opencl: Initial stub implementation of OpenCL 1.0 (try 2)
On 30/11/10 05:31, C.W. Betts wrote: It doesn't look like you look for Apple's OpenCL implementation, which uses. That was intentional. I have no way of testing on OSX, so rather than including untested code and giving the illusion of it working on OSX, I decided to leave that out. I am also not sure what, if anything, I need to do with autoconf to support OpenCL detection on OSX. My personal preference would be to get the current version accepted in the wine tree and then someone with access to an OSX system can provide a complete patch. Of course, if AJ would prefer the untested #ifdef __APPLE__ variant, I'm happy to resubmit the patch. Cheers, Peter Urbanec
Re: [PATCH] ntdll: Increase size of buffer used to read lines of /proc/cpuinfo
Den 2010-11-29 08:36 skrev Peter Rosin:
> Den 2010-11-29 01:03 skrev James Eder:
>> On 11/26/10 12:15 AM, Damjan Jovanovic wrote:
>>> On Fri, Nov 26, 2010 at 6:56 AM, Vitaliy Margolen
>>> wrote:
>>>> On 11/24/2010 07:19 PM, James McKenzie wrote:
>>>>> On 11/24/10 6:56 PM, Vitaliy Margolen wrote:
>>>>>> On 11/24/2010 12:23 PM, jimportal at gmail.com wrote:
>>>>>>> From: James Eder
>>>>>>>
>>>>>>> - while (fgets(line,200,f) != NULL)
>>>>>>> + while (fgets(line,450,f) != NULL)
>>>>>> You might as well then change this to "sizeof(line)".
>>>>> Just for my edification, is there not a better way then setting the
>>>>> variable
>>>>> line to a flexible length for this purpose.
>>>> Unless I didn't understand your question - you can't set a buffer to a
>>>> "variable length". You have to provide fgets() a size of the buffer so it
>>>> can read at most that many characters -1 for terminating \0.
>>>>
>>>> Vitaliy.
>>>>
>>>>
>>>>
>>> So read lines dynamically instead:
>>>
>>
>> It would be nice to not reinvent that wheel all the time. I don't
>> suppose your function could be pulled out of winemenubuilder.c and
>> placed in a more accessible location. Should I just copy and paste
>> it? It's a good function and it would fit just fine in my opinion.
>>
>> Alternatively, I doubt 2k or 4k worth of processor features ("flags")
>> are going to show up for some years, but I don't know. At any rate,
>> at least it would fix it for current systems.
>
> I'm just making a note that the fgets function is not very well suited
> for CRNL style line endings. In the cases discussed here, you appear to
> only handle linux files with NL style line endings, but if you ever try
> to handle CRNL files, fgets may read CR as the last character on one
> invocation and then forget that until the next invocation and thus fail
> to find the line ending. The proposed function a few messages back
> would in that case read two lines into the buffer, and they would be
> separated by a CR.
>
> For this reason, I consider fgets completely unusable (on Windows) for
> anything where the maximum line length isn't known in advance.
>
> But maybe wine does not have this problem? However, my XP SP3 sure does.
Scratch that, it appears to behave. I must have screwed up my previous
tests.
However, I do remember fgets misbehavior on Windows.
Cheers,
Peter
Re: [PATCH] ntdll: Increase size of buffer used to read lines of /proc/cpuinfo
Den 2010-11-29 01:03 skrev James Eder:
> On 11/26/10 12:15 AM, Damjan Jovanovic wrote:
>> On Fri, Nov 26, 2010 at 6:56 AM, Vitaliy Margolen
>> wrote:
>>> On 11/24/2010 07:19 PM, James McKenzie wrote:
>>>> On 11/24/10 6:56 PM, Vitaliy Margolen wrote:
>>>>> On 11/24/2010 12:23 PM, jimportal at gmail.com wrote:
>>>>>> From: James Eder
>>>>>>
>>>>>> - while (fgets(line,200,f) != NULL)
>>>>>> + while (fgets(line,450,f) != NULL)
>>>>> You might as well then change this to "sizeof(line)".
>>>> Just for my edification, is there not a better way then setting the
>>>> variable
>>>> line to a flexible length for this purpose.
>>> Unless I didn't understand your question - you can't set a buffer to a
>>> "variable length". You have to provide fgets() a size of the buffer so it
>>> can read at most that many characters -1 for terminating \0.
>>>
>>> Vitaliy.
>>>
>>>
>>>
>> So read lines dynamically instead:
>>
>
> It would be nice to not reinvent that wheel all the time. I don't
> suppose your function could be pulled out of winemenubuilder.c and
> placed in a more accessible location. Should I just copy and paste
> it? It's a good function and it would fit just fine in my opinion.
>
> Alternatively, I doubt 2k or 4k worth of processor features ("flags")
> are going to show up for some years, but I don't know. At any rate,
> at least it would fix it for current systems.
I'm just making a note that the fgets function is not very well suited
for CRNL style line endings. In the cases discussed here, you appear to
only handle linux files with NL style line endings, but if you ever try
to handle CRNL files, fgets may read CR as the last character on one
invocation and then forget that until the next invocation and thus fail
to find the line ending. The proposed function a few messages back
would in that case read two lines into the buffer, and they would be
separated by a CR.
For this reason, I consider fgets completely unusable (on Windows) for
anything where the maximum line length isn't known in advance.
But maybe wine does not have this problem? However, my XP SP3 sure does.
Cheers,
Peter
Re: Debugging 64-bit Wine Apps with winedbg
On 24/09/10 06:43, Eric Pouech wrote: sure send me the .exe+pdb (+source) I'll have a look at it Source and binaries sent to Eric in private, so that the list isn't polluted with megabytes of binaries. If anyone else is interested in having a copy, please let me know and I'll forward it in private. Cheers, Peter Urbanec
Re: Debugging 64-bit Wine Apps with winedbg
On 23/09/10 06:51, Tom Grubbe wrote: problem seems to be getting any kind of stack trace information from the 64-bit winedbg. This used to work with the 32-bit version of winedbg. I can confirm that wine64 winedbg can not produce valid backtraces for multi-threaded programs (.exe + .pdb) generated by the VS2005 64-bit compiler. I get something like the following: Backtracing for thread 001a in process 0008 (Z:\amd64\MultipleThreads.exe): Backtrace: =>0 0x7f68d08925ab __libc_read+0x2b() in libpthread.so.0 (0x7f68ceb3c7a0) Backtracing for thread 0019 in process 0008 (Z:\amd64\MultipleThreads.exe): Backtrace: =>0 0x7f68d08925ab __libc_read+0x2b() in libpthread.so.0 (0x7f68cec4c7a0) Backtracing for thread 0018 in process 0008 (Z:\amd64\MultipleThreads.exe): Backtrace: =>0 0x7f68d08925ab __libc_read+0x2b() in libpthread.so.0 (0x7f68ced5c320) Backtracing for thread 0009 in process 0008 (Z:\amd64\MultipleThreads.exe): Backtrace: =>0 0x7f68d08925ab __libc_read+0x2b() in libpthread.so.0 (0x7f68cef7deb0) 0x7f0d2737b5ab __libc_read+0x2b in libpthread.so.0: syscall Testing on Gentoo x86_64, with wine 1.3.2. Identical source code compiled with VS2005 32-bit compiler running under wine32 produces valid backtraces, although they suffer from bug #20617 * Setting WINEDEBUG to several debug channels has helped some but is difficult to sift through all the noise I don't get much joy from WINEDEBUG output because the crash I encounter appears to be in a DLL initialisation routine called / calling code from Microsoft.VC80.CRT redist code. I can't use the wine msvcrt/msvcp implementations because they are missing implementations for several functions. So any info on strategies to debug 64-bit Wine applications is welcome I would also like to hear any tips for debugging under wine64. I'm finding that even the minidump files produced by wine64 are not much use in VS2005 or VS2008. At least the minidumps from wine32 can provide a little bit of info when loaded into VS2008 debugger. I'm happy to provide test source code, 64-bit and 32-bit binaries and matching PDB files, if anyone is interested in looking at the issue. Cheers, Peter Urbanec
Re: [PATCH] winealsa.drv: Count micelem in mixer chans, don't add spare capture input for half-duplex mics.
Den 2010-09-05 11:45 skrev David Laight: > On Wed, Sep 01, 2010 at 05:40:35PM +0200, Alexandre Julliard wrote: >> Jeff Cook writes: >> >>> @@ -520,7 +520,12 @@ static void ALSA_MixerInit(void) >>> } >>> >>> /* Add master channel, uncounted channels and an extra for capture >>> */ >>> -mixdev[mixnum].chans += !!mastelem + !!headelem + !!pcmelem + 1; >>> +/* Do not add the extra channel needed for capture on half-duplex >>> capture cards >>> + like snd_usb_audio mics */ >>> +if (micelem && !mastelem && !captelem) >>> +mixdev[mixnum].chans += !!mastelem + !!headelem + !!pcmelem + >>> !!micelem; >>> +else >>> +mixdev[mixnum].chans += !!mastelem + !!headelem + !!pcmelem + >>> !!micelem + 1; >> >> This statement wasn't exactly clear before, but now it's really >> impossible to follow. Please rewrite this in a way that makes sense to a >> casual reader. > > Clearly it should be: > mixdev[mixnum].chans += !!mastelem + !!headelem + !!pcmelem + > (micelem && !mastelem && !captelem); > ducks quickly ... :-) Clearly not, since it is harder to debug code than to write it, and you failed to write it correctly in the first place (assuming the patch was indeed correct). Good thing you ducked... :-) Cheers, Peter
msvcrt unimplemented function calls
I see calls to the following two functions just prior to a crash when testing wine64. Any idea what these are? wine: Call from 0x7b8497d9 to unimplemented function msvcp80.dll.??0?$comp...@n@std@@q...@aebn0@Z, aborting wine: Call from 0x7f7b04cf40d9 to unimplemented function MSVCR80.dll.__C_specific_handler, aborting err:seh:setup_exception stack overflow 2432 bytes in thread 0009 eip 7f7b04d32341 esp 7f7b03b10c80 stack 0x7f7b03b1-0x7f7b03b11000-0x7f7b03c1 Segmentation fault Thanks.
PDB files generated by Intel C++ Compiler
I have some x64 binaries and associated PDBs that have been generated using Intel C++ Compiler 11.1. These PDBs cause issues such as this: 1 0x781cc1ba in msvcr80 (+0x9c1b9) (0x7ff047a4c840) fixme:dbghelp_msc:codeview_fetch_type Cannot locate type 670 err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols 2 0x6189a00d in lua5.1 (+0xa00c) (0x7ff047a4c840) Now, from a quick look at mscvpdb.h, it looks like these PDBs contain datatypes with 64-bit near pointers, however wine does not seem to understand this mode. How would one go about adding support for this type of PDB? I actually don't have access to the Intel C++ Compiler to do much testing. :-(
Re: Wine64 debugger
On 18/08/10 01:51, Marcus Meissner wrote: On Wed, Aug 18, 2010 at 01:00:35AM +1000, Peter Urbanec wrote: I'm seeing crashes in FindNextFileW/FindNextFileA due to what looks like a 64 bit HANDLE value being truncated to 32 bits. Check if your code uses "int" in its FindNextFile or findfirst things. I had a good look at the wine source code as well as those parts of the application source code that I can get access to and it all looks good as far as correctly using HANDLE type to store HANDLE values. Unfortunately, the application in question also makes use of FLEXlm libraries from Macrovision and these binary blobs appear to be buggy. All the symptoms point to the FLEXlm code storing the 64-bit HANDLE value in a 32-bit int - this is evidenced by sign extension on some of the values. Of course, the initial cause and the issues with the debugger are essentially unrelated. I have sent some sample test binaries to Eric, to reproduce the debugger issue. The buggy Win64 application is another story. It looks like Win64 must most of the time return HANDLE values that fit within 31 bits, because from what I hear, Windows users go through thousands of invocations of this app without seeing any issues. I wonder if there is a way of making wine allocate the memory for the object pointed to by the HANDLE somewhere in the lower part of the address space. That ought to mitigate this particular application bug and bring the compatibility a little closer to what's observed under Win64.
Wine64 debugger
Hi, I'm trying to get a fairly complex Win64 application to work with wine. I'm seeing crashes in FindNextFileW/FindNextFileA due to what looks like a 64 bit HANDLE value being truncated to 32 bits. I thought that I would employ winedbg to help me, but I can't get very far. I don't have any luck with winedbg even on a simple x64 Win32 app. For my simplified test, I used MSVC2005 to generate an x64 executable created from the standard MSVC2005 template Win32 application. This is a simple app that just creates an empty window. As simple as one could get for a Win32 test and it executes correctly when run as "./wine Test1.exe". When I try to execute this test app under winedbg, I get an assert failure: ./wine winedbg Test1.exe WineDbg starting on pid 001a ./programs/winedbg/memory.c:37: be_cpu_linearize: Assertion `addr->Mode == AddrModeFlat' failed. wine: Assertion failed at address 0x7fec2fa657c5 (thread 0009), starting debugger... Unhandled exception: assertion failed in 64-bit code (0x7fec2fa657c5). Any ideas about why I can not use winedbg to run Win32 x64 code? Thanks, Peter Urbanec
Re: D3DXCreateTeapot
On 20/07/10 04:54, Ian Macfarlane wrote: Following the question as to how to implement D3DXCreateTeapot, might I suggest making it in the form of a wine glass? Given that is unlikely to negatively affect anything (indeed the entire method does border on the ridiculous) I think it would make a nice hidden touch. The geometrical properties of a wine glass and the teapot are sufficiently different that I would argue against that. For starters, a teapot is not symmetrical, like a wine glass would be. The handle of the teapot also creates a topological feature that is not present in a wine glass.
NPTL and kthreads in the developer guide
Since kthreads has now been removed, references to it in the developer's guide should presumably be removed. What about NPTL? Should discussion comparing it to kthreads be removed? Peter
Re: Manifests, Microsoft.VC90.CRT and vc_redist
On 12/07/10 20:44, Paul Chitescu wrote: On Monday 12 July 2010 12:49:02 pm Peter Urbanec wrote: Wine itself provides msvcr90.dll.so, which as far as I can tell doesn't play the manifest games or provide any particular version number. Should I be using msvcr90.dll from VC redist? Should I be using msvcr90.dll.so provided by wine? If so, how do I tell wine to ignore manifests and just load the DLLs found in the app dir? Thanks for any insights you could provide. You need a special manifest to redistribute the VC runtimes in the application's directory. This is provided with Visual C++ (but not with the Express edition that doesn't allow you to distribute the created applications). I am already using "Microsoft Visual Studio 9.0\VC\redist\amd64\Microsoft.VC90.CRT" from a full blown install of Visual Studio 2008, which includes a manifest. Is that the manifest you mean? This manifest does not include any redirections and so I run into the problem listed in the Caveats section of this blog entry: http://blog.helgeklein.com/2010/03/deploying-visual-c-runtime-files-as.html I'm still not quite sure whether I need to persist with distributing the MSVC provided DLLs or whether I can use the wine implementation instead. Can I get wine to ignore the manifests and just load DLLs from the app directory?
Manifests, Microsoft.VC90.CRT and vc_redist
I'm trying to get my head around the mess generated by SxS, isolated apps, embedded manifests, local deployment and all the other "solutions" to DLL hell. It's hard enough to make it work on Windows, but making it work well under wine is another challenge. In a nutshell, I'd like to ship a custom wine64 RPM package that can co-exist with distribution provided wine32 RPMs. I also want to make a couple of companion RPMs, which provide x64 apps that depend on my wine64 RPM. I don't want to require an installation of the x64 packages under Wine. i.e. I want to avoid the requirement to run vcredist_x64.exe for each user. The most obvious solution to this seems to be to include the DLLs from "Microsoft Visual Studio 9.0\VC\redist\amd64\Microsoft.VC90.CRT" in the same dir as the x64 application executable, known as "application local deployment". Now, this is where I get confused. The VC redist files provide DLLs with version 9.0.30729.1, whereas the manifest embedded in the application has version 9.0.21022.8. When the 9.0.30729.1 VC redist files are installed in the windows dir, the associated policies will redirect requests for 9.0.21022.8 to use 9.0.30729.1, but this does not seem to work when the DLLs are deployed in the app directory. Wine itself provides msvcr90.dll.so, which as far as I can tell doesn't play the manifest games or provide any particular version number. Should I be using msvcr90.dll from VC redist? Should I be using msvcr90.dll.so provided by wine? If so, how do I tell wine to ignore manifests and just load the DLLs found in the app dir? Thanks for any insights you could provide.
Re: RFC: Wine API Documentation Proposal
> I don't know about the 'respectability' of SF, but I'm more concerned with > the content and who gets to change it. There are folks that may decide to > enter incorrect or even bogus information. I would like it if all added > information that is not already present in the Wine API be vetted. That > means one person enters it and another disassociated person verifies before > it goes live. Code already in the API should be considered automatically > vetted. I think the speed and freedom provided by wiki is more important than vetting. Most problems would be due to vandalism (easily reverted), people will keep an eye on Recent Changes. If the problem is overwhelming, we will make editing privileges require a grant by an admin on a shall issue basis. Bogus information is a non-issue, people with sufficient knowledge to enter convincing information are not going to be the sort to enter bogus information. Wikipedia has a high level of accuracy despite its openness. Peter
Re: Add support for arguments to -fprofile-* functions.
> What's wrong with strncmp? strncmp(arg, str, sizeof(str)-1) looks ugly. Peter
Re: Add support for arguments to -fprofile-* functions.
> Hi,
> sorry, but your patch is a bit ugly...
> please look at the code below /* determine if tihs switch is followed by a
> separate argument */ in winegcc.c and understand what it does.
> specially with next_is_arg, is_linker_arg,
I could set option_arg for semantic correctness.
> Also the following is senseless:
> +int strstartswith(const char * str, const char * start)
> +{
> + return strstr(str, start) == str;
> +}
Are you objecting to function or the implementation? It is a simple
function that clarifies the code by making it self documenting,
implemented fairly efficiently in a performance wise undemanding
program.
Peter
Re: (Resent) Documentation - Reference to MSDN?
> My primary concern here is > participation Count me in! I think it would be a great way to learn the wine/windows internals. Peter
Re: Creating tests with additional binary modules
> Wine can load and parse resources just from > winelib (dll.so/exe.so) binaries. I assume that dll.so/exe.so are for all practical purposes identical to .dll/.exe except they can't be run on windows. Peter
Re: updating spec files - which windows version to use?
> Howdy, > > I was looking at http://bugs.winehq.org/show_bug.cgi?id=23421, and > wanted to add a stub for it. Using winedump on a Windows 7 shlwapi.dll > gives different exports than Windows XP SP3 shlwapi.dll. Which dll > should the spec file be updated to match? I'm assuming the latest and > greatest, since eventually applications will head that direction. > > An additional related question. Some of the functions that are > ordinals in previous Windows versions are now exported (e.g., > ParseUrlA/W seems to have been documented/exported since Vista). > Should the spec file be adjusted to match the newer behavior? > > I'm assuming this will have to wait until after 1.2 to be applied... > > Thanks! > Austin If there are no conflicts, add everything. If any version of windows exports something, export it. Exporting ParseUrlA/W by name will work with both XP and post-vista programs, not exporting it by name will break post-vista programs. If a function was removed after a certain version, it wouldn't be removed in wine. Peter
Re: Please resend the fixed gcov patch by tomorrow so I can test building with it :)
> What is the cleanest way to do this? I was hoping it would be as simple > as passing -fprofile-generate and -fprofile-dir as CFLAGS and LDFLAGS > to configure. > > Thanks, > Scott Ritchie Copy 'preloader.o' (to prevent wine-preloader being rebuilt) and 'wine-preloader' from a normal build. As noted elsewhere -fprofile-dir won't work (I intend to fix this soon). Peter
Re: Add files generated by "make depend", PGO and gcov to .gitignore
> Is best practice to confine these to a particular folder (like you get > with -fprofile-dir)? Is there a switch to do that for gcov data? Due to limitations of my patch -fprofile-dir (or passing arguments to -fprofile-* is unsupported). All it allows you can do is pass "--coverage", "-fprofile-generate" or "-fprofile-use" to winegcc without arguments. It started as a hack to enable gcov and evolved into a hack to enable PGO and gcov. Peter
Re: Add files generated by "make depend", PGO and gcov to .gitignore
> It shouldn't. What conf* files do you see? conf23880 conf23880.dir conf23880.file Where "conf23880.dir" is an empty directory, "conf238800.file" is a file containing only a newline and "conf23880" symlinks to "conf23880.file". Having looked into it, it seems that these files are usually deleted by 'make depend' and are only temp files (I probably stopped "make depend" with ^C to generate them). The pattern is broken anyway since it also catches "configure", etc. Peter
Re: Add files generated by "make depend", PGO and gcov to .gitignore
Does this mean that "make depend" should be removed from README and ./tools/wineinstall? It generates /conf* files. Peter
Re: Please resend the fixed gcov patch by tomorrow so I can test building with it :)
On 18 June 2010 01:50, Scott Ritchie wrote: > Hey Peter, > > Was just hoping you'd make the (I believe trivial) change to your gcov > patch that Alexandre wanted and submit it by tomorrow so it creeps into > the next RC. I want to start messing around with profiled package > builds this weekend :) > > Anyway, keep up the good work! > > Thanks, > Scott Ritchie > I didn't send it because the change was so trivial (I have now). Note you will need to build wine-preloader without PGO (and with a libport.a without PGO) or you will get libc linking errors. Peter
Re: [RESEND 2] Changes to enable the use of gcov and PGO
>LDFLAGS are already passed to winegcc where appropriate. Oops, hadn't noticed they got in though $(ALL_LIBS), you can omit that part of the patch then. Why do we silently drop unrecognized args in "winegcc" anyway? Peter
Re: PGO and wine
On 16 June 2010 02:37, Dan Kegel wrote: > But does PGO improve performance measurably? > Probably, to test it I need a program that runs wine like a typical program, that I can run autonomously. Anyone have any ideas? Peter
Gcov and PGO
After applying my "[RESEND 2] Changes to enable the use of gcov and PGO" patch To use gcov: Run "make EXTRACFLAGS=--coverage LDFLAGS=--coverage" Run program (presumably test suite) Run "gcov file.c" (multiple files like "gcov *.c" doesn't work for some reason) To use PGO Run "make EXTRACFLAGS=-fprofile-generate LDFLAGS=-fprofile-generate" Run sample program (test suite is inappropriate because it doesn't represent normal usage). Run "make clean" Run "make EXTRACFLAGS=-fprofile-use LDFLAGS=-fprofile-use" Peter
Re: propsys: mention that the functions are stubs
> Wouldn't it be sufficient for our purposes to just count every first > fixme in a WINAPI function as a stub? As it is now there's a large > percentage of fixmes that don't include the 'stub' keyword. A FIXME doesn't neccesarily indicate a stub. It sometimes is like "Flag FOO unsupported", which is not the same as a stub. Maybe we could have STUB macro to be called in stub functions. Peter
Re: Changes to enable the use of gcov
> Somehow this patch got munged in transit and will not apply to current git. > Can you update it and send it again? I think my mail client (gmail) line wraps. I discovered when trying to apply it myself. > As an aside, if gcov compilation finally starts working that means we > can build Wine using GCC's Profile Guided Optimization. In other > applications this has made a very significant boost in performance, and > it's basically "free". The changes to enable gcov are trivial, all we have to do is have winegcc let the relevent options through. I'll resend the patch and make sure it helps with PGA. Peter
Re: Updating the 1.2 release announcement text
On 14/06/10 18:12, Edward Savage wrote: I'm looking to try and fill out a WWN for this friday I really think it would be very beneficial to go into some detail on the 64-bit support. In particular, it would be a good idea to outline the expected user experience when running a 64-bit app.
Re: Make depend
On 14 June 2010 18:40, Damjan Jovanovic wrote: > > Since around 2-3 months ago, you don't need to run "make depend" at all :-). > > Damjan > Then why is it still there? Peter
Make depend
How often do I need to run "make depend"? Peter
Re: Three year sever outstanding bug requiring minor fix
On 12 June 2010 00:23, Aneurin Price wrote: > Is it a legal requirement that everyone working on WINE must be a > complete arsehole, or just a project requirement? > > Nye Which side are you on? Peter
Test suite success rate
How do I get the test suite to report it success rate (as a whole) in a "%d tests executed (%d marked as todo, %d %s), %d skipped.\n" style. Peter
Tests crash
Some tests crash for me (eg. http://bugs.winehq.org/show_bug.cgi?id=22903 segfaults). This means I can't run the entire test suite with "make test", what should I do? Peter
Re: Change a malloc() to a HeapAlloc()
> We use real names here. This patch probably will not be committed until it > is resubmitted. Ops! I've mis-configured my mail client > The patch is also wrong. Why? What difference does malloc() over HeapAlloc() make? (this is arguably a case for not sending the patch in the first place) There is nothing that bugs me more than not being told why I'm wrong. Peter
Re: bt all broken? Bisect result.
I did a git bisect to test the "bt all" issue and narrowed down the issue: d29c6ead9280a174fa07ec7d5cd07293c3f7832d is the first bad commit commit d29c6ead9280a174fa07ec7d5cd07293c3f7832d Author: Eric Pouech Date: Tue Mar 30 21:37:01 2010 +0200 winedbg: Store the CONTEXT in each stack frame to enable register access in the non topmost frames. I used the multithreaded test program from bug 20617 http://bugs.winehq.org/show_bug.cgi?id=20617 to test this problem. This is what a failure looks like: $ ./wine winedbg MultipleThreads.exe ... Wine-dbg>bt all ... Backtracing for thread 0020 in process 0018 (Z:\MultipleThreads.exe): Backtrace: =>0 0xf77fd42e (0x0033f7a8) 1 0x00190050 (0x0018004f) Backtracing for thread 001f in process 0018 (Z:\MultipleThreads.exe): Backtrace: =>0 0xf77fd42e (0x0033f7a8) 1 0x00190050 (0x0018004f) Backtracing for thread 001e in process 0018 (Z:\MultipleThreads.exe): Backtrace: =>0 0xf77fd42e (0x0033f7a8) 1 0x00190050 (0x0018004f) Backtracing for thread 0019 in process 0018 (Z:\MultipleThreads.exe): Backtrace: =>0 0xf77fd42e (0x0033f7a8) 1 0x00190050 (0x0018004f) 0xf776b42e: jmp 0xf776b423 ... A proper backtrace should look something like this: ... Backtracing for thread 002e in process 0028 (Z:\U_Drive\Projects\WineDbg_TestCases\Release\MultipleThreads.exe): Backtrace: =>0 0xf7711430 (0x0081ea04) 1 0x7ee155f4 SleepEx+0x2a(timeout=0x00c8, alertable=0) [/source/wine/dlls/kernel32/sync.c:108] in kernel32 (0x0081ea34) 2 0x7ee155c0 Sleep+0x25(timeout=0x00c8) [/source/wine/dlls/kernel32/sync.c:97] in kernel32 (0x0081ea54) 3 0x0040103a Boom::crash_func+0x3a(void_ptr=0x33fdb0) [u:\projects\winedbg_testcases\multiplethreads\multiplethreads.cpp:25] in multiplethreads (0x0081ea68) 4 0x7efbad44 call_thread_func+0xc() in ntdll (0x0081ea78) 5 0x7efbad82 call_thread_entry_point+0x34(entry=0x401000, arg=0x33fdb0) [/source/wine/dlls/ntdll/signal_i386.c:2457] in ntdll (0x0081eb58) 6 0x7efc19ea RtlCreateUserThread(process=0x33fdb0, descr=(nil), suspended=10, stack_addr=0x0(nil), stack_reserve=0x81eb7c, stack_commit=0x81ef7c, start=(nil), param=0x0(nil), handle_ptr=(nil), id=(nil)) [/source/wine/dlls/ntdll/thread.c:411] in ntdll (0x0081f398) 7 0xf756f92f start_thread+0xbf() in libpthread.so.0 (0x0081f498) Backtracing for thread 002d in process 0028 (Z:\U_Drive\Projects\WineDbg_TestCases\Release\MultipleThreads.exe): Backtrace: =>0 0xf7711430 (0x0071ea04) 1 0x7ee155f4 SleepEx+0x2a(timeout=0x00c8, alertable=0) [/source/wine/dlls/kernel32/sync.c:108] in kernel32 (0x0071ea34) 2 0x7ee155c0 Sleep+0x25(timeout=0x00c8) [/source/wine/dlls/kernel32/sync.c:97] in kernel32 (0x0071ea54) 3 0x0040103a Boom::crash_func+0x3a(void_ptr=0x33fda4) [u:\projects\winedbg_testcases\multiplethreads\multiplethreads.cpp:25] in multiplethreads (0x0071ea68) 4 0x7efbad44 call_thread_func+0xc() in ntdll (0x0071ea78) 5 0x7efbad82 call_thread_entry_point+0x34(entry=0x401000, arg=0x33fda4) [/source/wine/dlls/ntdll/signal_i386.c:2457] in ntdll (0x0071eb58) 6 0x7efc19ea RtlCreateUserThread(process=0x33fda4, descr=(nil), suspended=10, stack_addr=0x0(nil), stack_reserve=0x71eb7c, stack_commit=0x71ef7c, start=(nil), param=0x0(nil), handle_ptr=(nil), id=(nil)) [/source/wine/dlls/ntdll/thread.c:411] in ntdll (0x0071f398) 7 0xf756f92f start_thread+0xbf() in libpthread.so.0 (0x0071f498) Backtracing for thread 002c in process 0028 (Z:\U_Drive\Projects\WineDbg_TestCases\Release\MultipleThreads.exe): Backtrace: =>0 0x0040105b Boom::crash_func+0x5b(void_ptr=0x33fd98) [u:\projects\winedbg_testcases\multiplethreads\multiplethreads.cpp:29] in multiplethreads (0x0061ea68) 1 0x7efbad44 call_thread_func+0xc() in ntdll (0x0061ea78) 2 0x7efbad82 call_thread_entry_point+0x34(entry=0x401000, arg=0x33fd98) [/source/wine/dlls/ntdll/signal_i386.c:2457] in ntdll (0x0061eb58) 3 0x7efc19ea RtlCreateUserThread(process=0x33fd98, descr=(nil), suspended=0, stack_addr=0x0(nil), stack_reserve=0x61eb7c, stack_commit=0x61ef7c, start=(nil), param=0x0(nil), handle_ptr=(nil), id=(nil)) [/source/wine/dlls/ntdll/thread.c:411] in ntdll (0x0061f398) 4 0xf756f92f start_thread+0xbf() in libpthread.so.0 (0x0061f498) Backtracing for thread 0029 in process 0028 (Z:\U_Drive\Projects\WineDbg_TestCases\Release\MultipleThreads.exe): Backtrace: =>0 0xf7711430 (0x0033fcfc) 1 0x7ee155f4 SleepEx+0x2a(timeout=0x00f0, alertable=0) [/source/wine/dlls/kernel32/sync.c:108] in kernel32 (0x0033fd2c) 2 0x7ee155c0 Sleep+0x25(timeout=0x00f0) [/source/wine/dlls/kernel32/sync.c:97] in kernel32 (0x0033fd4c) 3 0x0040103a Boom::crash_func+0x3a(void_ptr=0x33fd8c) [u:\projects\winedbg_testcases\multiplethreads\multiplethreads.cpp:25] in multiplethreads (0x0033fd60) 4 0x0040112e main+0xae(argc=0x0001, argv=0x40c338) [u:\projects\winedbg_testcases\multiplethreads\multiplethreads.cpp:65] in multiplethreads (0x0033fdbc) 5 0x0040139c mainCRTStartup+0x173() [f:\vs70builds\6030\vc\crtbld\crt\src\
Re: bt all broken?
On 09/04/10 19:10, Peter Urbanec wrote: On 07/04/10 06:39, Dan Kegel wrote: winedbg's bt all seems broken since sometime between 1.1.40 and now. Has anybody else seen this? If I start a program under debugger control with "./wine winedbg ~/test/my.exe" then I see errors such as "Can't get context for thread 0021 in current process" or backtraces like this: Backtrace: =>0 0xf773d42e uni2cp_low+0x576e() in libwine.so.1 (0x0033f7a8) Backtrace: =>0 0xf773d42e uni2cp_low+0x576e() in libwine.so.1 (0x0033f7a8) 0xf771d42e: jmp 0xf771d423 If a program crashes and invokes the debugger (which I have modified to execute "bt all" instead of "bt" by default), I get a full set of backtraces. I am now getting bad "bt all" even with the debugger being invoked from a crash. I see this: Backtrace: =>0 0xf770c42e cp2uni+0x4b8e() in libwine.so.1 (0x0033f7a8) for every thread in the program that crashed. Tested with wine 1.1.43, plus all commits up to about 4 hours ago. Dan, Are you still seeing this problem? Any ideas as to what may have caused it? Cheers, Peter Urbanec
Re: bt all broken?
On 07/04/10 06:39, Dan Kegel wrote: winedbg's bt all seems broken since sometime between 1.1.40 and now. Has anybody else seen this? If I start a program under debugger control with "./wine winedbg ~/test/my.exe" then I see errors such as "Can't get context for thread 0021 in current process" or backtraces like this: Backtrace: =>0 0xf773d42e uni2cp_low+0x576e() in libwine.so.1 (0x0033f7a8) Backtrace: =>0 0xf773d42e uni2cp_low+0x576e() in libwine.so.1 (0x0033f7a8) 0xf771d42e: jmp 0xf771d423 If a program crashes and invokes the debugger (which I have modified to execute "bt all" instead of "bt" by default), I get a full set of backtraces. I have also been seeing "err:dbghelp_msc:pe_load_debug_directory Got a page fault while loading symbols" on executables and matching PDB files generated by the Intel Compiler. It seems that MSVC generated executables and PDBs work fine. That problem has been around for quite a while, certainly before 1.1.40
Re: Verbose explanation about the cygwin issue
Den 2010-03-22 17:47 skrev Steven Edwards: On Sat, Mar 20, 2010 at 2:49 PM, Alexandre Julliard wrote: And what about #ifdef __CYGWIN__ ? It sounds ugly but ... why not ? You can't use #ifdefs in winegcc. I suppose you could try to resolve __wargv dynamically at run-time. I was wondering if it was possible under current cygwin to still install mingw that was a separate package from the cygwin-gcc. Sorry for not asking sooner but I assume based upon prior emails we are going to end up linking msvcrt and cygwin1? Are you sure this is even going to work? When I've tried this in the past, which was years ago, the applications would either crash or behave unpredictably. I checked the cygwin faq and linking to both msvcrt and cygwin1 was still not supported but perhaps the FAQ is out of date. I am not sure what has changed and have just be cursory following this but it peaked my interest since it was stated that they removed the -mno-cygwin option. Assuming 'bad things' still happen, I was thinking, could we make it work if we linked to msvcrt and then were able to use a wine build of our msvcrt which would forward functionality that it did not implement itself to cygwin1. I guess this is kind of how msvcrt/glibc work on Linux. More assumptions which may not matter but, I could see it still not working due to msvcrt perhaps being a 'KnownDLL' in recent windows (I am not sure if it is or if you can still use your own msvcrt). Also this whole idea would create a circular dependancy because we would have to build wine to be able to build winegcc, My thinking was, if we require mingw on cygwin, then that would solve the winegcc problem and the rest of wine could be built including wine msvcrt, applications that linked to msvcrt would of course have to use Wine msvcrt because if they don't then we will get in to the situation of both c runtimes being invoked which I expect will still not end well. Hi! I don't know what you want to achieve, so I will just talk from the Cygwin/MinGW side and ignore the Wine side for a bit. The gcc version 3 series in Cygwin included a switch -mno-cygwin which turner gcc into a MinGW tool chain. I.e. a cross compiler. The normal way to handle cross tools would be to name them i586-mingw32-gcc or something such. Since people apparently got confused and didn't realize that they were using a cross compiler when then typed -mno-cygwin it was decided that that option should be ditched for the gcc version 4 series in Cygwin, in favour of a properly named cross tool chain. The first part has been implemented (there's no -mno-cygwin option in Cygwin gcc-4) but unfortunately not the second. So, users that need to use the MinGW compiler from Cygwin have some options. 1. Stick with gcc-3 and -mno-cygwin. Or, if gcc-4 is required, 2. Build the cross tool chain manually. However, there might be good reasons (such as obscure bugs) for an official package to not be available yet. 3. Wait for the official cross tool chain to be available. So, you need to ask yourselves what you want to do. Do you want to build Cygwin dlls/executables (depends on Cygwin libc) or do you want to build MinGW dlls/executables (depends on msvcrt)? Mixing is not supported, and if you do that anyway with anything sufficiently non-trivial you get to keep the pieces, so the suggestion to use -L/usr/lib/w32api -lmsvcrt with the native Cygwin gcc is not good even if it appears to work. (hmmm, was that even the suggestion?) Cheers, Peter -- They are in the crowd with the answer before the question. > Why do you dislike Jeopardy?
Re: measuring audio latency?
Den 2010-03-09 11:00 skrev Maarten Lankhorst: For example current dsound adds 105 ms or 110ms, depending on whether you use 44100 rate as primary, or 48000. OpenAL will probably use 4 buffers of 1024 samples, which would mean it adds 4096/44100 = 0.90s. I get 0.093s when I do the math... Cheers, Peter -- They are in the crowd with the answer before the question. > Why do you dislike Jeopardy?
OpenCL apps
Has anyone investigated wine support for OpenCL apps? What is required to support Win32 OpenCL apps, assuming the host machine has modern hardware, like an NVidia GT240?
Fwd: [user32/tests] Don't crash on Win9x/WinMe
Forgot wine-devel, >>I'm lost here as TrackPopupMenu() is not called in a loop. It's only called once. So which API function are you referring to? I was referring to the "loop" we got into on NT4 where the proc handler would be re-entered again and again. My idea was that if this happened on 9x as well, then this we could cause a crash. Apparently this is not the case. Thanks, /pedro
Re: [user32/tests] Don't crash on Win9x/WinMe
>> But maybe not with a window that's in the process (or already) of being destroyed (in the callback). OK, but in the the first run of the "loop" we are not in the process of destroying the window, as DestroyWindow has not been called yet. Am i missing something? Are there other things that cause the window to destroy? >>Yes, I'm a 100% sure it's this call. I commented several pieces of code to get to this conclusion. And you are also sure this happens the first time the API is called, and not the second time (because of the loop)? /p
Re: [user32/tests] Don't crash on Win9x/WinMe
> It took a while but I found the culprit. The crash is most likely because > the window is (about to be) destroyed. > > The only thing left to do is to fix the 211 test failures on NT4. > > I fixed a typo while at it and used a define instead of a magic value. > > > Are you sure this is the right fix? Is this crash not caused by the loop, and not the actual call to the menu? Other test-cases call the same API without this problem. /pedro
Re: user32: Do not allow a change of capture if the currently capture window is a menu unless explicitly specified (try3)
Hey Paul, Thanks for cleaning up the crashing 9x test-case so fast. > This patch has introduced test failures on NT4 and below (tested locally): > > http://test.winehq.org/data/tests/user32:win.html Sorry for that. > The callback is entered several times on NT4 (only once on XP) so it > seems. The test crashes on Win98 btw. Even more sorry :-). I would seem that the test-case would do good with a re-entry protection. Do you know where it crashes? > You can use the winetestbot (https://winetestbot.geldorp.nl/) to check > the failures on NT4. I can assist with Win9x testing if needed. I will check it out. Nice server! > I'm busy setting up a local winetestbot that includes Win95, Win98 and > WinMe. Great! Thanks, /pedro
Re: user32: Do not allow a change of capture if the currently capture window is a menu unless explicitly specified (try2)
On Mon, 2010-01-11 at 14:00 -0600, Alexandre Julliard wrote: > Is there actually an app that depends on this? http://bugs.winehq.org/show_bug.cgi?id=9369 This bug requires the function to fail, but you are probably right that no-one checks the error code. I will change the patch/test to be less pedantic. Thanks for the fast reply, /pedro
Re: user32: Do not allow a change of capture if the currently capture window is a menu unless explicitly specified (try2)
> Simply use wine_server_call instead of wine_server_call_err. That is my point. That will not work. The existing the error codes *should* be translated, but this new one should not. So if i use wine_server_call i would have to filter which ones to translate manually. It would also give me the problem of which error code to emit from the wine-server, as real windows does not set an error code at all in this case (hence the problem). I think it would be a bit naughty emitting errors from the server and them removing them with a filter later. Does not seem clean. But if you want me to do this, then what NT error code should the server use? I imagine that no matter what unused error code i selected the response would be "this error code i not meant for that purpose" (which would probably be right as there is no error code for this purpose). I still feel that an extra field in the response in the cleanest (the way my patch did it). Sorry for being so verbal, but i know that you are touchy about the server :-) Thanks, /pedro
Re: user32: Do not allow a change of capture if the currently capture window is a menu unless explicitly specified (try2)
Hello A.
I was afraid you were going to say that! :-)
My initial change actually did that, but then i ran into the problem
that i need the request to fail, but not set an error-code. I could
push/pop the current error code in user32 but that seemed a bit ugly. I
could also single out that error code and then only translate the
others. But what error code should be used then? Also seemed a bit ugly.
Instead i have added a new member to the response to check if the
request was "allowed". Seemed like the cleanest solution. Is this
acceptable?
I have attached a new patch which does this.
Thanks,
/pedro
On Fri, 2010-01-08 at 10:06 +0100, Alexandre Julliard wrote:
> Peter Dons Tychsen writes:
>
> > @@ -85,6 +85,17 @@ BOOL set_capture_window( HWND hwnd, UINT gui_flags, HWND
> > *prev_ret )
> > HWND previous = 0;
> > UINT flags = 0;
> > BOOL ret;
> > +GUITHREADINFO info;
> > +if(!GetGUIThreadInfo(GetCurrentThreadId(), &info))
> > +{
> > +return FALSE;
> > +}
> > +
> > +/* if in menu mode, reject all requests to change focus, except if the
> > menu bit is set */
> > +if((info.flags & GUI_INMENUMODE) && !(gui_flags & GUI_INMENUMODE))
> > +{
> > +return FALSE;
> > +}
>
> This should be handled on the server side.
>
diff --git a/dlls/user32/input.c b/dlls/user32/input.c
index bfe80c4..7fcfe40 100644
--- a/dlls/user32/input.c
+++ b/dlls/user32/input.c
@@ -97,15 +97,19 @@ BOOL set_capture_window( HWND hwnd, UINT gui_flags, HWND *prev_ret )
{
previous = wine_server_ptr_handle( reply->previous );
hwnd = wine_server_ptr_handle( reply->full_handle );
+ret = reply->allowed;
}
}
SERVER_END_REQ;
-USER_Driver->pSetCapture( hwnd, gui_flags );
-
-if (previous && previous != hwnd)
-SendMessageW( previous, WM_CAPTURECHANGED, 0, (LPARAM)hwnd );
+if(ret)
+{
+USER_Driver->pSetCapture( hwnd, gui_flags );
+if (previous && previous != hwnd)
+SendMessageW( previous, WM_CAPTURECHANGED, 0, (LPARAM)hwnd );
+}
+
if (prev_ret) *prev_ret = previous;
return ret;
}
@@ -228,7 +232,11 @@ HWND WINAPI DECLSPEC_HOTPATCH SetCapture( HWND hwnd )
{
HWND previous;
-set_capture_window( hwnd, 0, &previous );
+if(!set_capture_window( hwnd, 0, &previous ))
+{
+return NULL;
+}
+
return previous;
}
@@ -239,11 +247,15 @@ HWND WINAPI DECLSPEC_HOTPATCH SetCapture( HWND hwnd )
BOOL WINAPI DECLSPEC_HOTPATCH ReleaseCapture(void)
{
BOOL ret = set_capture_window( 0, 0, NULL );
+if(!ret)
+{
+return FALSE;
+}
/* Somebody may have missed some mouse movements */
mouse_event( MOUSEEVENTF_MOVE, 0, 0, 0, 0 );
-return ret;
+return TRUE;
}
diff --git a/dlls/user32/tests/win.c b/dlls/user32/tests/win.c
index 24e6ac2..9175abd 100644
--- a/dlls/user32/tests/win.c
+++ b/dlls/user32/tests/win.c
@@ -2697,6 +2697,104 @@ static void test_capture_3(HWND hwnd1, HWND hwnd2)
ok (ret, "releasecapture did not return TRUE after second try.\n");
}
+static LRESULT CALLBACK test_capture_4_proc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
+{
+GUITHREADINFO gti;
+HWND cap_wnd, cap_wnd2, set_cap_wnd;
+BOOL status;
+DWORD err;
+switch (msg)
+{
+case WM_CAPTURECHANGED:
+
+/* now try to release capture from menu. this should fail */
+memset(>i, 0, sizeof(GUITHREADINFO));
+gti.cbSize = sizeof(GUITHREADINFO);
+status = GetGUIThreadInfo(GetCurrentThreadId(), >i);
+ok(status, "GetGUIThreadInfo() failed!\n");
+cap_wnd = GetCapture();
+ok(gti.flags & GUI_INMENUMODE, "Thread info incorrect (flags=%08X)!\n", gti.flags);
+
+/* check that re-setting the capture for the menu fails */
+set_cap_wnd = SetCapture(cap_wnd);
+ok(!set_cap_wnd, "SetCapture should have failed!\n");
+
+/* check that SetCapture fails for another window and that it does not touch the error code */
+SetLastError(0xdeadbeef);
+set_cap_wnd = SetCapture(hWnd);
+err = GetLastError();
+ok(!set_cap_wnd, "ReleaseCapture should have failed!\n");
+ok(err == 0xdeadbeef, "Bad error-code from SetCapture. got %08X expected %08X\n", err, 0xdeadbeef);
+
+/* check that ReleaseCapture fails and does not touch the error code */
+status = ReleaseCapture();
+err = GetLastError();
+ok(!status, "ReleaseCapture should have failed!\n");
+err = GetLastError();
+ok(err == 0xdeadbeef, "Bad
Re: Acting as advisor for wcmd-uplift project?
On Sat, 2009-12-26 at 20:53 +0100, Jacek Caban wrote: > We can't really change the language as Windows doesn't provide English > resources for most binaries and executables on on non-English > installations. Why not just have the tests file check the locale, and then do skip() for the language dependent tests when run on other locales? Tests would then be only executed on systems which support that specific locale, just like it is done for other features that are system-specific. Is that not what skip() is for? Thanks, /pedro
Re: Acting as advisor for wcmd-uplift project?
On Fri, 2009-12-25 at 19:55 -0800, Dan Kegel wrote: > So, where should the tests live? I had been thinking > programs/cmd/tests, > but maybe something like programs/tests would be better > given that it can test more than just cmd. I think it would make most sense to follow the current strategy of one test suite per component/module. This would mean that cmd/tests would test "cmd" and all the built-in commands. If you put the infrastructure in (which would be a great bonus), then people could easily add regsvr32/tests, xcopy/tests, etc... I have a feeling that there are tons of tool related bugs that can be translated into tests. Thanks, /pedro
Re: Acting as advisor for wcmd-uplift project?
On Tue, 2009-12-22 at 15:36 -0600, Austin English wrote: > Sure. FWIW, I'm working on some AutoHotKey/Appinstall tests for cmd, > but it's a bit difficult, since the only way to capture the stdout is > to pipe it to a file first. Hey, i think a test suite for cmd is an excellent idea, and is surely what is needed to lift the quality of this module. However, i think using AutoHotKey in an external script might not be the optimal solution. Why not place the test in the source tree along with all of the other tests. Of course this requires the tests to be run from a C based file and not a AHK file, as i doubt that AJ wants AHK in git. It would however mean that one could add tests for all of the other command line utility programs much easier (not possible now at all). I don't really see "cmd" as an external tool but and integrated part of the Wine product. Therefore i think these tests belong in the main git tree. In any case, tests are better than no tests! (just to state the obvious :-)) /pedro
Re: wine rejects development (Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE)
Hi again, Vitaliy this are great news. I will see if I can read a bit more about XI2. :-D Keep going. You will crack that Bug. Ill try to help if i can steal Time from somewhere. But Honestly I am no Hacker. So don't expect to much of me. I am happy if I can solve the hacks vs. patch problem :P As I see in the reaction this is a Problem that does exist in other Bugs too. (Surprise! ;) ) I think Austin is right, stopping Hacks would slow down development. And we need people hacking. But we also need clear, and on topic Bugzilla or winewill clutter to much. (My believe) It is at least hard for me to pick the interesting Posts in Bugzilla. Or even the Interesting Bugs. Don't know but I see a lots of App based Bug reports. They get collected it one real Bug report. Which is sometimes just the first one that got reported. Hard to search for someone not tracking Bugs. (Aside Most ppl dont look enough I bet ;) ) There are some Ideas about splitting Hacks from patches. I think this maybe an aproach to solve this. Lets see: Looking at the Mouse "escape" Bug. We have 290 Post. Haven't count but going after my feeling at least half of the post belongs more in a Forum then in a Bug tracker. It makes technical Facts realy Hard to follow. I think Bugzilla is really not suitable for Hacker Approach. Bugzilla thinks more in terms where people actually know what they doing. And in case of wine even its best developer are shouting in the dark sometimes I bet. If you look at the Bugzilla post, you'll find: - Tech info - Approach Ideas - Discussions - Affected Infos - Instructions for installing and Bugfixing - A lot of Hacks / patches This is hell of different information unstructured in Bugzilla. Thinking on it, it may be better put into a maintained Wikki with different Sections to go on. There could be a menu which links people to the basic Instructions. It can hold the Hacks. It can serve as Link Collection and Info. And most Important of all it can be overhauled. Closed Discussions can be deleted. If some real approach is found all Info can be back posted into Bugzilla by some "Officer". With that a solution is accepted and likely to enter the main tree when ready. The Idea seems to be quite flexible, but maybe it won't be structured enough. Which means more work for Maintainers (I would install community maintainers :( *sight* Maybe that Idea is not good enough, what do you think? Hmm at least in vision it would give a workflow. Any more Ideas on this? And what should we do with the people on the Bug. Some saying the same within the bug itself. 8 Posts today. Shall I collect them and bring them here? Maybe more Brains come up with more approaches. I hesitate to do so: To much cooks corrupt the porridge. :) Regards Peter > On Mon, Dec 7, 2009 at 8:41 AM, Vitaliy Margolen > wrote: >> Peter Kovacs wrote: >>> Now Vitaliy Margolen actively stopped the >>> maintenance of this workarounds (in the bug called dirty hacks.), by >>> marking the patches obsolete and changing title. >> Yes, tried to, of course I can't stop anyone from hacking and posting their >> work, even on the same bug. All I can do is ask not to. > > Then where do you propose people put that work? > >> I did this because all of those workarounds (with exception of few) done by >> people, who don't understand the entire scope of the problem. They've >> touched (and broke) parts of DInput that have nothing to do with the >> problem. I've already seen several invalid bug reports that were caused by >> some of this hacks. > > This has happened with other bugs/patches too, e.g., the DIB > engine/the msi hack for photoshop/etc. > >>> Is it right to have no Dirty Hack solution which just works? >> Then those hacks called proper patches. But they have to work for >> everything. A "Dirty Hack" is something that avoids a problem for one set of >> apps and totally breaks things for everything else. > > Considering the main ones use a environmental variable to enable the > hack, the risk of that is greatly reduced. > > I'm not saying these aren't hacks. By all means, they are. But users > need/want a solution, so let them have it. Perhaps I'm a bit biased > though, since the last game I played (Borderlands) needed this hack, > so I've also been affected ;-). > > -- > -Austin
wine rejects development (Mouse "escapes" window or is confined to an area in the full screen program NO HACKS PLEASE)
Hi there, I want to bring this Issue up in Development Mailinglist. This proplem is about a bug that cant be fixed within wine, and The Bugtracker doesnt help it. I think this Bug is at the moment an Epic Fail of Open Source Development. (And needs to be solved so we get a accepted Fix somewhere someday) The Bug is Deadlocked. The Problem is in this Bug roughly spoken that in some games the Mouse movement is captured and not the real position. Now X only returns the real position. This Bug is a dependance of X (If I got it right). Since this Bug appeared people worked around this Bug by improving dirty hacks (by calculating mouse movement using weird? code), and maintaining them. And when Possible to make them switchable. Now Vitaliy Margolen actively stopped the maintenance of this workarounds (in the bug called dirty hacks.), by marking the patches obsolete and changing title. The Bug exist since 2009 - 12 - 06. And has a long thread. I understand the move of Margolen here. For that you need to look at the Bug history (clicky: http://bugs.winehq.org/show_bug.cgi?id=6971). And I dont put blame on his move. But for this Bug wine needs another political solution. Just stopping people to write hacks, dirty or not will stop people reaching in more and more patches. This sole incident wont have an effect on hole development but most bugs I followed started with a dirty hack. And this is definitely giving the wrong impression on wine. What I want to say, Margolens move might be technical right, but is political pretty lame. Atm I don't see any ability that the bug will be proper fixed. 1) I Xorg may implement the Problem or may not. Maybe they are even not aware(? - Haven't took a look) The Bug-tracking in wine does not contain a Link to the Bug-tracking in Xorg. 2) I am betting wine - Dev has no one working on the Bug actively. So how can we get a proper Fix or point people towards proper fixes? Is it right to have no Dirty Hack solution which just works? Do you think by stopping Hacks you will encourage development in what (you) think is the right solution? Where is the Xorg Link for this Problem since it is a problem interesting wine but maybe not Xorg? Before anyone asks, I don't have the Time to solve this Bug. Nor I do believe does any one of the "dirty" hackers. Or they had done it Proper by now. Thanks Listening, hope you got the Problem I want to address. I am not on the list since I develop nothing for wine. I would it appreciate it a lot, if I could stay with the discussion by keeping my email address in CC Regards Peter
Re: [PATCH 1/2] msvcrt: Add test to check if signal(SIGBREAK, ...) works (todo_wine).
Den 2009-12-02 16:35 skrev Charles Davis: You don't get added to AUTHORS until you've hacked on Wine enough. I learned that the hard way when I tried to put my name at the top of an already-existing file. I did a - eeerh couple of (sorry for the noise) - resend w/o touching AUTHORS. I don't really see the point of letting someone else update AUTHORS for me though, but now Alexandre can pick whichever version he likes best... Cheers, Peter -- They are in the crowd with the answer before the question. > Why do you dislike Jeopardy?
Re: today's git broke winetricks gecko :-(
Vincent Povirk wrote: Distro-specific packages just put the .cab file in the right place. Gecko binaries target windows, not unix (hence the need for mingw) so they really just depend on a functional x86 Wine. There's a lot of talk about the new Gecko requirement. At the end of the day, adding the .cab file to a binary distribution was a trivial 10 minute exercise. It took another 20 minutes to test everything and figure out that the wiki page was wrong and the .cab file needs to go in $PREFIX/share/wine/gecko NOT in $PREFIX/share/gecko. The wiki page is now fixed, so it really should be trivial to add the gecko runtime to most binary distributions. Yes, my new wine binary package has doubled in size due to a HTML component that is actually never used directly by the target application. A bit of a bother, but if the inclusion of the gecko binary blob as a .cab file means more reliable wine runtime, it's a small price to pay. At the end of the day, the only objection I have is the fact that building the binary release of the .cab file from source is such an ordeal. It would be nice if the requirement for gecko could be satisfied as part of the normal wine build process. Jacek, any ideas on what could/should be done to align the Gecko build process with the wine build process? Is it possible to have minimal Win32 stubs and keep most of the Gecko engine native? Cheers, Peter Urbanec
Multithreaded debugging
Eric Pouech wrote: Peter Urbanec a écrit : It can't be as simple as updating the value of dbg_curr_thread with the result of dbg_get_thread(dbg_curr_process, tid) and then calling GetThreadContext(dbg_curr_thread->handle, &dbg_context), can it? the changes will need to be larger than that winedbg assumes throughout the code that it's stopped in a single thread but, if you change dbg_curr_thread, and enter the 'cont' command, you have to decide which thread should be resumed therefore, the changes imply to use two different objects: - the thread on which an exception occured - the thread you're currently examining and that's not a simple task moreover it'll be hard to understand the difference between the two above mentionned thread objects so, finding another solution might be preferable what are the thread's missing information you were thinking of ? I would like to do the following: [ exception / attach to process ] [ all threads in process are now suspended ] info threads thread 0x42 bt info locals print *some_class up info locals print *some_var Or in other words, being able to examine the state of any thread, including the state of local variables in various stack frames, would be invaluable in determining how various threads got to where they are and what they are doing. Obviously, the above example is only workable if all threads in the debugged process are suspended. If only the current thread is suspended, it makes it very difficult to debug multithreaded code anyway. Controlling execution of individual threads with cont is not very important to me. I'd be quite happy for the debugger to stop and start all threads in a process together. The application that I am working with routinely has around 20-30 threads in interactive use and the thread count goes even higher when rendering jobs are started. Best regards, Peter Urbanec
Re: Question on using winedbg when program does not crash, just becomes unresponsive
Dan Kegel wrote: start winedbg without any app say 'bt all' in winedbg Voila, you now have backtraces for every process, including the hung one. It's your job to get that into a text file and remove the uninteresting ones... I've also been trying to debug a multithreaded app. There are at least two complications that winedbg throws up: 1. Is now documented in http://bugs.winehq.org/show_bug.cgi?id=20617 2. As far as I can tell, winedbg will not allow you to switch the current thread context. This means that even though you can get a backtrace of all threads in all processes, you actually can not examine the state of a specific thread. I don't know enough about the internals of wine to go ahead and implement a "thread tid" command. I could manage the code in dbg.y and debug.l to implement the command line interface. When it comes to the actual implementation, I can sort of guess at what may need to be done there. However, I suspect that my naive attempts at an implementation are unlikely to produce an acceptable patch. It can't be as simple as updating the value of dbg_curr_thread with the result of dbg_get_thread(dbg_curr_process, tid) and then calling GetThreadContext(dbg_curr_thread->handle, &dbg_context), can it?
Re: winex11.drv: Implement FIXME in AlphaBlend
I've taken the following feedback on board and resubmitted the patch. Andrew Eikum wrote: This is less important, but you're not following the code conventions of the surrounding code. The surrounding code does not have spaces around function parameters, so yours shouldn't either. The existing code uses a mixture of styles in the AlphaBlend function alone. My original patch did not have spaces around function parameters, however it did have spaces after C language keywords. The resubmitted patch follows the style of the code immediately before and after the patch, which does not have spaces after keywords. Roderick Colenbrander wrote: I didn't see this patch before because I was away at that time. The SourceConstantAlpha part looks correct to me. It might make sense to calculate blendfn.SourceConstantAlpha / 255 before the loop, so that it isn't recalculated each time. I considered this, but because the alpha is calculated using integer arithmetic on BYTE values, a pre-calculated blend factor would always degenerate to the value 0. The alternative is to use floating point arithmetic for the blend factor calculation, but that would most likely end up being a performance killer. Hopefully the compiler will do a reasonable optimising job if it is possible to improve the code. I guess the code could be hand optimised to use of a vectorised instruction set where available. However, I think that at this point providing a concise and readable implementation is probably a more valuable contribution. The other half of your patch is a separate change and it would require a separate patch. The part looks suspicious though. I don't understand why you need special locking there. Yes, the locking code is not related to the missing AlphaBlend functionality. It got rolled into the patch because I was fixing some other issues at the same time. I have a heavily multithreaded application and without that locking code I end up with areas of the screen that are not updated correctly. To be honest, I don't have a very clear picture of how the various locking mechanisms interact, so it is feasible that the locking code I added does not address the underlying problem, but only fixes the symptom as a side effect. I'd be happy to learn more about the interaction between X11, OpenGL and wine synchronisation mechanisms - any pointers where to look for explanations? Best regards, Peter Urbanec
Re: winecoreaudio: Quiet a noisy FIXME.
On Thu, 2009-10-15 at 19:19 -0500, Ken Thomases wrote:
> +static int once;
> +
> +if (!once++) FIXME("independent left/right volume not implemented
> (%f, %f)\n", left, right);
I know it is a detail, but is it not a bit misleading having a variable
called "once" when it will trigger the code every 4294967295th time.
Its not 100% wrong, but only 0.00023% wrong :-)
More correct would probably be:
static int once;
if(!once) {bla...bla; once=1};
Thanks,
/pedro
Re: Winamp disappears when you move it's location
> Yes I understand your comments, but they show that you don't > understand > the code. Of course i dont understand the code as well as you, as i only have used a little amount of time studying it. I was only hoping that my comments would spark a response which would allow me continue with the bug quicker. Instead you just keep stating the obvious which is that i do not know the code very well. I will use more time on it when possible or drop it. Thanks, /pedro
Re: Winamp disappears when you move it's location
> What you should do first is spend a lot more time studying the code, > before deciding that it has "major problems" and needs major > changes. It's a very sensitive area where the smallest change has big > consequences, and you have to be sure to know what you are doing. I already spent time on this code. So your comment does not really help in any way. Do you at least understand my comments? If not then please state that. Just stating that i should look at it again does not bring anything to the table. There were 3 questions/statements in the mail. Answering at least one of them would be constructive. > needs major changes I never stated that it needs major changes. But yes, winex11.drv is a bit messy if you ask me. Thanks, /p
Re: Winamp disappears when you move it's location
> So... i have investigated other ways of fixing this. Would you accept a > patch that uses _NET_WM_MOVERESIZ to move the window? That might also > fix the issue. That message requests the WM to move the window at not X. I have now tested with _NET_WM_MOVERESIZ & _NET_MOVERESIZE_WINDOW No cigar. They still have the same problem. I have also discovered a major problem in the X11 driver which is affecting this problem (winamp). The mouse code uses the relative coordinates of the window and compares it to the cached value in "whole_rect" and "client_rect". There are 2 problems here: 1) "whole_rect" and "client_rect" do not reflect the actual state of the window, as X might not have processed the request yet. These values should at least be updated on ConfigureNotify instead which signals that X has completed (and accepted) the request. 2) Using the relative coordinates from X is not a good idea, as you do not really know where the window is at that point. Instead the same message also supplies a "x_root" and "y_root" value. I did an experiment where i used these values instead of the other to calculate the mouse coordinate. This had an amazing effect on the stability and the smoothness when moving windows in e.g. Winamp. I did have problems with the virtual desktop though, but that can probably be fixed. Apart from this i am not really sure where the is a "window_rect" and "whole_rect" as they are both overwritten with the same value every time X11DRV_WindowPosChanged() is called. As you did not like my initial attempt to fix the problem, please advise which route you would approve of. Thanks, /pedro
Re: Winamp disappears when you move it's location
On Tue, 2009-10-06 at 14:37 +0200, Peter Dons Tychsen wrote: > Hello, > > > You can do it at window creation time, but you can't > > change the window back and forth just because you want some move request > > to not be intercepted. > > > Eh? Did you read the xlib manual i linked to? This is *exactly* what > they recommend for this type of scenario: > http://tronche.com/gui/x/xlib/window/attributes/override-redirect.html OK, reading it again i must admit it does not say that they recommend changed it on-the-fly. I often read between the lines even if there is nothing there :-). It would also generate extra X traffic. Thanks, /pedro
Re: Winamp disappears when you move it's location
Hello, > You can do it at window creation time, but you can't > change the window back and forth just because you want some move request > to not be intercepted. > Eh? Did you read the xlib manual i linked to? This is *exactly* what they recommend for this type of scenario: http://tronche.com/gui/x/xlib/window/attributes/override-redirect.html > Absolutely not. Hmm... :-) So... i have investigated other ways of fixing this. Would you accept a patch that uses _NET_WM_MOVERESIZ to move the window? That might also fix the issue. That message requests the WM to move the window at not X. Thanks, /pedro
Winamp disappears when you move it's location
I am posting your response, as you are not on CC in the bug. >>You can't do that sort of thing. If you really don't want the window manager to >>control the windows there's an option for it, but you can't have it both ways. I am not sure i agree. Everywhere i looked they referred to "override_redirect" as being *the way* to control this. And doing so is totally valid. The xlib manual is very clear on this: "To control window placement or to add decoration, a window manager often needs to intercept (redirect) any map or configure request. Pop-up windows, however, often need to be mapped without a window manager getting in the way. To control whether an InputOutput or InputOnly window is to ignore these structure control facilities, use the override-redirect flag." I think this says it all... http://tronche.com/gui/x/xlib/window/attributes/override-redirect.html I also checked the source code for Metacity, which only confirmed my findings. Notes and code to support the statement above was in place. Please consider this, as it makes some apps look so much better. Thanks, /pedro
Re: oleaut - SysAllocString/SysFreeString
On Fri, 2009-10-02 at 12:56 +0200, Michael Stefaniuc wrote: > If even Windows 7 behaves that way I figure > we'll have to provide that "feature" too. Else the application is > buggy > and won't work on all Windows versions either. Even if it did not work in win-7, then it could still be worth fixing. The thing that would make it a "wont-fix" was if the fix made it directly incompatible with win-7. There is lots of old win-3.11 and win-95 software which only runs on Wine (does not e.g. run on my work-XP machine). Changing this attitude towards legacy software would be a loss as i think it attracts many to use Wine to begin with. I think the fix that Markus is brewing on is the the kind of details that makes Wine so great! :-) Thanks, /pedro
Re: Peter Dons Tychsen : user32: Add exception handling for timer callbacks.
On Thu, 2009-10-01 at 12:33 +0200, Alexandre Julliard wrote: > Peter Dons Tychsen writes: > > > Just out of interest: You changed this to a write. Fine. > > But why the volatile? Can GCC assume predetermined results when writing > > to NULL? I don't see any reason to use volatile unless someone else is > > also read/writing from NULL (which is impossible). It might just > > generate more code in some cases. > > It's just to make sure no compiler tries to be too smart. For a single > access it probably doesn't make a difference; it could change if for > instance we try to trigger a second crash and the compiler optimizes out > the first write. > Ah,OK. Thanks for the info. /pedro
Re: ntdll: Do not accept device control requests with invalid and/or incompa tible handles
Thanks V. However, it would seem that AJ already has commited another fix in ntdlls serial module (which fixes the same bug), so i guess my fix and tests are not valid any more. Thanks, /pedro - Original meddelelse - > Fra: Vitaliy Margolen > Til: Peter Dons Tychsen > Cc: wine-devel@winehq.org > Dato: Søn, 13. sep 2009 23:42 > Emne: Re: ntdll: Do not accept device control requests with invalid > and/or incompa tible handles > > Peter Dons Tychsen wrote: > > OK. The "bad handle" is tested by the "deadbeef" handle. > > Where is the best place to get a really good "wrong class" handle? > Create it. Event handle will do for example. > > Vitaliy.
Re: ntdll: Do not accept device control requests with invalid and/or incompa tible handles
OK. The "bad handle" is tested by the "deadbeef" handle. Where is the best place to get a really good "wrong class" handle? Thanks, /pedro - Original meddelelse - > Fra: Alexandre Julliard > Til: Peter Dons Tychsen > Cc: wine-devel@winehq.org > Dato: Tor, 10. sep 2009 22:20 > Emne: Re: ntdll: Do not accept device control requests with invalid > and/or incompa tible handles > > Peter Dons Tychsen writes: > > > Thanks for the comments. > > Not sure i understand them though. > > > > The whole point of the test was to test what happens when you use a > wrong > > handle. The actual bug i fixed was that it was possible to for > programs > > to send invalid handles to IoControl. Cygwin was infact sending > handles > > to ntdll.dll which originated from GetStdHandle(). > > > > So i think using this API for testing is relevant, as the point of > the > > test is to verify that handles of the completely wrong class are > > rejected, and not just "bad handles". > > Yes, but then you should explicitly construct and test both kinds of > handles. Using GetStdHandle will either be a wrong class or a bad > handle > depending on whether stdio is to a file or to a console, so you don't > really know which case you are testing. The remapping of console > handles > happens in kernel32, not in ntdll, so it doesn't really make sense to > pass the result of GetStdHandle straight to ntdll. > > -- > Alexandre Julliard > julli...@winehq.org
Re: ntdll: Do not accept device control requests with invalid and/or incompa tible handles
Thanks for the comments.
Not sure i understand them though.
The whole point of the test was to test what happens when you use a wrong
handle. The actual bug i fixed was that it was possible to for programs
to send invalid handles to IoControl. Cygwin was infact sending handles
to ntdll.dll which originated from GetStdHandle().
So i think using this API for testing is relevant, as the point of the
test is to verify that handles of the completely wrong class are
rejected, and not just "bad handles".
Thanks,
/pedro
- Original meddelelse -
> Fra: Alexandre Julliard
> Til: Peter Dons Tychsen
> Cc: wine-devel@winehq.org
> Dato: Tir, 08. sep 2009 22:25
> Emne: Re: ntdll: Do not accept device control requests with invalid
> and/or incompatible handles
>
> Peter Dons Tychsen writes:
>
> > +static void test_device_control(void)
> > +{
> > + IO_STATUS_BLOCK io;
> > + NTSTATUS status;
> > +
> > + /* Try using a bugus handle for I/O control */
> > + HANDLE handle = (HANDLE)0xdeadbeef;
> > + status = pNtDeviceIoControlFile(handle, NULL, NULL, NULL, &io,
> IOCTL_SERIAL_SET_BAUD_RATE, NULL, 0, NULL, 0);
> > + ok(status == STATUS_INVALID_HANDLE, "Expected %08X, got %08X\n",
> STATUS_INVALID_HANDLE, status);
> > +
> > + /* Try using an valid (but wrong) handle for I/O control */
> > + handle = GetStdHandle(STD_INPUT_HANDLE);
> > + status = pNtDeviceIoControlFile(handle, NULL, NULL, NULL, &io,
> IOCTL_SERIAL_SET_BAUD_RATE, NULL, 0, NULL, 0);
> > + ok(status == STATUS_INVALID_HANDLE, "Expected %08X, got %08X\n",
> STATUS_INVALID_HANDLE, status);
>
> GetStdHandle returns a console handle which is not a valid ntdll
> handle,
> so you are not testing what you think.
>
> --
> Alexandre Julliard
> julli...@winehq.org
Re: [2/3] ntdll: don't treat DOS paths starting with / as Unix paths
Hi! [I'm not subscribed, I hope I got the forged in-reply-to header right] Ben Klein wrote: > This is what I meant about magic translation. It *shouldn't* work, but > I'm aware that it does. DOS/Windows uses backslash as the delimiter > when reporting and storing paths. Is the behaviour of magic > translation from foreslash to backslash documented (by Microsoft) > anywhere? From: http://msdn.microsoft.com/en-us/library/aa365247.aspx + MSDN Library + Win32 and COM Development + System Services + File Services + File Systems + File Management + About File Management + Creating, Deleting, and Maintaining Files * File Names, Paths, and Namespaces "Note File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\\?\" prefix as detailed in the following sections." So, the Win32 API supports / BTW, people using the identity mount technique with MinGW (*) are not unlikely to have a /bin/sh on the current drive. Hmmm, but that's actually /bin/sh.exe so maybe they are safe? And I guess building mingw-gcc on Windows isn't "real work" (that's the main reason for the identiy mount, IIUC). Anyway, that's just another stab at the python test suite. Building stuff using MSYS/MinGW (or Cygwin) inside wine which requires an identity mount is surely just for fun. Anything MSYS or Cygwin inside Wine is for fun. The identity mount technique clearly does not work with Wine. Cheers, Peter (*) Google: mingw "identity mount"
