March 2001 - Wine-Devel - list.winehq.org

Re: [PATCH] deferred trace

by gerard patel

At 03:00 PM 14/03/2001 -0800, you wrote: <snip> >that the wine debugger can resolve, it is possible to meet the needs that >have been expressed. Expressed ? What I wanted is something short and simple, so I could help people on the news group. The use of my patch could be explained in *one* line and it would have worked with Wine right 'out of the box' :-)... something the internal debugger does not do anymore since a long time. I am afraid that this thing will be more complex to setup and to use that the debugger - something already too complex for many people. And well, I almost never use the debugger myself because it crashes at the slightest provocation so I don't feel much about saying people to use it. So in short, after all my 'needs' (helping ppl on the news group) are indeed specific :-) Gerard

March 15, 2001

Re: [PATCH] Version info for comctl32.dll

by gerard patel

At 10:10 AM 15/03/2001 +0800, you wrote: >I thought that include/wine/wine_common_ver.rc will serve as the quite reasonable >defaults for all built-in Wine dlls. If not, it should be changed for ALL dlls >in ONE place. Getting the common controls to the 4.72 version at least is the *whole* purpose of the patch. There are applications testing the version number of the common controls - tons of them : all the apps written with modern Borland tools. Their behaviour change accordingly because Ms changed things quite a lot with 4.72. Wine does not emulate the old behaviour, so it's needed to return a recent version number to get some apps to work correctly. Unless the version number of winsock.dll, richedit.dll, version.dll, or unrelated dlls like that is always identical to the version number of common controls ? I did not check but that seems unlikely. >1. I believe that version numbers should be equal in both numerical field and >in the string value (0.01 != 4.72 and 1.00 != 4.72). >2. There is no need for excessive \000 at the end of the string value. >3. All well behaving programs do read "VarFileInfo"/"Translation" before >retrieving other version information. LANGUAGE does nothing here. >4. Did you try to use my sample application showing version info? >5. Version resources in kernel, user, gdi for both 16 and 32-bit dlls could serve >as an example of adding version resources into built-in dlls. Well, all right I'll do like it's done in include/wine. I did not search far enough, I used the file in commdlg as an example :-) I found another problem you missed btw, there is a special function to retrieve the dll version directly, it returns hard coded values; I'll add code to retrieve these from the resource. Gerard

March 15, 2001

Re: winedefault patch

by Andreas Mohr

On Wed, Mar 14, 2001 at 09:35:17PM +0100, Ove Kaaven wrote: > Wine won't load builtin dlls if a full path to a nonexistent file is > specified, so the default registry should probably not have a full path to > dplayx.dll. Some guy managed to start Settlers 3 after this was fixed... > > Log: > Removed path from dplayx registry entry, so that the builtin dplayx can be > loaded. Alexandre, please add a comment to winedefault.reg reminding people of this problem for future entries. Thanks ! -- Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany Tel. +49 7159 800604 http://home.germany.net/100-30936/

March 15, 2001

Re: [PATCH] deferred trace

by Eric Pouech

> > I think it is desirable to use as much of the existing debugger > > functionality as possible, and to add an "elaborate mechanism in the > > debugger" that allows it to be dynamically extended in > > functionality. > > It would certainly be possible to load dlls inside the debugger itself > to extend it; though maybe simply loading a batch file containing > debugger commands may allow to do a lot of things already without > requiring compiling new code. all of this would be possible. The only missing point so far is stopping the debugger execution at any point in time (like a ctrl-c for example), and also the one of debugged program. this may be the trickier part. A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

March 15, 2001

Re: [PATCH] Version info for comctl32.dll

by Dmitry Timoshkov

"gerard patel" <gerard.patel(a)asi.fr> wrote: > ChangeLog: > > * dlls/comctl32/rsrc.rc > Add version info. [...] > LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL > + > +1 VERSIONINFO > +FILEVERSION 4, 72, 0, 0 > +PRODUCTVERSION 4, 72, 0, 0 > +FILEFLAGSMASK VS_FFI_FILEFLAGSMASK > +FILEOS VOS_DOS_WINDOWS16 [...] > + VALUE "FileVersion", "0.01\000" [...] > + VALUE "ProductVersion", "1.00\000" I thought that include/wine/wine_common_ver.rc will serve as the quite reasonable defaults for all built-in Wine dlls. If not, it should be changed for ALL dlls in ONE place. Besides that: 1. I believe that version numbers should be equal in both numerical field and in the string value (0.01 != 4.72 and 1.00 != 4.72). 2. There is no need for excessive \000 at the end of the string value. 3. All well behaving programs do read "VarFileInfo"/"Translation" before retrieving other version information. LANGUAGE does nothing here. 4. Did you try to use my sample application showing version info? 5. Version resources in kernel, user, gdi for both 16 and 32-bit dlls could serve as an example of adding version resources into built-in dlls.

March 15, 2001

Re: [PATCH] deferred trace

by Alexandre Julliard

"Rob Farnum" <rfarnum(a)mindspring.com> writes: > I am not exactly sure what you mean by this. Do you mean to put the > code that would be in the dll, into the debugger, or to extend the > debugger in such a way that it can load dll's to enhance its > functionality, or something else? I mean that the code that would have been in the dll and loaded into Wine should be in the debugger instead. So for instance, instead of having a magic key (or X message) to switch tracing on, you'd have a debugger command 'set tracing on' that would poke into the Wine address space to do it. Since you can read/write memory, call functions (I think it's broken now but should be easy to fix), etc. from the debugger you can do everything from here and avoid the need to have any debugging code running inside the Wine process. > This would bypass the objection of intercepting a key, like F12, and > using it to generate a window list dump, and replace it with a > mechanism that uses the debugger own builtin functions to do that. Yes, exactly. > I think it is desirable to use as much of the existing debugger > functionality as possible, and to add an "elaborate mechanism in the > debugger" that allows it to be dynamically extended in > functionality. It would certainly be possible to load dlls inside the debugger itself to extend it; though maybe simply loading a batch file containing debugger commands may allow to do a lot of things already without requiring compiling new code. -- Alexandre Julliard julliard(a)winehq.com

March 14, 2001

Re: [PATCH] deferred trace

by Rob Farnum

Alexandre Julliard <julliard(a)winehq.com> wrote... > What you should rather do IMO is to put your dll inside the debugger, I am not exactly sure what you mean by this. Do you mean to put the code that would be in the dll, into the debugger, or to extend the debugger in such a way that it can load dll's to enhance its functionality, or something else? > and have the debugger drive Wine instead of the other way around. Then My intention was not to have wine drive the debugger, but to allow the debugger to be driven by effectively hooking into yylex and feeding it externally by a separate application. I am not interested in driving wine, I am interested in getting state information from wine in as least an invasive way as possible. This would bypass the objection of intercepting a key, like F12, and using it to generate a window list dump, and replace it with a mechanism that uses the debugger own builtin functions to do that. > 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. I think it is desirable to use as much of the existing debugger functionality as possible, and to add an "elaborate mechanism in the debugger" that allows it to be dynamically extended in functionality. If I have built debugging instrumentation into a dll, I would prefer not to be required to have the debugger and wine be linked to it at compile time, but be able to bind to it at run time. The idea is to be able to extend the language of the debugger to dynamically handle application specific instrumentation. Basically, I need the ability of gdb to 'call' an external function that the wine debugger does not have prior knowledge of. With these two capabilities, externally feeding the debugger commands by a separate application to a currently running wine application and being able to call any function that the wine debugger can resolve, it is possible to meet the needs that have been expressed.

March 14, 2001

RE: Problems with WM_NCHITTEST and HTTRANSPARENT

by Patrik Stridvall

> 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.

March 14, 2001

Re: [PATCH] deferred trace

by Alexandre Julliard

"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

March 14, 2001

Problems with WM_NCHITTEST and HTTRANSPARENT

by Ove Kaaven

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...

March 14, 2001