wine-devel

wine-devel@winehq.org

9 participants
84397 discussions

Re: [PATCH] deferred trace
by Alexandre Julliard 14 Mar '01

14 Mar '01

"Rob Farnum" <rfarnum(a)mindspring.com> writes: > My current design is to have yet another dll that would register > itself as the handler for this XClientMessage, so that on reciept of > the XClientMessage, it is simply passed to this new dll. This dll > would implement whatever application specific debugging tools I > need, with only the bare minimum of support from wine needed. Since > the wine debugger already has quite a bit of the functionality that > is needed, it might be interesting if this method could be used to > effectively open a pipe and drive the wine debugger externally. What you should rather do IMO is to put your dll inside the debugger, and have the debugger drive Wine instead of the other way around. Then you can add all kinds of elaborate mechanisms in the debugger, and do anything you want without needing any cooperation from the running Wine process. -- Alexandre Julliard julliard(a)winehq.com

2 1

RE: Problems with WM_NCHITTEST and HTTRANSPARENT
by Patrik Stridvall 14 Mar '01

14 Mar '01

> I'm currently having problems with this situation: > > Thread 1 owns some controls (modeless dialog box, actually) > > Thread 2 owns a window that covers the dialog (let's say it's like a > "skin" or something...) > > The window procedure for thread 2's window return HTTRANSPARENT in its > WM_NCHITTEST handler, so in theory mouse messages should get > passed down > to thread 1's controls. Now, what happens is this... [snip] > Any ideas on how to solve this, or whether it's supposed to work at all? I > think I could fix some games if this worked... otherwise I'll have to > think of some other way... >From MSDN: < HTTRANSPARENT < In a window currently covered by another window in the same thread < (the message will be sent to underlying windows in the same thread < until one of them returns a code that is not HTTRANSPARENT). Note "window in the same thread". So it seems that you (Wine) shouldn't pass down mouse messages to thread 1 in your example.

1 0

Problems with WM_NCHITTEST and HTTRANSPARENT
by Ove Kaaven 14 Mar '01

14 Mar '01

I'm currently having problems with this situation: Thread 1 owns some controls (modeless dialog box, actually) Thread 2 owns a window that covers the dialog (let's say it's like a "skin" or something...) The window procedure for thread 2's window return HTTRANSPARENT in its WM_NCHITTEST handler, so in theory mouse messages should get passed down to thread 1's controls. Now, what happens is this... -Mouse message arrives at thread 2 -TranslateMouseMsg calls WINPOS_WindowFromPoint -WINPOS_WindowFromPoint sends a WM_NCHITTEST to window -Window procedure returns HTTRANSPARENT -WINPOS_WindowFromPoint finds the controls, and returns that -TranslateMouseMsg wakes owner of controls (thread 1) -Mouse message arrives at thread 1 -TranslateMouseMsg calls WINPOS_WindowFromPoint -Since the transparent window is not owned by the current thread, WINPOS_WindowFromPoint doesn't bother to send it a message, but rather returns HTCLIENT directly -WINPOS_WindowFromPoint returns the transparent window -TranslateMouseMsg wakes thread 2 Repeat. This blocks all further mouse input processing, by the way... Any ideas on how to solve this, or whether it's supposed to work at all? I think I could fix some games if this worked... otherwise I'll have to think of some other way...

1 0

Re: [PATCH] deferred trace
by gerard patel 14 Mar '01

14 Mar '01

At 12:04 PM 14/03/2001 -0500, you wrote: >I remember wishing fondly for something like this when we were working >on WordPerfect, but never having the time to do it myself. FYI someone at Codeweavers has something much more sophistificated than my simple patch but from my understanding it's not ready for general use :-/ Gerard

2 1

Re: [PATCH] deferred trace
by Alexandre Julliard 14 Mar '01

14 Mar '01

Gavriel State <gav(a)transgaming.com> writes: > I disagree - many of the bugs I encounter can happen well into the run > of a program. For example, debugging a dialog box in an app that comes > up only after a specific set of occurances. Having the ability to turn > on -debugmsg +all at will would make this kind of debugging much easier. My reply was more targeted at the dumping of the window handles; I don't deny switching tracing on or off would be useful, but it needs to be done in a more generic way. Also this can be done externally to Wine, so that we don't need to burden the core dlls with extra command-line options or magic key sequences. There are many ways of doing that; an output filter is very easy to do and would work in many situations; if you need more complex stuff you could do it from the debugger, or write a small app that uses the debug API to manipulate the tracing state. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: [PATCH] deferred trace
by Alexandre Julliard 14 Mar '01

14 Mar '01

gerard patel <gerard.patel(a)asi.fr> writes: > 2) I don't see how I will get the window list I generate with > WIN_WalkWindows if there is no change at all in Wine - I should > have said that to cut in the trace size in not a goal per se, but a > mean to make debugging easier. > If I have to make a first run with full trace that I have to browse to see > what is the meaning of the window handles appearing in the trace, I lose > a lot of time. Having immediately a view of all existing windows is *very* > handy. I don't doubt it's very useful for the specific problem you are tracking; but it's hardly generic enough to be included in the main tree. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Heroes 3
by Andreas Mohr 13 Mar '01

13 Mar '01

On Mon, Mar 12, 2001 at 07:06:03PM +0100, Rustan Rosen rustan(a)lysator.liu.se [AndiM/Usenet 01/2001] wrote: > I found this on wine-users, and have the same problem. I did as you said, > and have attatched the file. Good ! > I have tried to test different setups, and seem to have problems with > directx, it wants to install 6.1, which doesnt work, and then says my > system doesnt have directx ('failed' in a checklist). I use the latest > wine in debian unstable, from 5/3 2001. After checking for directx, it > seems to install fine, but then just hangs. After killing it, and running > wine HEROES3.EXE > from the installed directory, it gives the above message. Can you help? > Shall I ask someone else? > Shall I supply more data? Call kernel32.192: CreateFileA(418c1a11 "C:\\Program Files\\3DO\\Heroes3\\DATAh3sprite.lod",c0000000,00000003,405e6ce4,00000003,00000080,00000000) ret=00599971 fs=008f trace:string:lstrcpynA (0x405e6400, "/kul/musik/wine/fake_windows", 1024) Ret kernel32.192: CreateFileA() retval=ffffffff ret=00599971 fs=008f . . . Call user32.425: MessageBoxA(00000000,005dd4fc "Unable to initialize resources - possible disk problem.",005dd628 "Unexpected Program Termination",00000010) ret=004cef94 fs=008f Hmm. Does C:\\Program Files\\3DO\\Heroes3\\DATAh3sprite.lod exist ? Or maybe this should be DATA\\h3sprite.lod ?? Hmm. Let me check this. I smell some Wine problem... BTW, have you tried running http://home.germany.net/100-30936/download/winecheck ? Probably doesn't help here, though... ARGL: Call kernel32.414: GetFullPathNameA(005d78d0 ".\\DATA\\",00000104,405e6cdc,405e6ccc) ret=00599630 fs=008f trace:string:lstrcpynA (0x405e63d0, "/kul/musik/wine/fake_windows", 1024) trace:string:lstrcpynA (0x405e63ed, "Program Files/3DO/Heroes3", 995) trace:string:lstrcpynA (0x405e67d3, "PROG~FBU\\3DO\\HEROES3", 1021) trace:string:lstrcpynA (0x405e67d2, "/Program Files/3DO/Heroes3", 1021) trace:string:lstrcpynA (0x405e67ed, ".\\DATA\\", 995) trace:string:lstrcpynA (0x405e6cdc, "C:\\Program Files\\3DO\\Heroes3\\DATA", 260) Ret kernel32.414: GetFullPathNameA() retval=00000021 ret=00599630 fs=008f THAT's it !! GetFullPathNameA() is broken (clips trailing '\\'). Latest Wine release, BTW ? Or which one ? Oh well, something needs to be fixed then, I guess... ;-) Andreas Mohr

2 1

RE: The PEACE Project
by Patrik Stridvall 13 Mar '01

13 Mar '01

> I don't know if you know about The PEACE Project: > > http://chiharu.haun.org/peace/ Now I do. :-) > What is PEACE? > > PEACE is a set of programs to run Win32 apps on NetBSD/i386 > (and other ports > in the future?) box. I see. > What is the difference from other Win32 emulators? > > Actually, PEACE is éWin32-compatible package' rather than > éemulator' because > different from Wine and WABI, And Wine isn't a "Win32-compatible package"? > PEACE does not have éemulator > executable'. > EXE files are directly executed from sh or csh. The above is IMHO a rather clintonesque use of the words emulator and executable. They hide the comparable code in NetBSD's dynamic linker instead. Not impressed, eventhough we could and probably should do that in the future. However if we hide the fact Wine is run, many user will not realize that it really is Wine's fault that their Win32 application crashes and say to their friends that Linux is unstable which gives Linux a bad reputation. We don't want that do we? So we probably shouldn't make it transparent at least not as long Wine still is alpha. > PEACE consists of the following 3 components: > > 1.In-kernel *.EXE loader Can't find the source but can't imagine it is very complicated. Probably somthing similar to what David Howells did for Linux. > 2.Dynamic linker for Windows *.DLLs Hmm, 233 lines of code including comments. Not very revolutionary. > 3.Win32 API implementation (i.e. core DLLs) This is supposed to do exact what Wine (Winelib) does. However it currently only implements a very small part of what Wine currently does as they admit... > How many Win32 API functions are implemented? > > Currentry, most APIs are NOT implemented. ... here In short this is just some Japanese guys trying to reinvent the wheel. I really can't understand why they don't cooperate with us in the Wine project instead.

6 5

Re: [PATCH] deferred trace
by gerard patel 12 Mar '01

12 Mar '01

At 11:24 AM 10/03/2001 -0800, you wrote: >gerard patel <gerard.patel(a)asi.fr> writes: > >> This implements a way to not output the debug trace to disk until the >> user hits Alf + F12. The goal is to avoid too big trace files. > >I think it would be much better to do that with a small external >program that you pipe the debug output into. This way you can have >much more flexibility I don't see why. 2 other points : 1) I wonder if I will not lose in speed with this approach; it seems to be more efficient to stop the output ASAP, than to filter data after it has passed through a pipe. I have timed Bcb4 loading with Wine on my computer (K6-350) - without any trace : 48 seconds With a simple -debugmsg +win,+relay : - with my patch : 70 seconds -> 22 seconds overhead - with a redirection to /dev/null : 95 seconds -> 47 seconds overhead I don't know if a pipe would be more efficient that a redirection, though. 2) I don't see how I will get the window list I generate with WIN_WalkWindows if there is no change at all in Wine - I should have said that to cut in the trace size in not a goal per se, but a mean to make debugging easier. If I have to make a first run with full trace that I have to browse to see what is the meaning of the window handles appearing in the trace, I lose a lot of time. Having immediately a view of all existing windows is *very* handy. >, and you don't need to hardcode a specific key >that some apps may need. But my patch does not use the Alt+F12 key if the -dt command line option is not used. It's true that some apps use this key, but in this case it's only debugging that is affected because the app does something when I use this key. It has never been a problem until now. Maybe a signal could be used instead. Gerard

2 1

RE: The PEACE Project
by Patrik Stridvall 12 Mar '01

12 Mar '01

> > > What is the difference from other Win32 emulators? > > > > > > Actually, PEACE is éWin32-compatible package' rather than > > > éemulator' because > > > different from Wine and WABI, > > > > And Wine isn't a "Win32-compatible package"? > > > > > PEACE does not have éemulator > > > executable'. > > > EXE files are directly executed from sh or csh. > > > > The above is IMHO a rather clintonesque use of the words > > emulator and executable. They hide the comparable code > > in NetBSD's dynamic linker instead. > > > > Clintonesque?? HAHAHAHAHAHAHAHAHAHAHA That's really good > dude! I guess it > follows in the tradition of words like "nasty". It follows the same tradition as the word quisling which means "A traitor that serves as the puppet of the enemy occuping his or her country." after Vidkun Quisling the notorius Norwegian traitor. Being clintonesque means "Deliberately distorting the meaning of a word or words in order to make somebody believe something that is not true." Compare Bill Clinton saying "I did not have sex with that woman" using a rather non standard definition of the word sex. In the case PEACE this might not have been deliberate, but because of ignorance, so perhaps the use of the word clintonesque was too harsh. > > Not impressed, eventhough we could and probably > > should do that in the future. > > > > I thought there was another kernel module running around that > loaded wine > for exe files. Used BINFMT_MISC or something? See Chad's mail. > > However if we hide the fact Wine is run, many user > > will not realize that it really is Wine's fault > > that their Win32 application crashes and say to > > their friends that Linux is unstable which gives > > Linux a bad reputation. We don't want that do we? > > > > So we probably shouldn't make it transparent at > > least not as long Wine still is alpha. > > > > Should there ever be a kernel module exe loader? The advantage of a kernel module loader is that you can do relocation on demand as well as having the ability to just discard such pages when memory is low instead of swapping them out. > Codeweavers is on the right track here, allowing users to > launch Windows > apps from gnome by creating a file association. Agreed. > > > PEACE consists of the following 3 components: > > > > > > 1.In-kernel *.EXE loader > > > > Can't find the source but can't imagine it is very complicated. > > Probably somthing similar to what David Howells did for Linux. > > > > I thought David's module was implementing the Wine in kernel > space (e.g. > part 3 of this). This part can be done with or without > having Wine in the > kernel. Not quite he is trying to implement the Wine _server_ in kernel space. ie approximately thoses things that requires some sort of intra-process communication. > > I really can't understand why they don't cooperate > > with us in the Wine project instead. > > I cannot either. I know that there is this whole thing about > wanting to > write your own code for stuff, but that is usually a waste of time. > Furthermore, the Wine project is developed in an extremely > open way by a lot > of very talented developers. It is a real shame to see > someone who could > obviously help out the Wine project going out and doing their > own program. > > Anyone can join the wine development team. Simply subscribe > to wine-devel > and wine-patches and start hacking. Because all patches go through > Alexandre before going into CVS every developer has basically > equal chances > of getting their patch into the tree (assuming that it is > following the > overall architecture goals of Wine). Indeed and if they prefer not to communicate in english, setting up a wine-devel-jp mailing list shouldn't be a problem. Most of the patches they send in will "speak" for itself without any or at least only a very short explaination. > Actually, I would say wine is an > extremely good example of the open source development process. > > There is also no licensing issue with Wine, it's under such a liberal > license that anyone can use it! Agreed.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel