Lostwages updates
There have been a few patches submitted to lostwages over the past few weeks that are still uncommitted. Are you still on vacation Jeremy? Should we resend? Thanks, Scott Ritchie
Re: another build problem on current cvs
Le sam 01/01/2005 à 09:20, Andreas Mohr a écrit : [snip] > 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. Right. > > Configure check, anyone? To disable Alsa if alsa 0.9x headers are detected? I don't have either 0.9.x or 1.0 here, so I'd prefer somebody who has at least one of them to change configure.ac. Vincent
Re: Approving of the WINEprobe initiative
On Dienstag 21 Dezember 2004 05:46, Brian Vincent wrote: > On Mon, 20 Dec 2004 19:13:00 +0100, David Gümbel > <[EMAIL PROTECTED]> wrote: > > Jep, its actually a pun: WINEprobe means be something like WINEtasting > > in english an maybe "degustation de WINE" in french. It's a little hard > > to translate puns, sorry ;) Maybe this is helpful: > > http://dict.leo.org/?search=weinprobe > So as far as official endorsement.. I'm sure someone in the Wine > community will speak up if they disagree with anything. (Conversely, > they won't speak up if they agree.) The three projects you mentioned > all sound great and they're things that really should be worked on. As the feedback has been IMO very positive (well, if we abstract over certain implications of the name of the initiative in english ;) and nobody came up with objections, I now consider it safe to say this initiative is being approved of by the Wine community. I wanted to thank everybody who provided feedback and comments. Plus, a happy new year to all of you! Bye, David pgpZAqqEOIcpA.pgp Description: PGP signature
Re: December 2004 - more patches than you can shake a stick at
Rein Klazes wrote: On Sun, 02 Jan 2005 14:57:27 +, you wrote: Being the patch fetishist that I am, I couldn't help noticing that in December 2004 we cleared 8mb of patches: that's by far the largest since the current archives began in October 2000. For those that like such statistics: http://home.wanadoo.nl/wijn/wine/cvssize.png Rein. Am I the only one who thinks that trend line isn't up to date? :p
Re: Debugging mingw applications using wine
Dimitrie O. Paun a écrit : On Sun, Jan 02, 2005 at 11:35:07AM +0100, Eric Pouech wrote: winedbg using the gdb won't work here because (likely on unix) gdb isn't compiled with proper 'stabs in PE' support Maybe we should lobby people (like Fedora) to enable it by default. but this would require teaching gdb to use winelib too A+
Re: spy.c in debug output
On Sun, Jan 02, 2005 at 04:47:41PM +, Mike Hearn wrote:
> Perhaps we could provide a Wine specific API and then an inline
> function that does a GetProcAddress on it, and if it's missing just passes
> the number straight through.
Right. A default implementation could be just:
wine_dbg_sprintf("%x", msg);
Anyway, it would be way cool if we could use the nice dumping
functions from spy.
We should be exporting a
wine_dbg_msg_{enter,exit}()
that we could use them nicely in our window procs.
In fact, I don't think it's feasible to return a string
(the max buffer is probably not big enough), we should just
dump the output automagically to the correct channel, so maybe
a better name would be:
wine_dbg_msg_{enter,exit}_dump()
Hmm, it needs a bit more thought, we also need a calling
macro to hide the channel business:
TRACE_MSG_ENTER()/TRACE_MSG_EXIT()
--
Dimi.
Re: spy.c in debug output
On Sun, Jan 02, 2005 at 05:22:43PM +0100, Eric Pouech wrote: > because they are not exported as regular APIs from user32, and we must > stick to what the Win32 API provides for inter DLL calls True, but they are useful. Maybe we can move them to libwine, or do a trick of sorts with GetProcAddress(). -- Dimi.
Re: Debugging mingw applications using wine
On Sun, Jan 02, 2005 at 11:35:07AM +0100, Eric Pouech wrote: > winedbg using the gdb won't work here because (likely on unix) gdb isn't > compiled with proper 'stabs in PE' support Maybe we should lobby people (like Fedora) to enable it by default. -- Dimi.
Re: December 2004 - more patches than you can shake a stick at
On Sun, 02 Jan 2005 14:57:27 +, you wrote: > Being the patch fetishist that I am, I couldn't help noticing that in > December 2004 we cleared 8mb of patches: that's by far the largest since > the current archives began in October 2000. For those that like such statistics: http://home.wanadoo.nl/wijn/wine/cvssize.png Rein.
Re: spy.c in debug output
On Sun, 02 Jan 2005 17:22:43 +0100, Eric Pouech wrote: > because they are not exported as regular APIs from user32, and we must stick > to > what the Win32 API provides for inter DLL calls Perhaps we could provide a Wine specific API and then an inline function that does a GetProcAddress on it, and if it's missing just passes the number straight through. That way there are no hard dependencies between the DLLs but when run using Wine user32 the traces are more helpful. Thoughts? thanks -mike
Re: December 2004 - more patches than you can shake a stick at
On Sun, 2005-01-02 at 17:07 +0100, Maxime Bellengà wrote: > Happy new year everybody ! > > In your list, you forgot your big work on systray. Do you see in your > crystal ball if/when it will be merged ? We'll see ;) Every so often I do a sprint on that patch, and each time it gets a bit closer to what Alexandre wants. The main problem is that I don't actually know what his vision for this code is, he never spells it out. So each time I improve it a few times but it's still not good enough, and I get bored/frustrated and move onto something else. I'll probably return to it in a few months. If somebody else wants to run with it of course they are welcome to do so. thanks -mike
Re: spy.c in debug output
Vitaly Lipatov a écrit : Can anyone tell me why we can't use functions from windows/spy.c for debugging purposes (in TRACE output) in any dlls/ modules? because they are not exported as regular APIs from user32, and we must stick to what the Win32 API provides for inter DLL calls A+
Re: December 2004 - more patches than you can shake a stick at
Happy new year everybody ! In your list, you forgot your big work on systray. Do you see in your crystal ball if/when it will be merged ? thanks Max On Sun, 2005-01-02 at 14:57 +, Mike Hearn wrote: > Happy new year everybody! > > Being the patch fetishist that I am, I couldn't help noticing that in > December 2004 we cleared 8mb of patches: that's by far the largest since > the current archives began in October 2000. > > The extra traffic came from a lot of places: > > - Huge improvements to the Application Database. > > - The number was also pushed higher by an MSI merge from CodeWeavers. > > - Some big janitorial patches went in from Michael Stefaniuc > > - Finally Rob and I were cranking out DCOM patches, and there are of >course lots more in the pipeline. > > Now time for some crystal ball gazing. Here are some interesting patches > we might be seeing in 2005: > > - Completion of the WM rewrite work. Alexandre seems to be making great >progress on this, which will let us fix many of the odd visual >corruption problems we've been plagued with for so long. It'll also >let us remerge Alexs winedesktop patch, giving us a real desktop window >that is used for all apps, at last. > >It should have many other benefits too: fixing the flickering in >the Half Life menus and allowing us to support the NETWM fullscreen >protocol. This should let us resolve many instances of the "my game >starts but I can't type" problem. > > - Lots more DCOM code. Huw Davies is hacking on getting widl to produce >a stdole32.tlb file, once that's in we can start really nailing >InstallShield to the wall. We will hopefully get this and the >thread-affinity patches in the next few months, which should mean >for the first time we can run InstallShield 6 installers perfectly, out >of the box. > >Support for newer InstallShields will come as time permits of course. > > - More MSI improvements! CodeWeavers are continuing to work on >this so it should develop nicely even though the iTunes installer >work has been completed. Office 2003 will also motivate this. It's >being used by at least one commercial app porting project as well. > > - Support for running Winelib apps directly, so we can get rid of the >.exe.so extensions/shell wrapper scripts, and produce "raw" ELF >binaries. They'll still need the wine loader app to be present of >course, but it should all be invisible and behind the scenes. Vincent >Beron and I have been working on this in the last week or so, and we >just need to finish it off and convince Alexandre the extra assembly >is worth it! :) > > Who knows what the new year will bring? More apps working out of the box, > that's for sure! Have fun! > > thanks -mike > > >
spy.c in debug output
Can anyone tell me why we can't use functions from windows/spy.c for debugging purposes (in TRACE output) in any dlls/ modules? -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru
Re: `__ctype_b' .. `__ctype_toupper'
On Sun, 02 Jan 2005 15:37:57 +0100, Dietrich Teickner wrote: > I have updated to suse 9.1. After them I have this error. > Where must be this definitions ? Those symbols are for thread-local locales, a feature we don't need but that glibc gives us anyway. To fix it you need to either use RPMs built for the exact version of the distro you're running, or you need to compile Wine yourself from the source. Hope that helps. thanks -mike
December 2004 - more patches than you can shake a stick at
Happy new year everybody! Being the patch fetishist that I am, I couldn't help noticing that in December 2004 we cleared 8mb of patches: that's by far the largest since the current archives began in October 2000. The extra traffic came from a lot of places: - Huge improvements to the Application Database. - The number was also pushed higher by an MSI merge from CodeWeavers. - Some big janitorial patches went in from Michael Stefaniuc - Finally Rob and I were cranking out DCOM patches, and there are of course lots more in the pipeline. Now time for some crystal ball gazing. Here are some interesting patches we might be seeing in 2005: - Completion of the WM rewrite work. Alexandre seems to be making great progress on this, which will let us fix many of the odd visual corruption problems we've been plagued with for so long. It'll also let us remerge Alexs winedesktop patch, giving us a real desktop window that is used for all apps, at last. It should have many other benefits too: fixing the flickering in the Half Life menus and allowing us to support the NETWM fullscreen protocol. This should let us resolve many instances of the "my game starts but I can't type" problem. - Lots more DCOM code. Huw Davies is hacking on getting widl to produce a stdole32.tlb file, once that's in we can start really nailing InstallShield to the wall. We will hopefully get this and the thread-affinity patches in the next few months, which should mean for the first time we can run InstallShield 6 installers perfectly, out of the box. Support for newer InstallShields will come as time permits of course. - More MSI improvements! CodeWeavers are continuing to work on this so it should develop nicely even though the iTunes installer work has been completed. Office 2003 will also motivate this. It's being used by at least one commercial app porting project as well. - Support for running Winelib apps directly, so we can get rid of the .exe.so extensions/shell wrapper scripts, and produce "raw" ELF binaries. They'll still need the wine loader app to be present of course, but it should all be invisible and behind the scenes. Vincent Beron and I have been working on this in the last week or so, and we just need to finish it off and convince Alexandre the extra assembly is worth it! :) Who knows what the new year will bring? More apps working out of the box, that's for sure! Have fun! thanks -mike
Re: `__ctype_b' .. `__ctype_toupper'
On Sun, Jan 02, 2005 at 03:37:57PM +0100, Dietrich Teickner wrote: > Hi, > > I have updated to suse 9.1. After them I have this error. > Where must be this definitions ? > > Dietrich > > ../../libs/libwpp.a(y.tab.o)(.text+0x2827): In function `combine_mtext': > /home/sao2l02/Wine/wine/libs/wpp/./ppy.y:626: undefined reference to > `__ctype_b' > > ... > ../../libs/libwpp.a(lex.yy.o)(.text+0x3051):/home/sao2l02/Wine/wine/libs/wpp/./ppl.l:1078: > > undefined reference to `__ctype_b' > ../../libs/libwpp.a(lex.yy.o)(.text+0x3bfe): In function `is_c_h_include': > /home/sao2l02/Wine/wine/libs/wpp/./ppl.l:1411: undefined reference to > `__ctype_toupper' > collect2: ld returned 1 exit status Did you recompile wine after the version upgrade? run make clean make depend make Ciao, Marcus
`__ctype_b' .. `__ctype_toupper'
Hi, I have updated to suse 9.1. After them I have this error. Where must be this definitions ? Dietrich ../../libs/libwpp.a(y.tab.o)(.text+0x2827): In function `combine_mtext': /home/sao2l02/Wine/wine/libs/wpp/./ppy.y:626: undefined reference to `__ctype_b' ... ../../libs/libwpp.a(lex.yy.o)(.text+0x3051):/home/sao2l02/Wine/wine/libs/wpp/./ppl.l:1078: undefined reference to `__ctype_b' ../../libs/libwpp.a(lex.yy.o)(.text+0x3bfe): In function `is_c_h_include': /home/sao2l02/Wine/wine/libs/wpp/./ppl.l:1411: undefined reference to `__ctype_toupper' collect2: ld returned 1 exit status make[2]: *** [widl] Fehler 1 make[1]: *** [widl] Fehler 2 make: *** [tools] Fehler 2
Re: oleaut.c small change to former patch an some more
On Sat, Jan 01, 2005 at 04:25:34PM +0100, Dietrich Teickner wrote: > Hi Alexandre, > > I have some problems with SysReAllocStringLen in Odin(wine for os/2) and > the win32 MySqlQueryBrowser.exe. And I thing wine will have some times > the same. I thing we can / need no memcpy, if str and old the same > before realloc. We can reset the source (str) to NULL in this case. This > should solve the problem for wine and odin. While we do not really need memcpy here, I think we should understand the real problem you see. Is there any problem? What exactly is not working? (explaining what you do in Mysqlquerybrowser is ok, I have it running here.) Your patch would not handle a potential truncation if the "len" parameter is changed, right? Can you provide a testcase snippet for dlls/oleaut32/tests/vartype.c::test_SysReAllocStringLen() that shows different behaviour between real Windows and WINE? Ciao, Marcus
Re: Debugging mingw applications using wine
Bryce McKinlay a écrit : 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. winedbg using the gdb won't work here because (likely on unix) gdb isn't compiled with proper 'stabs in PE' support you can either: - use bare winedbg (without gdb support) - recompile gdb with 'stabs in PE' support (ie the settings used when compiling gdb under windows) I tried your exe with latest cvs and it load just fine in winedbg (with and without gdb support) I don't know what the unknown stabs type are for. They aren't defined in latest gdb (6.3), the only trace I found was for the MacOS/X but I doubt it concerns your case. A+
