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

Re: Wine, Mozilla & IE ?

by Dimitrie O. Paun

On January 10, 2003 02:07 pm, Francois Gouget wrote: > and FreeType breaking backwards compatibility in minor releases, but if > ISVs also have to deal with g++ changing their ABI on a regular basis... A valid concern. But it should be a configure option (--with[out]-khtml), so they can easily disable if need be. Anyway, people should not need to ship an embedded Wine. With a bit of luck, we will ship a 0.9 this year, (and hopefully 1.0), it should be like glibc soon :). Besides, the interface to _Wine_ is always C, it doesn't matter that Wine uses C++ internally. If there are compatibility concerns, we just statically link -lstd++, and be done with it. -- Dimi.

Jan. 10, 2003

Re: Wine, Mozilla & IE ?

by Francois Gouget

On Fri, 10 Jan 2003, Dan Kegel wrote: [...] > I don't know the particulars, but I do know that g++'s > ABI only very recently stabilized. ^^^^^^^^^^^^^^^^^^^^^^^^ Isn't that a contradiction in terms? [...] > (There was one little ABI tweak between 3.2 and 3.3, > and there may be more later, but they probably > won't break many apps.) That too seems incompatible with something declared 'stable'. Not that I have anything against C++, I like OO programming. But these g++ compatibility issues have been like a cold shower. <rant class="my opinion only"> >From the point of vue of an ISV, distributing a Wine binary is already enough trouble with the C library changing their internal implementation (which of course they are absolutely free to do since it's *internal*) and FreeType breaking backwards compatibility in minor releases, but if ISVs also have to deal with g++ changing their ABI on a regular basis... Well, I guess ISVs could always compile these libraries with Visual C++ and ship them as Windows dlls and thus benefit from a stable and Wine compatible ABI... </rant> -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

Jan. 10, 2003

Re: Wine, Mozilla & IE ?

by Dan Kegel

Dan Kegel wrote: > With gcc 3.2 and later, shared libraries > produced by g++ will have a stable ABI, > and different machines (with different versions > of gcc >= 3.2) will produce compatible shared libraries. I forgot to mention: this also means that you can mix and match shared libraries produced by *other* c++ compilers, not just gcc! See http://www.linuxbase.org/spec/refspecs/ http://www.codesourcery.com/cxx-abi/ http://www.armdevzone.com/EABI/CppABI.html http://gcc.gnu.org/gcc-3.2/c++-abi.html http://www.intel.com/software/products/compilers/clin/clinux.htm and, for a bit of solaris history wrt c++ abis, http://forte.sun.com/s1scc/articles/CC_abi/CC_abi.html -- Dan Kegel Linux User #78045 http://www.kegel.com

Jan. 10, 2003

Re: Wine, Mozilla & IE ?

by Dimitrie O. Paun

On January 10, 2003 06:45 am, Ender wrote: > The current state of my local tree, besides being a mess, is that it has > most QT dependencies removed. Currently it uses a lot of QT stub's around > WinAPI functions that I wish to remove before doing much more work with > it. Ender, you may be right that we might have to integrate something into the tree. Nonetheless, it scares me shitless! What happens 3 mo, 1 year down the road? KHTML is very much a work in progress, who's gonna track it? We don't have any richedit control, heck even our bog standard edit box is not finished! And for how many years now?!? Just for curiosity's sake, can you give us a wc -l of the KHTML stuff? If we do have to integrate something, I think we *have* to have a way to track the KHTML development. Just throwing something in the tree may actually be detrimental, if it remains unmaintained. To be able to track the KHTML development, we need to keep track of the revisions we worked off of, and we have to avoid touching their sources. To this end, I think we are much better off by implementing a QT subset: -- It should be a lot stabler than the KHTML stuff. It seems to me QT hasn't change that much from the 1.0 days, now it should be close to a libc in terms of interface stability. -- I haven't looked, but I assume KHTML can't use that many difficult to implement QT features -- Having a free QT/Windows implementation is generally useful to a lot of people, so we're likely to get more people to help If our changes to the KHTML source are minor, I am certain the KDE people will help us by integrating them upstream. If in time we can work off of the same code base, we can simply delete our copy from the Wine tree. There might be another way. Now that Safari is out and it's deQTfied, and having more and more people interested in KHTML, the KDE folk may decide to officially switch to a QT-free KHTML version, in which case we'll be saved the trouble of implementing a WQT (pronounced wicked :)). -- Dimi.

Jan. 10, 2003

dx8 Patches - Question

by Ann and Jason Edmeades

Just a question, I noticed some of the dx8 patches are not applied - Is it due to the Chrismas backlog where Alexander took a very well deserved break, or because they have slipped through the cracks (or are there problems with them)? Will it help to resubmit them based off the current cvs since there were about 4 chained together each based off the previous one? Jason

Jan. 10, 2003

Re: Clean up OSS_Wave{In,Out}Init

by Eric Pouech

Francois Gouget wrote: > > This modifies OSS_Wave{In,Out}Init to report the exact capabilities of > the OSS driver. The new code does not try to use SNDCTL_DSP_SETFMTS > since some (old) cards may support 16bit or stereo audio at some sample > rates but not other (higher) rates. It now also reports the 48kHz and > 96kHz formats if they are supported. given the susceptibility of some OSS implementations, I'd suggest reimplementing the test loop as: for fmt for channels for rates if open succeeds 1/ flag format as supported 2/ close device endif endfor endfor endfor this would also put us out of danger if the device doesn't accept changing its mode on the fly A+ -- Eric Pouech

Jan. 10, 2003

Re: widl patch

by Greg Turner

On Wednesday 08 January 2003 02:53 pm, Ove Kaaven wrote: > I've been wondering if perhaps MSVC-type __try/__except > support can be done on gcc by taking advantage of gcc's support for > nested functions. I have a prototype of this and I think it's going to work. Patches (or at least RFC's) should be forthcoming.... -- gmt "If everyone is thinking alike then somebody isn't thinking." --George S. Patton

Jan. 10, 2003

Re: [RFC] msvcrt: defines break C++ code

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> writes: > OK, but what do we do now about those defines? I think making them inline functions should work for now. -- Alexandre Julliard julliard(a)winehq.com

Jan. 10, 2003

Re: wine/dlls/comcat regsvr.c comcat_main.c

by Dimitrie O. Paun

On January 10, 2003 12:48 am, John K. Hohm wrote: > + CLSID const *clsid; /* NULL for end of list */ [...] > + { NULL } /* list terminator */ Why not terminate the list with a NULL pointer to the struct instead, it's simpler and more idiomatic... -- Dimi.

Jan. 10, 2003

Re: Kaleidagraph demo

by Mike Hearn

> There are quite a few things that cause the app to crash or draw windows in a > funny way. Once the app is slighlty useable, I can list more bugs. Yeah, I just tried it. Clearly not happy at all. I'm getting lots of errors saying it didn't call BeginPaint in a WM_PAINT handler, which iirc is a bug in the app? I think you're always supposed to call BeginPaint when you receive a WM_PAINT message at some point (unless it's actually a bug in the wine controls library). It doesn't run at all with the latest version of CrossOver, with the Dec 19th release it runs but with lots of nasty bugs. I don't see the menu duplication error though. When I got that automated email from Synergy I replied telling them about Wine, maybe they'd be willing to help it run. Oh well, here's to dreaming :) BTW I am very much a newbie Wine developer so I can probably give hints only. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

Jan. 10, 2003