Re: Compiling WINE - Hopeless situation? :)
On Saturday 29 March 2003 05:50 pm, Sylvain Petreolle wrote: > If interested in any other projects response: > http://www.mplayerhq.hu/DOCS/users_against_developers.html#gcc MPlayer's problem was famously revealed by Bero as a couple of typos in their inline ASM that 2.95.x ignored. I built and ran mplayer fine with 2.96 after fixing their dumb typo and turning off their compiler detection, but Xine is much better anyway ;-) > If you think its false, telle me why the wine code doesnt compile with > 2 Mandrake machines having this version of gcc? Ask Mandrake. Wine compiles and runs fine on all Red Hat 7.x distros using 2.96. I use it daily to run some important Win32 apps :-)
Re: Compiling WINE - Hopeless situation? :)
On Saturday 29 March 2003 04:00 pm, Sylvain Petreolle wrote: > Please update gcc to version 3.x.x, gcc2.96 was a broken unofficial > version of RedHat and all dependancies must be updated too. (like > binutils) That's total FUD. There is no problem compiling and running Wine on a 2.96-based distro.
Re: wineconf 2002: final things
> Just check out http://www.lst.de/~mm/wineteam.jpg :) LOL, ok, I'll just link to yours, that's even easier :) Thanks! -Ian Schmidt Unofficial Wine Screenshots: http://wine.godmonkey.com/ [EMAIL PROTECTED]
Re: wineconf 2002: final things
On Tuesday 19 March 2002 04:49 pm, Andreas Mohr wrote: > http://home.arcor.de/andi.mohr/wine/wineconf2002/ > for the photos I took and the presentation I gave. Thanks Andreas, those are great pictures :) I've added a few cheesy "tooltips" with names that I could figure out to Andi's group picture and posted it on Unofficial Wine Screenshots. The results are from squinting at nametags in the pictures and/or comparing to peoples' homepage pictures, so errors are possible. If you're in the picture and aren't identified or are misidentified please email me directly and I'll promptly update the pic so everyone can be properly quasi-famous ;-) It's currently at http://wine.godmonkey.com/wineall.jpg -Ian Schmidt [EMAIL PROTECTED] Unofficial Wine Screenshots: http://wine.godmonkey.com/
Re: Wine license change
On Wednesday 13 February 2002 01:28 pm, Brett Glass wrote: > business. So, if the company was profitable at all, it was just squeaking > through. (And $20M in annual revenues after ten years of existence is no > one's idea of "good money" for a company that size.) Sure, but they did stay in business for 10 years and were in no reported danger of going out of it. Not bad by any metric for a license you can't make money off of ;-) Anyway to steer back toward my point, can you name any pure-BSD/X11 players that are profitable? See, I think there's a more basic problem, which is that no known business model works really well for source-available software when the software is targeted at technically savvy users. Things like the Aladdin license are a nice compromise, but ultimately won't lead to Microsoft levels of profitability. The solution as I see it is for GPL/BSD/whatever programmers to actually cough up something non-technical users not only would use, but would *prefer*. *Then* support and selling binaries becomes a worthwhile proposition. Codeweavers is leaning in this direction with CrossOver - even though you could probably duplicate their work eventually with the current Wine CVS, the installer and overall ease of use make it well worth paying for if you value your time at all (I bought it and I love it, if you can't tell). To put this back on topic, I don't see any immediate benefits from a LGPL license. If we knew what the threat to Wine Jeremy hinted at was, it might make for a more informed discussion. I also liked Gav's idea about WineCorp a lot as a compromise, and I'd love to see more dicussion of that and less licensing flaming.
Re: Wine license change
> No company that has adopted an FSF license for its main work > product has EVER thrived. Even Red Hat has lost millions. Actually, Cygnus has made good money for over 10 years doing GCC ports and paid support, and they're one of the reasons Red Hat was able to report a profit recently.
Re: Compile error on latest CVS
On Monday 01 January 2001 23:34, Francois Gouget wrote: >BTW, the compiler you're using is even more recent than the one > shipped with Redhat 7, right? Yes. It's the latest official update (gcc-2.96-69), which is quite a bit more solid in my experience than the shipping Redhat 7 version. I'll try older obj_base.h versions in the meantime, thanks for the hint. -Ian Schmidt [EMAIL PROTECTED] Unofficial WINE screenshots: http://wine.godmonkey.com/
Compile error on latest CVS
With gcc 2.96-69 (latest from up2date) on Red Hat 7 (running kernel 2.4.0-test10 and glibc 2.2) and latest CVS with no diffs: (several *hundred* similar warnings to the following 2 suppressed...) ../include/wine/obj_base.h:489:72: warning: nothing can be pasted after this token ../include/wine/obj_base.h:490:72: warning: nothing can be pasted after this token In file included from ../include/objbase.h:17, from uuid.c:17: ../include/wine/obj_moniker.h:313: parse error before `GetObject_must_be_suffixed_with_W_or_A_in_this_context' ../include/wine/obj_moniker.h:313: warning: no semicolon at end of struct or union ../include/wine/obj_moniker.h:313: parse error before `}' In file included from ../include/oleidl.h:21, from uuid.c:21: ../include/wine/obj_inplace.h:420: parse error before `GetObject_must_be_suffixed_with_W_or_A_in_this_context' ../include/wine/obj_inplace.h:420: warning: no semicolon at end of struct or union ../include/wine/obj_inplace.h:420: parse error before `}' In file included from ../include/ocidl.h:18, from ../include/olectl.h:6, from uuid.c:23: ../include/wine/obj_control.h:417: parse error before `GetClassInfo_must_be_suffixed_with_W_or_A_in_this_context' ../include/wine/obj_control.h:417: warning: no semicolon at end of struct or union ../include/wine/obj_control.h:438: parse error before `GetClassInfo_must_be_suffixed_with_W_or_A_in_this_context' ../include/wine/obj_control.h:438: warning: no semicolon at end of struct or union ../include/wine/obj_control.h:438: parse error before `}' make[1]: *** [uuid.o] Error 1 make[1]: Leaving directory `/home/irsman/wine/ole' make: *** [ole/libwine_uuid.a] Error 2 Any ideas? I was just away for 2 weeks and it was compiling and running fine before then. -Ian Schmidt [EMAIL PROTECTED] Unofficial WINE Screenshots: http://wine.godmonkey.com/
Re: Header files that conflict with UNIX headers
George Boutwell wrote: > crtdll.dll only came with the very first version of > Windows 95, all subsequent version of Win95 (A, B, C, > OSR2, OSR2a, etc) either didn't have it at all, or had > msvcrt.dll Luckily for this discussion, I had to blow away my C: partition last night and reinstall Win98 (gold retail version). It includes CRTDLL.DLL in WINDOWS\SYSTEM, dated May 11, 1998 (same as the other default system DLLs for Win98 gold retail). MSVCRT is also included of course, since Internet Explorer needs it. -Ian Schmidt [EMAIL PROTECTED]
Re: EventExpose race condition problem
gerard patel wrote: > I have tried a quick and dirty implementation of WM_SYNCPAINT and it seems > to work as you intend. I have not seen any nasty side-effect on any program I use. > Some paintings have a different order, it seems that a few splash screen are not > painted as fast as before, but no crash or obvious mis-paintings. Gerard, This patch greatly improves Visual C++'s painting behavior. Previously it had severe problems where portions of the window wouldn't paint correctly or wouldn't paint at all. Now there's one problem remaining and one new one (Both managed and unmanaged modes behaved the same). - The left strip of the editor where e.g. breakpoint icons appear still isn't right. Without the patch it never paints at all (you see whatever's behind the window). With the patch it paints properly on initial draw when you open a project, but all refreshes of the window after that revert to the old broken behavior. - The splash window doesn't appear at all now (without the patch it works fine). Still, impressive improvement for a "quick and dirty" patch :-) -Ian Schmidt [EMAIL PROTECTED]
Re: cvs.winehq.com
"Dimitrie O. Paun" wrote: > It is down again (since yesterday). > > This is becoming a big problem. I manage to squeeze a few minute weekly to > work on Wine, and most of the time the CVS server is down -- it kills the > little time I have between 1 other things I must do. I am sure I am not > the only one in this situation. Hi Dimitrie, There are 3 CVS mirrors for Wine: :pserver:[EMAIL PROTECTED]:/home/wine :pserver:[EMAIL PROTECTED]:/home/wine :pserver:[EMAIL PROTECTED]:/home/wine I've never yet seen all 3 down at once :-) -Ian Schmidt [EMAIL PROTECTED]
Re: trackbars
Serge Ivanov wrote: > Why don't you guys look into Corel's CVS. We have a lot of improvements for > most of controls including trackbar, treeview, combo/list boxes, etc. There's also the Odin trackbar backport, which Alex Priem posted twice (most recently in March) after the Odin guys agreed to dual-license it for inclusion in WINE. It made every app I tried 100% perfect, but for unknown reasons it never made it into CVS. Alexandre? :-) -Ian Schmidt [EMAIL PROTECTED]
Re: wine & glibc 2.1.3
"M.H.VanLeeuwen" wrote: > Any idea how to go about debuggin this? The workaround is to set the environment variable LC_ALL to en. For sh/bash/ash: LC_ALL=en ; export LC_ALL For csh/tcsh: setenv LC_ALL en Can we somehow autodetect this and print that as an error message? Maybe an autoconf macro? (I don't know autoconf very well unfortunately). -Ian Schmidt [EMAIL PROTECTED]
Re: NIY: loops (4294967295) in wavehdr
Matthew Toseland wrote: > So it should just play the sound once only? That should still be playable. > It starts to play the intro loop (I always thought unreal's music was midi - > but it shouldn't go through this if it did). Then it stops. I use menus, > start new game, no sound. Hence the suspicion that something drastic had gone > wrong and the code had gone into some sort of damage limitation mode. Unreal uses a varient of Impulse Tracker (.IT) for music. My guess is Unreal mixes all it's sound into a looping buffer, as per standard game-coding practice. Since the buffer doesn't loop under Wine everything grinds to a halt after 1 trip through the buffer. > OK. So why does the sound system go down? Is it possible this is a bug in my > sound driver (emu10k1 from cvs)? See above. This is Wine's fault and Wine's fault only :-) -Ian Schmidt [EMAIL PROTECTED]
Re: RH6.2
Bradley Baetz wrote: > There's no bug in bugzilla for RH. If this is the same bug, can someone > who has RH6.2 report this? (I don't have RH6.2 to check, only 6.1) Thanks for the info, Bradley. I do have RH 6.2, and I have verified that Wine crashes :-) I just submitted a bug into RH's bugzilla system for the problem so hopefully they'll get some fix RPMs out soon. -Ian Schmidt [EMAIL PROTECTED]
Re: RH6.2
Jon Masters wrote: > err:seh:EXC_DefaultHandling Unhandled exception code c005 flags 0 > addr 0x407cc625 Could whoever's doing the FAQ please add something about this before we're innundated in this question (the newsgroup already has been). The workaround du jour: (the bash version might be wrong, but nobody on the newsgroup bothered to correct me yet ;) (t)csh: setenv LC_ALL en (ba)sh: LC_ALL=en ; export LC_ALL Also, has Cygnus released an updated version of glibc with this bug fixed yet? -Ian Schmidt [EMAIL PROTECTED]
Re: What's going on with CVS
Ove Kaaven wrote: > On Sat, 25 Mar 2000, Ian Schmidt wrote: > > I had a similar problem last night - despite floods of cvs commit emails coming > > in, cvs update from cvs.winehq.com would not touch any files. I updated from > > Andreas' mirror ([EMAIL PROTECTED]) and the files updated properly, > > so you might try that. > > And did you try waiting a while? cvs.winehq.com only updates from > commit.winehq.com every 10 minutes, if I remember right. Yup. I gave it 30 minutes after the emails stopped, still no go. -Ian Schmidt [EMAIL PROTECTED]
Re: What's going on with CVS
Uwe Bonnes wrote: > Despite my tree not being updated for some days, cvs doesn't give me > that change (neither for dlls/ole32/ifs.c nor for any other of the > recent commits): I had a similar problem last night - despite floods of cvs commit emails coming in, cvs update from cvs.winehq.com would not touch any files. I updated from Andreas' mirror ([EMAIL PROTECTED]) and the files updated properly, so you might try that. -Ian Schmidt [EMAIL PROTECTED]
Re: Testing Wine with Programming Windows 95
Steven Elliott wrote: > Is this because the original code in the book is not redistributable? > Maybe the publisher would be willing to make an exception for Wine. It > would be nice if what you did could be included in the "libtest" > directory. The original code is not redistributable, and the publisher is Microsoft Press. Computing the odds of their making an exception for Wine is left as an exercise for the reader ;-) As for Win32 test apps in Perl, I imagine they could be useful for a lot of things. Even if they don't fit into Francois' test suite you could always create your own Perl-based suite (and indeed this might be useful on it's own - multiple Windows language test suites can only help). Unfortunately the preliminary address separation patch breaks more of Visual C++ than it fixes or I'd be doing some MFC-based Wine tests about now :-) -Ian Schmidt [EMAIL PROTECTED]
Re: COREL: trackbar
Whatever happened to the much more complete trackbar fix from the Odin project? I tried the patch at the time it was posted and it made trackbars *perfect*, but apparently there was some problem with the license. I was under the impression the licence problem has since been resolved, but the trackbar patch was never applied or resubmitted. -Ian Schmidt [EMAIL PROTECTED]
[OT] Applix FUDs Wine
A lovely quote: "The added layer of Wine code--an open source implementation of Windows 95/Microsoft Windows NT application programming interfaces--causes native Windows applications to run more slowly and with less stability on Linux, says Richard Manly, director of product marketing for Applix." http://www.pcworld.com/pcwtoday/article/0,1510,15139,00.html Also in the comments on Linux Today, it appears Corel has switched gears and will now ship PE binaries as their final product. That's pretty discouraging for WineLib - could we get a post-mortem from someone at Corel? -Ian Schmidt [EMAIL PROTECTED]
