January 2005 - Wine-Devel - list.winehq.org

Re: Debugging mingw applications using wine

by Scott Ritchie

On Sat, 2005-01-01 at 18:04 -0800, Scott Ritchie wrote: > On Sat, 2005-01-01 at 17:53 -0500, Bryce McKinlay wrote: > > I've attached the mingw-compiled C binary. Is it worth trying again with > > a newwer WINE? Thanks! > > > > Always! > > -Scott Ritchie Wait, I need to correct myself: NOT ALWAYS. There was a horrible bug in winelib that prevents compiling anything in the last release. Heh, sorry. For now I recommend either CVS or waiting for a week or two for the next release. And, uh, I also recommend we go to a stable release system sooner rather than later :) -Scott

Jan. 2, 2005

Re: Debugging mingw applications using wine

by Scott Ritchie

On Sat, 2005-01-01 at 17:53 -0500, Bryce McKinlay wrote: > WINE is wine-0.20040914-1.rhfc2.nr from newrpms.sunsite.dk Did you try the newer rpms on Wine's download page? One was probably built for the same setup you're using. > I've attached the mingw-compiled C binary. Is it worth trying again with > a newwer WINE? Thanks! > Always! -Scott Ritchie

Jan. 2, 2005

Re: ptrace single-stepping change breaks Wine

by Daniel Jacobowitz

On Fri, Dec 31, 2004 at 09:19:48AM -0800, Linus Torvalds wrote: > > > On Fri, 31 Dec 2004, Daniel Jacobowitz wrote: > > > > Lots, I like it. The syscall trap will always be delivered before the > > single-step trap, right, because signal delivery won't run until we > > return to userspace? > > Yes. Although I've not actually tested it. > > Before, it used to show up as one event, and basically the "0x80" marker > got lost, so effectively the "system call exit" part would have got lost. > Now, it _may_ DTRT, with the caveat that the system call ptrace_notify() > thing still has the same problem with restarting-with-a-signal. > > That's basically a "don't do that then", and is the status quo, of course, > so this is at least not a regression. It's still pretty ugly, but > apparently nobody really cares ;) Yes. At some point, I'd like to make that an error - if you want to restart with a signal, don't do it from the notification points where it doesn't make sense (exit, fork, vfork-done, syscall). Send a signal by hand, and then resume, and if you want to fudge the siginfo you can do that when stopped in the signal delivery path. -- Daniel Jacobowitz

Jan. 1, 2005

Debugging mingw applications using wine

by Bryce McKinlay

I'm trying to debug a windows .exe built with mingw using wine, but winedbg seems to have problems reading stabs from the mingw-built binary. My goal is to be able to debug a cross-compiled, native Java (GCJ) application, but even a simple C "hello world" seems to cause problems. My cross-build environment consists of: - mingw-runtime-3.5 and w32api-3.1from mingw.org - I just used the pre-built binaries - stock binutils 2.15, configured with --target=mingw32 - CVS head gcc 4.0, configured with --target=mingw32 WINE is wine-0.20040914-1.rhfc2.nr from newrpms.sunsite.dk $ mingw32-gcc hello.c -o hello-mingw.exe -g $ wine ./hello-mingw.exe Hello World $ winedbg --gdb ./hello-mingw.exe 0000000a:0000000b: create process 'D:\tests\hello-mingw.exe'/0x77bd003c @00401220 (0<0>) wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0xb6e4d174 in 32-bit code (0x657997a3). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:657997a3 ESP:5b56bc7c EBP:5b56ed78 EFLAGS:00210246( - 00 -RIZP1) EAX:b6e4d174 EBX:151409b8 ECX:00000000 EDX:261955dc ESI:00000000 EDI:b6e4d174 Stack dump: 0x5b56bc7c: 15135de8 b6e4d174 00000002 00010000 0x5b56bc8c: 00000000 00000000 00000000 00000000 0x5b56bc9c: 00000000 00000000 00000000 5b56cd6c 0x5b56bcac: 00000001 00000000 00000000 00000000 0x5b56bcbc: ffffffff ffffffff 00000000 7fc07000 0x5b56bccc: 7fc06000 00010000 7f980078 000000d5 Backtrace: =>1 0x657997a3 (0x5b56ed78) 2 0x15132ec0 (0x5b56edc8) 3 0x1513371c pe_load_debug_info+0x16c in dbghelp (0x5b56ee04) 4 0x1513391a pe_load_module+0x1ba in dbghelp (0x5b56ef54) 5 0x1512d93e SymLoadModule+0x9e in dbghelp (0x5b56ef94) 6 0x15129fd3 (0x5b56f4d8) 7 0x1512a129 SymInitialize+0x119 in dbghelp (0x5b56f518) 8 0x6101906a (0x5b56f650) 9 0x6101cfba (0x5b56f8e4) 10 0x6101d39a (0x5b56f970) 11 0x6101d422 gdb_remote+0x32 in winedbg (0x5b56fe44) 12 0x610279ec main+0x11c in winedbg (0x5b56fe90) 13 0x610122f1 (0x5b56ff20) 14 0x4824e0e2 (0x5b56fff4) 15 0x43940f31 (0x00000000) .... I've attached the mingw-compiled C binary. Is it worth trying again with a newwer WINE? Thanks! Bryce

Jan. 1, 2005

loading native binaries

by Ivan Leo Puoti

Alexandre, your patch doesn't perform relocation, and this causes and access violation in secdrv.sys To perform relocation, we need to be able to write to memory, but there appears to be some sort of problem with this that causes wine to hang. I'm attaching your original patch, plus an updated one that Laurent Pinchar and I have come up with, it should work *in theory*, but it doesn't. Laurent has suggested that maybe it would if the image was aligned to a page boundary, but I'm to tired to look into it now. I'm cc'ing wine-devel, ideas/patches welcome. Ivan.

Jan. 1, 2005

Re: Remove heap.h

by Dimitrie O. Paun

On Sat, Jan 01, 2005 at 07:47:11AM -0800, Jon Griffiths wrote: > >Because in 99.99% of cases you don't want to convert from W->A. > >If all our functions are Unicode, a W->A conversion is a warning > >sign, and for sure you wouldn't want to encourage people to do > >so by making it any easier. > > winapi_check will allready tell us all cross-calls anyway, doesn't it? > It may be years before all the a to w conversions are done and we are > 100% internally unicode, why live with a non standard header that long? Because it provides more reason for fixes. If we make everything tidy, those problems are less likely to get fixed. It's been a long standing policy, I doubt that Alexandre will change it. But, then again, he will make the final call. -- Dimi.

Jan. 1, 2005

Re: Remove heap.h

by Jon Griffiths

Hi, >>+ docA.lpszDocName = WtoA( doc->lpszDocName ); >>+ docA.lpszOutput = WtoA( doc->lpszOutput ); >>+ docA.lpszDatatype = WtoA( doc->lpszDatatype; >> >Isn't there a missing parenthesis? There sure is, I must have deleted it while removing the cruft from the diff (since it compiles fine on my box at home :). I'll resubmit. (Dimitrie) >Because in 99.99% of cases you don't want to convert from W->A. >If all our functions are Unicode, a W->A conversion is a warning >sign, and for sure you wouldn't want to encourage people to do >so by making it any easier. winapi_check will allready tell us all cross-calls anyway, doesn't it? It may be years before all the a to w conversions are done and we are 100% internally unicode, why live with a non standard header that long? Cheers, Jon ===== "Don't wait for the seas to part, or messiahs to come; Don't you sit around and waste this chance..." - Live jon_p_griffiths(a)yahoo.com __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com

Jan. 1, 2005

Re: another build problem on current cvs

by Andreas Mohr

Hi, On Wed, Dec 29, 2004 at 06:42:41PM -0500, Vincent Béron wrote: > Le mer 29/12/2004 à 05:38, Joris Huizer a écrit : > [snip] > > In debian the package is called libasound2-dev, version > > "0.9.0beta10.9.0beta1" which should be the 0.9 branch of alsa > > I thought we stopped supporting alsa 0.9 a while ago to focus on alsa > 1.0... > > (Looking through dlls/winmm/winealsa/audio.c's changelog, it's been that > way since snapshot 20040505). > > The two versions use the same function names but with different number > of args (hence the problems which you saw). > > Either update to alsa 1.0, downgrade Wine to prior 20040505, or switch > to the wineoss driver. Problem is that we might want to have Wine never break during compile. At least for semi-modern software versions it should compile successfully, no matter how much functionality we have to disable to achieve that. Configure check, anyone? Andreas Mohr

Jan. 1, 2005

Jumbo Mail - fireworks

by puoti＠inwind.it

Ciao, questa è una Jumbo Mail, che puoti(a)inwind.it ti ha inviato per condividere con te * video.zip (119256515 byte) e questo messaggio: -------------------------------------------------------------------------------- Greetings and Happy New Year from the Sorrento Peninsular. I've just finished taking this film of the New Year firework celebrations still going on all around. I took this film from our terrace, I hope you enjoy it. The file is big, 113MBs, so I don't recommend downloading it if you don't have broadband. The download link will expire in 7 days. Happy New year to all, Ivan. -------------------------------------------------------------------------------- Per scaricare questi files fai click sul seguente link: http://webmail.inwind.it/r.php?d=inwind.it&wr=_unreg_4eh3943v&ws=3850nl9t&e… Ti ricordiamo che questo link sarà valido fino al 08.01.2005 alle 07:23. Jumbo Mail è il servizio di Libero Mail che permette di condividere file di grandi dimensioni fino a 1GB, senza problemi di superamento dei limiti delle caselle e-mail. Scopri come è semplice e veloce inviare una Jumbo Mail! Fai click su http://liberomail.libero.it/jumbomail.phtml Lo staff di Libero

Jan. 1, 2005