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

Wine, WIDE & Unix (was: Support for pkgconfig)

by Dimitrie O. Paun

On April 19, 2003 05:44 pm, Francois Gouget wrote: > So I would rather put efforts into making sure Gtk, Gnome, KDE and QT > are suitable solutions. Really? Do people think that KDE & QT would be a more suitable solution? Do *anyone* here think that KDE & QT are a better alternative then WIDE for Linux as a _platform_?!? Newsflash: QT is GLPed. KDE depends on QT. If you want to develop non-GPL apps on Unix using KDE/QT, you have to pay thousands of dollars to Troll Tech for each developer. Is this the _free_ platform we want to build? You can develop apps for free on Windows (see MinGW, Borland, OpenWatcom), or for a small price buy MSVC, yet you'll have to pay through the nose on our free OS! Isn't that fantastic? And the best part is that we give the Trolls complete monopoly, whereas they can do what they want to the price in the future. We trade the (very little) control that MS has over Win32, with the big one that Trolls have over QT. Splendid! So, can someone please tell me a *single* advantage of having KDE & QT as the GUI platform for Linux vs. having WIDE? I have waited with this message a week to calm down, but I didn't :) so I have to say what I have to say. You guys rave about the big, bad, bloated, ugly Win32 messing up the nice Unix GUI API. WTH are you guys talking about? There's no traditional Unix GUI API! You want bad, bloated, and ugly? Fine: -- ugly: Xaw, what can I say? -- bloated: Motif, it's good it's dead. -- bad: QT, can you spell non-free? So the _only_ viable Unix GUI API is GTK/GNOME. But version 2 of that API came out only a year ago, and Evolution is not even ported to it! Do you consider that traditional? It's so new it's not even funny. And maybe that's fine, but the problem is that they lost steam: at the moment it seems that most development is done by RedHat, Ximian, and Sun. And it's going slow. The two platforms (GNOME and KDE) seem to diverge more and more, and if you look asymptotically, do you see a bright, integrated future? I don't think that WIDE is the greatest idea since slice bread. It's just something I thought of as a possibility during the discussion, and I threw it in there as a way to show there are other ways of looking at Wine. But I also don't think it's such a bad idea either. And I really don't understand the irrational fear (oh, it comes from MS, it *must* be evil), and the overly emotional and unsupportable defense of 'Unix API'. -- Dimi.

April 25, 2003

Re: help, service thread, pthread, segv

by Mike Hearn

> Why cannot we use pthreads directly ? pthreads doesn't offer enough to fully implement the Win32 threading primitives from what I understand, so Wine has to work at a lower level. If you're on RH9, you have to configure using --with-nptl, which switches to the new threading model. Did you do that? -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

April 25, 2003

help, service thread, pthread, segv

by KK singh

hi, am a newbee and in need of help about wine, following are my querries. using wine20030408 on linux rhl 8.0 1. wine-devel doc says that the code for service thread should be in scheduler/services.c, I could not locate the file in my source code. 2. scheduler/pthread.c baffled me. It seems a pthread implementation using windows code. The header says. /* * pthread emulation for re-entrant libcs * * We can't use pthreads directly, so why not let libcs * that want pthreads use Wine's own threading */ Why cannot we use pthreads directly ? 3. I get a SIGBUS and repeated SIGSEGV, keeps coming, while running wine under gdb, this segv or sigbus is not normally visible, I mean running without gdb. This must be affecting the performance severly ? How can i know which thread is causing this ? gdb version is 5.2.1-4 4. The stack trace of sisegv looks like ..... for SIGBUS #0 0x4207be77 in memset () from /lib/i686/libc.so.6 #1 0x00000010 in ?? () #2 0x400c4bf8 in NtAllocateVirtualMemory (process=0xffffffff, ret=0x40722854, addr=0x41920000, size_ptr=0x40722858, type=4096, protect=64) at virtual.c:1045 #3 0x400b6b57 in HEAP_FindFreeBlock (heap=0x418f0000, size=65040, ppSubHeap=0x40722884) at heap.c:340 #4 0x400b74a5 in RtlAllocateHeap (heap=0x418f0000, flags=3, size=65040) at heap.c:1102 #5 0x004014f6 in ?? () ========================================== FOR SIGSEGV #0 RtlImageNtHeader (hModule=0x0) at loader.c:1242 #1 0x400ba560 in RtlImageDirectoryEntryToData (module=0x0, image=1, dir=0, size=0x40722650) at loader.c:1270 #2 0x400b97c7 in LdrGetProcedureAddress (module=0x0, name=0x4072267c, ord=0, address=0x40722678) at loader.c:754 #3 0x4007c8f9 in GetProcAddress (hModule=0x0, function=0xac46c4 "IID_ITextServices") at ../../loader/module.c:1053 #4 0x0046b5ed in ?? () #5 0x006074d7 in ?? () #6 0x00467708 in ?? () #7 0x00469e99 in ?? () #8 0x00607865 in ?? () #9 0x004671ae in ?? () #10 0x004610f1 in ?? () #11 0x00466ffa in ?? () #12 0x00466fa5 in ?? () #13 0x00463e07 in ?? () #14 0x0040b610 in ?? () #15 0x00463c22 in ?? () #16 0x00431979 in ?? () #17 0x00462662 in ?? () #18 0x00463a94 in ?? () #19 0x00463a0d in ?? () #20 0x004631b2 in ?? () ---------------------------------------- Please help me to know what are these functions ?? () tia -kks __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com

April 25, 2003

Re: wintab32 (from CrossOver Office)

by Mike Hearn

Thanks, I already have some code in the form of libegg, but I suspect Chris' code might be clearer. Chris - if you have any tips or could send me that code, it'd be good. Just remember that if you start getting it to work with Wine, please drop me a line. On Fri, 2003-04-25 at 04:09, Mike McCormack wrote: > Hi Mike, > > Now is a good time to mention to you that Chris Hoff did some work on > getting XEmbed to work with Wine. As far as I know, he had a standalone > program that could put something in the gnome toolbar, but no Wine code. > > You might want to write him an email to see how far he got with it. > > Mike > > Mike Hearn wrote: > > > I don't really have any, I'm much happier now that the policy has been > > made clear. It seems fine to me. No promised on xembed though ;) > -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

April 25, 2003

Re: wintab32 (from CrossOver Office)

by Fabian Cenedese

>No, our policy is not to be particularly secretive; we >particularly don't want to waste anyones time, ever. >There is so much to do that any inefficiency is >anathema to us. > >We're debating now how to do better. And we're >open to suggestions. Ideas? I'm far from doing any productive work for wine. And if I will it will be targeted at our software mainly. So this could only be helpful for others. But what about this: You could send a regular Codeweavers-News to the wine-devel (or private mailing-list to know who gets them) where you could summarize the work you're on at the moment (like weekly or once a month). So if someone is hard doing code he can check first with your list and then either move to something else or contact you to join forces. No details necessary, just the big picture. The other way would be that everybody has to ask you if you're already doing work on this or that or... bye Fabi

April 25, 2003

New Server?

by hatky

Since the Slash Dot pice on Wine the server is dead half the day.... Why not get the site on a new server I know what you are going to say: "Have you got one?" :) How about wine.sf.net? You already have a project open on source forge is it that difficult to move the site to their server? I THINK they can handle the load I assume there is some reason it has not been done but if there is not any meager issue I think it will be done at least for now (till the users stop coming :) ) What do you think? Hatky. __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com

April 25, 2003

Re: Debugging

by Mike Hearn

> In general, I don't think it's such a good idea to just dump > memory. Most of the time the data is typed, so outputing > something more meaningful is better. We haven't had a need > for such a macro, so I would suspect it's something very > specific -- defining it locally would be better for now IMO. Not to mention that such a dump might interfere with the terminal. I've had Wine stomp all over my xterms enough by accident thanks :)

April 24, 2003

Re: wine-dbg gone mad?

by Eric Pouech

Kye Lewis wrote: > I've just had this problem: > > A program had crashed and wing-dbg has been initiated, when I pressed > CTRL+C it went back to the console. however then like mad "wine-dbg>" > kept appearing over and over until I exited the console. > > Like "winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> > winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> > winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> > winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> > winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> > winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> > winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> > winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> > winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> > winedbg> winedbg> winedbg> winedbg> winedbg> winedbg> winedbg>" > > Over and over and over (and over... and over...... and over..... etc) > > Any ideas why this is? this sometimes happens when the underlying terminal dies (either unix or wineconsole) either a bug in winedbg or in the wineserver it's been a while I didn't see this though A+ -- Eric Pouech

April 24, 2003

Re: Debugging

by Eric Pouech

> 2. When debugging using winedbg, is there any way to view the contents of a > lot of memory in one go (eg. hex dump of 256 bytes)? for chars x /256c <addr> or x /256x <addr> for bytes A+ -- Eric Pouech

April 24, 2003

Re: Debugging

by Dimitrie O. Paun

On Thu, 24 Apr 2003, Ann and Jason Edmeades wrote: > 2 questions... > > 1. Is there any macro to dump out a hex dump of memory, eg. > TRACE_DUMP("Memory", pMem, numBytes); > If not, can I add one (inline in debug.h?) In general, I don't think it's such a good idea to just dump memory. Most of the time the data is typed, so outputing something more meaningful is better. We haven't had a need for such a macro, so I would suspect it's something very specific -- defining it locally would be better for now IMO. -- Dimi.

April 24, 2003