Hi Alexandre, What was wrong with this patch? I guess you want it in a separate debug channel, yes? On Sun, 2003-10-19 at 12:58, Mike Hearn wrote:
This implementation is obviously not complete, but it prints out the event log strings using MESSAGE, which is good enough for now. This is handy because MSI uses this API when it gets into trouble, so we can now see what it thinks is going on.
Mike Hearn <mike(a)theoretic.com> writes:
What was wrong with this patch? I guess you want it in a separate debug channel, yes?
That would be one way to do it, yes. A better equivalent of the Windows functionality would probably be to use syslog. Using MESSAGE is definitely wrong. -- Alexandre Julliard julliard(a)winehq.com
On Sun, 2003-11-02 at 23:20, Alexandre Julliard wrote:
That would be one way to do it, yes. A better equivalent of the Windows functionality would probably be to use syslog. Using MESSAGE is definitely wrong.
What's wrong with it? My main concern over other methods is that nobody would ever notice the app was outputting potentially useful information. At least with MESSAGE there's no chance of people missing it. The best way imho would be to have some debug channels be on +trace by default, like OutputDebugString and this event logging system. Syslog is a nice idea but I think it's primary use if for debugging, so we don't want it going there.... thanks -mike
Mike Hearn <mike(a)theoretic.com> writes:
What's wrong with it? My main concern over other methods is that nobody would ever notice the app was outputting potentially useful information. At least with MESSAGE there's no chance of people missing it.
And if the info is not useful, there's no way to turn it off...
The best way imho would be to have some debug channels be on +trace by default, like OutputDebugString and this event logging system.
Note that you get an event type in ReportEvent so you can use that to do smarter tracing, i.e. use ERR for error events, WARN for warnings etc. This way errors will be shown by default, but they can still be turned off if needed.
Syslog is a nice idea but I think it's primary use if for debugging, so we don't want it going there....
Syslog is for logging system events, which is precisely what Windows event logging does, so it sounds like a pretty good fit to me. -- Alexandre Julliard julliard(a)winehq.com
If we use the syslog, doesnt this mean we must be root to read the messages ?
Syslog is for logging system events, which is precisely what Windows event logging does, so it sounds like a pretty good fit to me.
===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
--- Alexandre Julliard <julliard(a)winehq.org> wrote:
Syslog is for logging system events, which is precisely what Windows event logging does, so it sounds like a pretty good fit to me.
Maybe WINE should develop a event log service like in WinNT/2k so you dont have to be root to see these messages. There are some other areas where this would be needed the same is in windows such as in netapi32 and rpcrt4 logging so perhaps WINE and ReactOS can use the same interface and event log service. Thanks Steven __________________________________ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/
Hello All Again, We have found a work around for all our existing issues porting X-Lite so long as Jerry Jenkins's unincorporated WINE patch listed below is applied to Wine. I don't know why it's not incorporated yet, but without it our application has horrible issues (as do similar styled applications). We have spent time creating another test application with source to demonstrate UI issues that fail under Wine with unusual shaped windows, so you all can have a test application to work against to fix these issues at your leisure. We have worked around all of these issues in our application (with the unincorporated JJ patch) by using alternative APIs or use the APIs in a different manner. What are the chance's JJ's patch can be put into the main Wine CVS tree? Does anyone know what issues it breaks? All I can see is improvement (even though it's not a complete solution yet to all issues), hence my curiosity. This application demonstrates the issues we are having which will allow X-Lite to run under WINE. Find the demo application at: http://www.xten.com/files/winetest2.zip Some of the bugs are fixed by this *unincorporated* WINE patch by Jerry Jenkins: http://www.winehq.org/hypermail/wine-patches/2003/09/0268.html (hereafter called "the unincorporated JJ patch") - B1. Critical, but fixed by the unincorporated JJ patch. Focus does not appear to be on the application at startup. We do not receive keyboard messages, though we do receive many other messages, such as as mouse-clicks. Clicking on the square labelled "focus:" fixes the problem, by bringing up a message box -- when the message box is dismissed, the application has focus. This appears to be the same problem as that discussed here: http://bugs.winehq.org/show_bug.cgi?id=292 - B2. Critical, but fixed by the unincorporated JJ patch. No task bar item. - B3. Critical, but fixed by the unincorporated JJ patch. "System" commands do not appear to be working. Examples: - we do not receive WM_CLOSE when the user presses Alt+F4 - Alt+Space does not bring up the System menu - B4. Critical, but fixed by the unincorporated JJ patch. We are always on top, until a screen-saver kicks in. (Also can be fixed by simply removing WS_POPUP.) This appears to be the same problem as that discussed here: http://bugs.winehq.org/show_bug.cgi?id=1288 - B5. Not critical, as we have a work-around. The application window is supposed to have a non-rectangular shape. The shape is made by setting a "region" from a mask bitmap, and calling SetWindowRgn. The problem under Wine happens when converting the 2-bit color mask to a 24-bit color mask. The black 2-bit pixels are properly converted to black 24-bit pixels, but the white 2-bit pixels are converted to a near-black, rather than white. The sample app demonstrates 2 ways of working around the problem: method 1: fixes the problem by using a 16-color (4 bit per color) mask instead of a 2-color mask. This gets around the bug in a reasonable way. method 2: fixes the problem by using near-black (instead of white) for the "transparent" color. This exploits the bug and causes a bad (but correct) appearance on Windows. - B6. Fixed by latest CVS WINE release. Copy to the clipboard doesn't work (though pasting from the clipboard does work). - B7. Not critical, as we have a work-around. Attempting to bring up the right-click context menu causes the app to hang. - B8. Not critical, as we have a work-around. Unwanted caption. If an application without a caption shows itself, and *then* gives itself a funky shape by calling SetWindowRgn, the application will have a caption. If, however, the application calls setWindowRgn *before* showing itself, it will correctly not have a caption. The sample app demonstrates this, as well as demonstrating a fix for the problem. min. fix view: clicking on this square hides the window and then shows it again, which gets rid of the caption max. fix view: clicking on this square also fixes B5 (using method 1) and then hides and shows the window - B9. Not critical, as we have a work-around. Handling WM_NCHITTEST to move an app without a caption. Another example of such an app was the clock that shipped with older versions of Windows. (You've got to first turn off the caption and menu by pressing Esc, or with Settings->NoTitle in the menu.) There's a copy here: http://www.user.dccnet.com/jroe/wakeup/winclock.zip This app shows another Wine bug -- turning off the caption bar and menu ony half works -- the caption bar remains. Another example of an application which turns off the caption bar and menu (and which only half works under Wine): http://www.user.dccnet.com/jroe/wakeup/wakeup.zip - B10. Not critical, as we have a work-around. Apart from the WM_NCHITTEST method (see B9), the sample app demonstrates 2 algorithms for moving a window. I'll call the algorithms the 'mouse move argument' algorithm and the 'cursor pos' algorithm. Either algorithm works fine under Windows, and either algorithm works fine under Wine *if* the window has a caption bar. but if the window does not have a caption bar, the mouse move argument algorithm produces some very undesirable results -- if you move the mouse fast, WM_MOUSEMOVE appears to send some very confused LPARMS, and the window gets moved to unpredictable positions. Clicking on the "toggle bug B10" toggles between the 2 algorithms. (Remember to turn off the caption bar first -- see B8). - B11. Not critical, as we have a work around. RTF control. This one is not actually demonstraded by the sample app. The problem can commonly be seen when running installer progams -- the EULA is often displayed in a rich edit control, and is unreadable under wine. An example of such an installer: ** http://www.innosetup.com/ -Rob
participants (5)
-
Alexandre Julliard -
Mike Hearn -
Rob -
Steven Edwards -
Sylvain Petreolle