August 2004 - Wine-Devel - list.winehq.org

Re: runtime change to WINEDEBUG output

by Robert Shearman

James Hawkins wrote: >I ran WINEDEBUG=trace+all wine setup.exe 2>&1 | sed '1,/Debug mark/d' >in the terminal, and all of the debug output is being displayed >already without selecting the "Put..log" option. I switched >"Managed" to "N" at Vincent's suggestion. Any ideas? > > Try this instead: WINEDEBUG=trace+all wine setup.exe 2>&1 | sed '1,/Debug mark requested/d' It then shouldn't match against a call to the menu functions that put the debug log option into the system menu. Rob

Aug. 25, 2004

Re: runtime change to WINEDEBUG output

by James Hawkins

I ran WINEDEBUG=trace+all wine setup.exe 2>&1 | sed '1,/Debug mark/d' in the terminal, and all of the debug output is being displayed already without selecting the "Put..log" option. I switched "Managed" to "N" at Vincent's suggestion. Any ideas? On Wed, 25 Aug 2004 19:34:34 -0400, James Hawkins <truiken(a)gmail.com> wrote: > Oh ok thanks a bunch I will definitely try it out now. > > On 25 Aug 2004 19:25:19 -0400, Vincent Béron > > > <vberon(a)mecano.gme.usherb.ca> wrote: > > Le mer 25/08/2004 à 19:11, James Hawkins a écrit : > > > > > Then you just need to bring the system menu up and click on "Put 'Debug > > > > > mark' in debug log" and debugging will then start. > > > > > > I'm not exactly sure what you mean by system menu. I cant remember > > > seeing the "Put...log" anywhere. Thankyou for your help on this > > > response btw. > > > > [snip] > > > > I didn't see it when used in "Managed"="Y" mode, but with "Managed"="N" > > the option's there (Alt-space, or the icon in the top-left corner of the > > window of the app). > > > > Vincent > > > > > > > -- > James Hawkins > -- James Hawkins

Aug. 25, 2004

Re: runtime change to WINEDEBUG output

by Diego 'Flameeyes' Pettenò

Vincent Béron wrote: > I didn't see it when used in "Managed"="Y" mode, but with "Managed"="N" > the option's there (Alt-space, or the icon in the top-left corner of the > window of the app). When an app is running in Managed Mode we can access the system menu opening the first menu (usually File) and then moving to left (so the previous menu, which is the system menu :) ). -- Diego "Flameeyes" Pettenò dgp85(a)users.sourceforge.net - http://flameeyes.web.ctonet.it/

Aug. 25, 2004

Re: Patch for CreateDIBitmap: Don't create monochrome bitmaps (help wanted)

by Michael Kaufmann

Hi all, I finally managed to create a patch that fixes the bug in CreateDIBitmap and also changes all the WINE code that was relying on the wrong behavior. I'll send the patch to wine-patches in a couple of minutes. So if you intended to help, it's too late ;-) > Test Program (DIB-Testcase.zip): > --------------------------------- > > I've created a test program that shows the problem. It also shows a > bug in Windows! It displays two bitmaps, both should be black and > white. WINE displays them red on green (I've set these colors with > SetTextColor/SetBkColor). > > The images differ only in a single byte. I've used the program bmpdump > ( http://david.tribble.com/programs.html ) to analyze them. In the > color table of the bitmaps, the rgbReserved member of a RGBQUAD > structure is 0x00 for the left bitmap and 0xFF for the right bitmap. > This shouldn't make a difference. But Windows creates a monochrome > bitmap for the left one, and a color bitmap for the right one! Does > anyone understand this behavior? Now I do. CreateDIBitmap() doesn't provoke this, it's LoadImage(). This function creates a device-dependent bitmap. If it's possible, it creates a monochrome bitmap. Windows looks at the color tables to check if the two colors are really black and white. For the right bitmap, this is not the case, and so Windows creates a color bitmap. WINE will do the same with my patch applied. Regards Michael

Aug. 25, 2004

Re: Something broke winetest?

by Kevin Koltzau

I'm having the same problem On Wednesday 25 August 2004 08:12 am, Paul Millar wrote: > imagelist.o(.text+0x11ba):/home/paulm/Testing/wine-cross-source/dlls/comctl32/tests/imagelist.c:279: > more undefined references to `ImageList_DrawIndirect(a)4' follow > distcc[21076] ERROR: compile on localhost failed > make: *** [comctl32_test.exe] Error 1 > [paulm(a)quisquiliae tests]$ > > Which causes comctl32_test.exe not to be built, so the build of winetest.exe > fails. > > Do others get this too?

Aug. 25, 2004

Re: runtime change to WINEDEBUG output

by James Hawkins

Oh ok thanks a bunch I will definitely try it out now. On 25 Aug 2004 19:25:19 -0400, Vincent Béron <vberon(a)mecano.gme.usherb.ca> wrote: > Le mer 25/08/2004 à 19:11, James Hawkins a écrit : > > > > Then you just need to bring the system menu up and click on "Put 'Debug > > > > mark' in debug log" and debugging will then start. > > > > I'm not exactly sure what you mean by system menu. I cant remember > > seeing the "Put...log" anywhere. Thankyou for your help on this > > response btw. > > [snip] > > I didn't see it when used in "Managed"="Y" mode, but with "Managed"="N" > the option's there (Alt-space, or the icon in the top-left corner of the > window of the app). > > Vincent > > -- James Hawkins

Aug. 25, 2004

Re: runtime change to WINEDEBUG output

by Vincent Béron

Le mer 25/08/2004 à 19:11, James Hawkins a écrit : > > > Then you just need to bring the system menu up and click on "Put 'Debug > > > mark' in debug log" and debugging will then start. > > I'm not exactly sure what you mean by system menu. I cant remember > seeing the "Put...log" anywhere. Thankyou for your help on this > response btw. [snip] I didn't see it when used in "Managed"="Y" mode, but with "Managed"="N" the option's there (Alt-space, or the icon in the top-left corner of the window of the app). Vincent

Aug. 25, 2004

Re: runtime change to WINEDEBUG output

by James Hawkins

> > Then you just need to bring the system menu up and click on "Put 'Debug > > mark' in debug log" and debugging will then start. I'm not exactly sure what you mean by system menu. I cant remember seeing the "Put...log" anywhere. Thankyou for your help on this response btw. On 25 Aug 2004 18:40:22 -0400, Vincent Béron <vberon(a)mecano.gme.usherb.ca> wrote: > Le mer 25/08/2004 à 17:29, Robert Shearman a écrit : > > > > James Hawkins wrote: > > > > >Hi, > > > > > > Is there a way to change the trace options of WINEDEBUG during > > >runtime? > > > > > WINEDEBUG=trace+all wine setup.exe 2>&1 | sed '1,/Debug mark/d' > > > > Then you just need to bring the system menu up and click on "Put 'Debug > > mark' in debug log" and debugging will then start. I seem to remember > > that Mike Hearn submitted a patch a while ago that did exactly what you > > are asking for, but Alexandre rejected it saying that it could be done > > just as easily with external programs. I just haven't figured out how yet.... > > ReactOS taskmgr (programs/taskmgr) can do that for any channel, although > I didn't see the "all" debug channel. > > Vincent > > -- James Hawkins

Aug. 25, 2004

Re: X86/PPC linking (was Re: [Darwine] Re: Wine Emulation: Swapping functions)

by Pierre d'Herbemont

Le 26 août 04, à 00:58, Jim White a écrit : > Of course if you're planning on compiling Wine as PPC then we're on > different pages architecturally. I still believe it is the *best* way for us to go. But I agree that as a first step we can go for qemu-darwin-i386-user, that's why I am now working a bit on qemu-darwin-i386-user. Pierre

Aug. 25, 2004

Re: X86/PPC linking (was Re: [Darwine] Re: Wine Emulation: Swapping functions)

by Jim White

Pierre d'Herbemont wrote: > Le 25 août 04, à 23:01, Jim White a écrit : > >> I would really like to get away from having to write all the little >> wrappers to deal with the namespace problem. I believe we can solve >> that with a suitable naming convention as we began to do with the >> winegcc patch. > > I think we can forget this solution, loading symbol at launch time works > like a charm :) > > (BTW it was indeed winebuild which was patched) > > Pierre. While I think that dynamic binding can work, I'm concerned about calling conventions between X86 and PPC. We'll need to look into what those are and what QEMU uses. It may turn out that to get things to line up correctly and not have anything get clobbered, we might not be able to allow any intermediate calls. In which case we have to use an emulation escape so that the call can be translated as a direct native call rather than using a syscall. And in that case the indirection through the pointer is likely be a problem. Besides not having little wrappers for the namespace issue is not having to write syscalls for all the OS X API we want to use. I'ld much rather folks could just call the OS X API directly (albeit with carefully written code). Of course the advantage to going this (syscall) route is that it is easy to write and doesn't depend on esoteric compiler/linker/loader/emulator coordination. Of course if you're planning on compiling Wine as PPC then we're on different pages architecturally. Jim

Aug. 25, 2004