Re: tools/widl/typegen.c pointer initialization
On Sun, 28 Oct 2007, Dan Hipschman wrote: The logic is as follows: Thanks for the explanation, Dan! Better than this would be to put assert(is_user_type(type)); above the initializations to convince the programmer at least that name will get initialized correctly in get_user_type. If that doesn't convince the compiler then I don't think it's worth it to try to placate it since we're supposed to be wrting code for humans, not computers. I think the question is whether a compiler can reasonably be expected to deduce that the source is fine. If that deduction involves solving the halting problem (or similar) hacking the source to avoid the warning actually doesn't occur to be that bad. ;-) After the work I did again in the last weeks Wine now builds more or less without warnings for most versions of GCC (and our default set of options). If things continue to proceed well, this may be the only warning left in the whole codebase in a week or two. I think the real problem is that the code is just not clear enough. I've been meaning to add asserts. Where asserts are impractical: comments. Does this mean you are going to submit some patches to address this? Gerald
Re: ATI fglrx 8.42 Driver issues
Am Montag, 29. Oktober 2007 00:55:34 schrieb Brian Dunne: but I encountered a pretty serious problem when trying to wine World of Warcraft in OpenGL mode. In short, it won't draw models - it seems to draw environments and effect animations fine, but characters and objects like benches and mailboxes are invisible. The problem is that if something like this happens in OpenGL mode, we can do almost nothing. OpenGL is to 99% a pass through, so the app calls the driver directly. We do not have the chance to alter anything if the driver doesn't like what the app is doing. So your best bet is to file a bug at ATI concerning this. But can you try d3d mode? In the past, the ATI drivers preferred that over WoW's OpenGL renderer. signature.asc Description: This is a digitally signed message part.
Re: Lots of 'make test' failures on Windows
On Sun, 28 Oct 2007, Reece Dunn wrote: [...] It would be even better if the tests were also run on real machines, as that would catch which test failures are VM related (such as the Direct3D tests). Sure. However I don't have real Windows machines so I'll leave this as an exercise for someone else. The tricky part is scripting the download, signature checking and getting it all to run automatically at night (because if it's not 100% automated I don't think we'll have regular results). Maybe the way to go is with the Windows scheduler plus a wsh script. Or winetest could be modified to do most of it: with wininet/winhttp/urlmon managing the download part should be quite feasible, while crypt32 might provide for the signature checking part. Then it's just a matter for winetest to remain idle (with a systray icon?) until the specified time to run the tests... Actually, I'll mention that Virtual machines do have an advantage over real Windows machine: after the tests are run, they are reset back to a known state, even if the tests did not clean things up quite right. -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.
Re: Make test drill, next steps, call for help with Winetest
On Sun, 28 Oct 2007, Detlef Riekenberg wrote: On Sa, 2007-10-27 at 14:03 +0200, Francois Gouget wrote: Things still on the todo list: * the script also grabs the winetest.exe signature and attempts to verify it. But I don't know where to find the corresponding public key (651FD487) so I don't know if this really works. Paul's homepage: http://www.astro.gla.ac.uk/users/paulm/ $ gpg --list-keys paulm pub 1024D/BF0F03E9 2000-11-07 uid Paul Millar (Physics Astronomy) sub 1024g/1034BACC 2000-11-07 When I run 'gpg --list-keys paulm' all I get is this first key, but the one I need is the one below... Same thing if I go to the http://wwwkeys.pgp.net/ URL listed on his page. pub 1024D/651FD487 2002-05-11 uid quisquiliae (automatic program for testing WINE) sub 1024g/420F3FE4 2002-05-11 [...] My script loads the signature and verify the winetest-latest.exe. When gpg failed to verify the binary, a new winetest is available. The new binary is downloaded and checked again. When the check was ok, the winetest-lastest is copied to the destination and qemu is started for every image. Sounds like a good idea. To bad, that qemu 0.9.0 crash on ntdll_text.exe exception ... Maybe you can try VirtualBox. Apparently it's GPL... Though if it's incompatible with qemu it would force you to make a choice between them. -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ Avoid the Gates of Hell - use Linux.
Re: Misplaced Property Sheet buttons
On Fri, 26 Oct 2007, Frank Richter wrote:
On 26.10.2007 16:52, Peter Åstrand wrote:
This solves the position problem, but instead the Help button disappears.
See screenshot
http://www.cendio.com/~astrand/wine/62-tab-size/patched.png. Any ideas?
Hint: check again what WM_WINDOWPOSCHANGED's 'lParam' contains ...
Thanks. I've now fixed this problem. I discovered another bug, though: The
implementation does not take into account that the caller might do
ShowWindow(FALSE) on the help and apply buttons. The patch below fixes
this problem as well. I will file a bug.
--- propsheet.c (revision 13243)
+++ propsheet.c (arbetskopia)
@@ -865,10 +865,12 @@
int buttonWidth, buttonHeight;
PADDING_INFO padding = PROPSHEET_GetPaddingInfo(hwndParent);
- if (psInfo-hasApply)
+ hwndButton = GetDlgItem(hwndParent, IDC_APPLY_BUTTON);
+ if (psInfo-hasApply GetWindowLongW(hwndButton, GWL_STYLE) WS_VISIBLE)
num_buttons++;
- if (psInfo-hasHelp)
+ hwndButton = GetDlgItem(hwndParent, IDHELP);
+ if (psInfo-hasHelp GetWindowLongW(hwndButton, GWL_STYLE) WS_VISIBLE)
num_buttons++;
/*
@@ -3828,6 +3830,17 @@
return TRUE;
}
+ case WM_WINDOWPOSCHANGED:
+ {
+ PropSheetInfo* psInfo = (PropSheetInfo*) GetPropW(hwnd,
PropSheetInfoStr);
+
+ if (!psInfo)
+return FALSE;
+
+ PROPSHEET_AdjustButtons(hwnd, psInfo);
+ return FALSE;
+ }
+
default:
return FALSE;
}
Regards,
---
Peter Åstrand ThinLinc Chief Developer
Cendio AB http://www.cendio.se
Wallenbergs gata 4
583 30 LinköpingPhone: +46-13-21 46 00
ThinLinc User Group 2007 Höstkonferens --- 15-16 november, Linköping.
Program och anmälan: http://www.thinlincusergroup.se/aktiviteter
Re: Make test drill, next steps, call for help with Winetest
On Sat, 27 Oct 2007, Jakob Eriksson wrote: [...] I achieved much the same thing by putting a wget script in the Auto-startup folder of Windows. Then I copy in this vmware windows virtual machine and start it. Then Windows itself downloads winetest and upon completion, does a shutdown -h now. (Via cygwin.) I often find cygwin a relief when working with Windows. While I prefer the autorun approach because it has fewer dependencies on the Windows side and thus allows me to test in as clean a Windows as desired, your approach could be pretty useful for testing on a real Windows machine. Maybe if you post your script with some instructions it will inspire some people to set up automated testing on their real Windows machines. I'm sure it would make the Direct3D guys happy (if the testers have Nvidia ;-) ). -- Francois Gouget [EMAIL PROTECTED] http://fgouget.free.fr/ Any sufficiently advanced Operating System is indistinguishable from Linux
Re: ATI fglrx 8.42 Driver issues
Am Montag, 29. Oktober 2007 00:55:34 schrieb Brian Dunne: but I encountered a pretty serious problem when trying to wine World of Warcraft in OpenGL mode. In short, it won't draw models - it seems to draw environments and effect animations fine, but characters and objects like benches and mailboxes are invisible. The problem is that if something like this happens in OpenGL mode, we can do almost nothing. OpenGL is to 99% a pass through, so the app calls the driver directly. We do not have the chance to alter anything if the driver doesn't like what the app is doing. So your best bet is to file a bug at ATI concerning this. But can you try d3d mode? In the past, the ATI drivers preferred that over WoW's OpenGL renderer. Ati's drivers are still very buggy. In various situations they even fall back to software rendering. In some cases the xorg.conf option 'UseFastTLS=2' can do miracles. It is important to find a testcase in which you can produce the problems. And then submit a bugreport to ati.cchtml.com (it is ati's unofficial bugzilla; all bugs are forwarded to ati and they really do something with them) Roderick -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: Make test drill, next steps, call for help with Winetest
Francois Gouget wrote:
While I prefer the autorun approach because it has fewer dependencies on
the Windows side and thus allows me to test in as clean a Windows as
desired, your approach could be pretty useful for testing on a real
Windows machine. Maybe if you post your script with some instructions it
will inspire some people to set up automated testing on their real
Windows machines. I'm sure it would make the Direct3D guys happy (if the
testers have Nvidia ;-) ).
I forgot... I did a C hack. cc -o runstuff.exe runstuff
Then copied runstuff.exe to c:\win95\Start-Menu\Program\Autostart
#include stdlib.h
#include unistd.h
int main ()
{
chdir (/tmp);
unlink (winetest-latest.exe);
system (wget
http://www.astro.gla.ac.uk/users/paulm/WRT/CrossBuilt/winetest-latest.exe;);
system (./winetest-latest.exe -q -c -t JakobAuto);
system (shutdown -h now);
return 0;
}
About virtual machines starting in a clean state, nothing stops anyone
from booting linux
in between and dd if=windows_part.bin of=/dev/hdb1 and then reboot
into Windows.
This way you could get consistent Windows regression testing on real
hardware.
regards,
Jakob
Re: dlls/comctl32/listview.c warning elimination
Gerald Pfeifer [EMAIL PROTECTED] writes: Not a patch I am particularily proud of, but the best way I found to get rid of listview.c:5043: warning: 'strW' might be used uninitialized in this function issued by GCC, and apart from the added cast it actually is simpler than the original. It was done the way it is precisely to avoid the non-const cast, which triggers a warning too. -- Alexandre Julliard [EMAIL PROTECTED]
New Wine help and discussion forum
Hello, There is a new Wine help and discussion forum at http://www.wine-forum.org/index.php that is meant to be a meeting place for anyone interested in Wine usage or development. In the past there there has never been a single forum dedicated solely to Wine. The lack of a single forum has left people to post Wine related help and discussions in other forums. At the moment most users turn to their Linux distribution forum where Wine is often a sub-forum at most and questions often go unanswered. My goal is to provide a forum to bring Wine users together into a single meeting place to discuss anything relevant to the daily happenings surrounding Wine. There are multiple categories/subforums to cover all aspects of using Wine (Applications, Games, 3rd Party Wine Utilities, Commercial Offerings, etc.). Cheers, Tom Wickline
Re: Yet another wine frontend: PlayOnLinux
It's a jungle out there! (WineBot, Wine Doors, PlayOnLinux + the old ones) Dan Kegel wrote: This one seems new to me: http://www.playonlinux.com It's hooked up in the wine wiki already: http://wiki.winehq.org/ThirdPartyApplications http://wiki.winehq.org/PlayOnLinux Anyone tried it? - Dan
What's wrong with ...
Hello, I've submitted a patch to wine-patches 5 days ago which has not been added yet: Added wrapper dll for ct-api(CardTerminal API) http://www.winehq.org/pipermail/wine-patches/2007-October/045716.html I think that most of the code has already been reviewed: The 1st version has already been submitted May 06 2007: - http://www.winehq.org/pipermail/wine-patches/2007-May/038908.html Steven Edwards pointed out some obvious mistakes... - http://www.winehq.org/pipermail/wine-patches/2007-May/038922.html - http://www.winehq.org/pipermail/wine-patches/2007-May/038923.html ... which were fixed on July 3: - http://www.winehq.org/pipermail/wine-devel/2007-July/057847.html - http://www.winehq.org/pipermail/wine-patches/2007-July/041206.html On July 11 Alexandre Julliard requested some additional changes: - http://www.winehq.org/pipermail/wine-devel/2007-July/058003.html I hope that everything is correct now. If not, please let me know. Thanks Christian
Re: [Wine] New Wine help and discussion forum
Awesome, it was about time something like this was done, I feel more at home with a forum rather than using a mailing list - kudos to you! thanks a ton, I'll register ASAP ^_^. On 10/29/07, Tom Wickline [EMAIL PROTECTED] wrote: Hello, There is a new Wine help and discussion forum at http://www.wine-forum.org/index.php that is meant to be a meeting place for anyone interested in Wine usage or development. In the past there there has never been a single forum dedicated solely to Wine. The lack of a single forum has left people to post Wine related help and discussions in other forums. At the moment most users turn to their Linux distribution forum where Wine is often a sub-forum at most and questions often go unanswered. My goal is to provide a forum to bring Wine users together into a single meeting place to discuss anything relevant to the daily happenings surrounding Wine. There are multiple categories/subforums to cover all aspects of using Wine (Applications, Games, 3rd Party Wine Utilities, Commercial Offerings, etc.). Cheers, Tom Wickline ___ wine-users mailing list [EMAIL PROTECTED] http://www.winehq.org/mailman/listinfo/wine-users
Re: New Wine help and discussion forum
On Mon, Oct 29, 2007 at 11:34:33AM -0400, Tom Wickline wrote: My goal is to provide a forum to bring Wine users together into a single meeting place to discuss anything relevant to the daily happenings surrounding Wine. Does that mean you will make it synchronise with the user mailinglist? Jan
Re: New Wine help and discussion forum
On 10/29/07, Jan Zerebecki [EMAIL PROTECTED] wrote: Does that mean you will make it synchronise with the user mailinglist? I can't speak for Tom on this issue, though I was the one to suggest that he start the forum after the Wineconf discussions regarding the mailing list and newsgroup disconnection. I think long term we might want to see about just killing the users mailing list if the forum proves to be much more popular. The idea is to have ONE central place for all user discussions. Most users these days tend to be content with a forum like system, see the proliferation of blogs as an example. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: Yet another wine frontend: PlayOnLinux
Dan Kegel wrote: This one seems new to me: http://www.playonlinux.com It's hooked up in the wine wiki already: http://wiki.winehq.org/ThirdPartyApplications http://wiki.winehq.org/PlayOnLinux Anyone tried it? - Dan Whatever happened to winefix by the way? You mentioned it earlier, but it's not on the wiki. Unlike those temporary hacks to get specific applications working, winefix sounds like it has a few things Wine could really use in the desktop integration department. Remco (just a user/wine-devel-lurker) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
re: New Wine help and discussion forum
Steven wrote: I can't speak for Tom on this issue, though I was the one to suggest that he start the forum after the Wineconf discussions regarding the mailing list and newsgroup disconnection. So you're the guilty party! Next time you decide to shake up the wine community like that, please consider discussing the move with the developer community first. I think long term we might want to see about just killing the users mailing list if the forum proves to be much more popular. The idea is to have ONE central place for all user discussions. The mailing list can in fact be the central place, even in the era of web-based interfaces. Killing it would greatly annoy a large population of people, including especially the developers who sometimes help users on the list. The thing to kill, if anything, is the usenet group; sadly, usenet does seem to be decaying pretty badly. As an experiment, I've set up a google groups front end for wine-users. It's at http://groups.google.com/group/wine-users/ For this to become real, we'd have to switch the mailman user list over. Do folks think we should try that? Or do people really think we should kill the mailing list and go to a forum? - Dan
Re: opengl problems (commit 00633e37bcc8da1032f34ea2d87814739de07db4)
Alex Romosan [EMAIL PROTECTED] writes: this was on my thinkpad t40 with a radeon r250 (mobility firegl 9000) card using the open source drivers. the program also crashes on my desktop with an nvidia card using the proprietary nvidia drivers but i don't know if it's the same problem. i'll investigate more tomorrow. also, i am using xorg 7.3 from debian. i've been having this problem for about a month now which is about the time debian switched to xorg 7.3. i wonder if maybe this has something to do with the crash. so i played with wine and tracked on my desktop with the same results. latest wine git version crashes tracked with the following: wine: Unhandled page fault on read access to 0x at address 0x7da22648 (thread 0014), starting debugger... Unhandled exception: page fault on read access to 0x in 32-bit code (0x7da22648). fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7da22648 ESP:0033fdb4 EBP:0033fdec EFLAGS:00210202( - 00 - -RI1) EAX:0033fde0 EBX:7da579b4 ECX:7da5a9c0 EDX:7da5a9c4 ESI: EDI:00122398 Stack dump: 0x0033fdb4: 1a85 0004 0033fde0 0x0033fdc4: fff1 ffe0 0x0033fdd4: 00122398 0042567c 004256b5 000a 0x0033fde4: 7ed1e988 0001 0033fe0c 7ed062db 0x0033fdf4: 0033fe60 00443457 00408fa0 0x0033fe04: 7ed06299 0033ff08 0041b192 Backtrace: =1 0x7da22648 X11DRV_wglFlush+0x68() [/home/romosan/cvs/wine/dlls/winex11.drv/opengl.c:2056] in winex11 (0x0033fdec) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value __wine_dbch___default (1) 2 0x7ed062db wine_glFlush+0x4b() [/home/romosan/cvs/wine/dlls/opengl32/wgl.c:584] in opengl32 (0x0033fe0c)
Re: opengl problems (commit 00633e37bcc8da1032f34ea2d87814739de07db4)
wine: Unhandled page fault on read access to 0x at address 0x7da22648 (thread 0014), starting debugger... Unhandled exception: page fault on read access to 0x in 32-bit code (0x7da22648). Gah, please stop spamming us with full back traces. And if you think this is a Wine bug, open a bug in bugzilla - this isn't primarily a bug forum. --Juan
Re: Extracting rules from comments in wine source code...?
Supposedly her tool finds bugs in source trees by looking for rules in comments and then checking the software against those rules. Her paper says she found one bug in wine this way... I sure didn't any reference to the actual bug, did you? --Juan
Re: Problems with TAB_GetCurFocus
This patch seems to cause the problem...
Author: Hagop Hagopian [EMAIL PROTECTED]
Date: 17-03-2007 19:16:08
Parent: comctl32: tab: Added message sequence tests for the tab c...
Child: winex11.drv: In the case requested glyphs do not present...
Branch: master (d3drm: Implement D3DRMCreateColorRGB.)
Follows: wine-0.9.33 (Release 0.9.33.)
Precedes: wine-0.9.34 (Release 0.9.34.)
comctl32: tab: Minor bug fixes in the curSel and curFocus getters
and setters.
I'll fill a bug
2007/10/29, Luiz Angelo Daros de Luca [EMAIL PROTECTED]:
It seems that this happens when the tab is not painted yet (window
created hidden) and the current focused tab read.
2297 static void TAB_Refresh (TAB_INFO *infoPtr, HDC hdc)
2298 {
(...)
2328 /* If we haven't set the current focus yet, set it now.
2329 * Only happens when we first paint the tab controls */
2330 if (infoPtr-uFocus == -1)
2331 TAB_SetCurFocus(infoPtr, infoPtr-iSelected);
2332 }
2007/10/29, Luiz Angelo Daros de Luca [EMAIL PROTECTED]:
Hello,
I'm having problems with the result of the message TCM_GETCURFOCUS. In
Windows, it returns 0 while in wine I got -1 (0x). This
results in a Segfault for a 3rd party proprietary application (no
source).
0009:Ret KERNEL32.TlsGetValue() retval=001445f8 ret=00501fc1
0009:Call
user32.CallWindowProcA(001b,00010056,132f,,)
ret=004ebf11
0009:Call window proc 0x7e88f0b0
(hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=,lp=)
0009:Call user32.GetWindowLongW(00010056,) ret=7e88f103
0009:Ret user32.GetWindowLongW() retval=0014e928 ret=7e88f103
0009:Ret window proc 0x7e88f0b0
(hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=,lp=)
retval=
0009:Ret user32.CallWindowProcA() retval= ret=004ebf11
0009:Ret window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=,lp=)
retval=
0009:Ret user32.SendMessageA() retval= ret=00416cad
0009:Call KERNEL32.GetLastError() ret=004d3ff9
(...)
0009:Call KERNEL32.UnhandledExceptionFilter(00338b9c) ret=004d8a7d
Sometime in the past, wine 0.9.24 (suse 10.2), this app worked
flawless. I filtered just TAB/TCM messages for version 0.9.24 and
current. For current wine (0.9.48), I got:
# WINEDEBUG=+relay wine VirtFone.exe 21 | egrep '(TCM|TAB)'
0009:Call window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
0009:Call window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
0009:Ret window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
retval=
0009:Ret window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
retval=
0009:Call window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=,lp=0033908c)
0009:Call window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=,lp=0033908c)
0009:Ret window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=,lp=0033908c)
retval=
0009:Ret window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=,lp=0033908c)
retval=
0009:Call window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
0009:Call window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
0009:Ret window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
retval=0001
0009:Ret window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
retval=0001
0009:Call window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0001,lp=0033908c)
0009:Call window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0001,lp=0033908c)
0009:Ret window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0001,lp=0033908c)
retval=0001
0009:Ret window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0001,lp=0033908c)
retval=0001
0009:Call window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
0009:Call window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
0009:Ret window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
retval=0002
0009:Ret window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
retval=0002
0009:Call window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0002,lp=0033908c)
0009:Call window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0002,lp=0033908c)
0009:Ret window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0002,lp=0033908c)
retval=0002
0009:Ret window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0002,lp=0033908c)
retval=0002
0009:Call window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_GETITEMRECT,wp=,lp=003390b4)
0009:Call window
Fwd: New Wine help and discussion forum
-- Forwarded message -- From: Tom Wickline [EMAIL PROTECTED] Date: Oct 29, 2007 5:16 PM Subject: Re: New Wine help and discussion forum To: Dan Kegel [EMAIL PROTECTED] On 10/29/07, Dan Kegel [EMAIL PROTECTED] wrote: On 10/29/07, Tom Wickline [EMAIL PROTECTED] wrote: Well, a single forum and a mailing list is a vast improvement over multiple forums and a mailing list. If you get your way it will be a forum and Google groups, and then you and Google will be the one who kills the Wine user mailing list, not me. ? We seem to be on different planets. Yea we are, because you are the one who ranted about killing the user mailing list in the first place. and now your spinning it to where I want to close down everything. I only want people to have the opportunity to post in a Wine centric forum. and not a Ubuntu or Gentoo or Fedora etc..etc..etc.. forum about Wine! There are quite a few forums where wine problems are discussed. You might need to shut down all of these to achieve your stated goal. Here are a few: http://www.linuxforums.org/forum/wine/ http://www.playonlinux.com/forums/ http://www.frankscorner.org/yabb/YaBB.pl http://www.tatanka.com.br/ies4linux/forum/ http://www.reactos.org/forum/ Thanks, ill send each of them a mail and ask them to cease operation. My stated goal is to not increase the number of discussion forums / mailing lists, yet still appeal to the I hate email generation. I think the google groups front end for the existing mailing list comes pretty close to that... So your goal is to have a single point for discussion? never mind ill let you send out the cease and desist mails. :D Tom - Dan
Re: New Wine help and discussion forum
Hi, On 10/29/07, Dan Kegel [EMAIL PROTECTED] wrote: But unless we kill the wine-users mailing list, you can't achieve your stated goal of having just one place to post. It does help consolidate all other Wine forum discussion that already goes on everywhere else though. My thinking is to leave wine-users, the newsgroup and the forum up for a while and then see which is the most popular/user friendly. If one achieves a dominate position then we can nuke the other venues. I am not even opposed to trying to move wine-users over to a google group as a test...I just don't personally like the interface. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Problems with TAB_GetCurFocus
Hello, I'm having problems with the result of the message TCM_GETCURFOCUS. In Windows, it returns 0 while in wine I got -1 (0x). This results in a Segfault for a 3rd party proprietary application (no source). 0009:Ret KERNEL32.TlsGetValue() retval=001445f8 ret=00501fc1 0009:Call user32.CallWindowProcA(001b,00010056,132f,,) ret=004ebf11 0009:Call window proc 0x7e88f0b0 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=,lp=) 0009:Call user32.GetWindowLongW(00010056,) ret=7e88f103 0009:Ret user32.GetWindowLongW() retval=0014e928 ret=7e88f103 0009:Ret window proc 0x7e88f0b0 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=,lp=) retval= 0009:Ret user32.CallWindowProcA() retval= ret=004ebf11 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=,lp=) retval= 0009:Ret user32.SendMessageA() retval= ret=00416cad 0009:Call KERNEL32.GetLastError() ret=004d3ff9 (...) 0009:Call KERNEL32.UnhandledExceptionFilter(00338b9c) ret=004d8a7d Sometime in the past, wine 0.9.24 (suse 10.2), this app worked flawless. I filtered just TAB/TCM messages for version 0.9.24 and current. For current wine (0.9.48), I got: # WINEDEBUG=+relay wine VirtFone.exe 21 | egrep '(TCM|TAB)' 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=) 0009:Call window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=) 0009:Ret window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=) retval= 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=) retval= 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=,lp=0033908c) 0009:Call window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=,lp=0033908c) 0009:Ret window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=,lp=0033908c) retval= 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=,lp=0033908c) retval= 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=) 0009:Call window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=) 0009:Ret window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=) retval=0001 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=) retval=0001 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0001,lp=0033908c) 0009:Call window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0001,lp=0033908c) 0009:Ret window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0001,lp=0033908c) retval=0001 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0001,lp=0033908c) retval=0001 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=) 0009:Call window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=) 0009:Ret window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=) retval=0002 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=) retval=0002 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0002,lp=0033908c) 0009:Call window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0002,lp=0033908c) 0009:Ret window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0002,lp=0033908c) retval=0002 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0002,lp=0033908c) retval=0002 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMRECT,wp=,lp=003390b4) 0009:Call window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETITEMRECT,wp=,lp=003390b4) 0009:Ret window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETITEMRECT,wp=,lp=003390b4) retval=0001 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETITEMRECT,wp=,lp=003390b4) retval=0001 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_SETCURSEL,wp=,lp=) 0009:Call window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_SETCURSEL,wp=,lp=) 0009:Ret window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_SETCURSEL,wp=,lp=) retval= 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_SETCURSEL,wp=,lp=) retval= 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=,lp=) 0009:Call window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=,lp=) 0009:Ret window proc 0x7e87a0b0 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=,lp=) retval= 0009:Ret window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=,lp=) retval= 0009:Call window proc 0x4eb6b7 (hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=,lp=) 0009:Call window proc 0x7e87a0b0
Re: Problems with TAB_GetCurFocus
It seems that this happens when the tab is not painted yet (window
created hidden) and the current focused tab read.
2297 static void TAB_Refresh (TAB_INFO *infoPtr, HDC hdc)
2298 {
(...)
2328 /* If we haven't set the current focus yet, set it now.
2329 * Only happens when we first paint the tab controls */
2330 if (infoPtr-uFocus == -1)
2331 TAB_SetCurFocus(infoPtr, infoPtr-iSelected);
2332 }
2007/10/29, Luiz Angelo Daros de Luca [EMAIL PROTECTED]:
Hello,
I'm having problems with the result of the message TCM_GETCURFOCUS. In
Windows, it returns 0 while in wine I got -1 (0x). This
results in a Segfault for a 3rd party proprietary application (no
source).
0009:Ret KERNEL32.TlsGetValue() retval=001445f8 ret=00501fc1
0009:Call user32.CallWindowProcA(001b,00010056,132f,,)
ret=004ebf11
0009:Call window proc 0x7e88f0b0
(hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=,lp=)
0009:Call user32.GetWindowLongW(00010056,) ret=7e88f103
0009:Ret user32.GetWindowLongW() retval=0014e928 ret=7e88f103
0009:Ret window proc 0x7e88f0b0
(hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=,lp=)
retval=
0009:Ret user32.CallWindowProcA() retval= ret=004ebf11
0009:Ret window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_GETCURFOCUS,wp=,lp=)
retval=
0009:Ret user32.SendMessageA() retval= ret=00416cad
0009:Call KERNEL32.GetLastError() ret=004d3ff9
(...)
0009:Call KERNEL32.UnhandledExceptionFilter(00338b9c) ret=004d8a7d
Sometime in the past, wine 0.9.24 (suse 10.2), this app worked
flawless. I filtered just TAB/TCM messages for version 0.9.24 and
current. For current wine (0.9.48), I got:
# WINEDEBUG=+relay wine VirtFone.exe 21 | egrep '(TCM|TAB)'
0009:Call window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
0009:Call window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
0009:Ret window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
retval=
0009:Ret window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
retval=
0009:Call window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=,lp=0033908c)
0009:Call window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=,lp=0033908c)
0009:Ret window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=,lp=0033908c)
retval=
0009:Ret window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=,lp=0033908c)
retval=
0009:Call window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
0009:Call window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
0009:Ret window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
retval=0001
0009:Ret window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
retval=0001
0009:Call window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0001,lp=0033908c)
0009:Call window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0001,lp=0033908c)
0009:Ret window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0001,lp=0033908c)
retval=0001
0009:Ret window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0001,lp=0033908c)
retval=0001
0009:Call window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
0009:Call window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
0009:Ret window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
retval=0002
0009:Ret window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_GETITEMCOUNT,wp=,lp=)
retval=0002
0009:Call window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0002,lp=0033908c)
0009:Call window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0002,lp=0033908c)
0009:Ret window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0002,lp=0033908c)
retval=0002
0009:Ret window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_INSERTITEMA,wp=0002,lp=0033908c)
retval=0002
0009:Call window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_GETITEMRECT,wp=,lp=003390b4)
0009:Call window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_GETITEMRECT,wp=,lp=003390b4)
0009:Ret window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_GETITEMRECT,wp=,lp=003390b4)
retval=0001
0009:Ret window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_GETITEMRECT,wp=,lp=003390b4)
retval=0001
0009:Call window proc 0x4eb6b7
(hwnd=0x10056,msg=TCM_SETCURSEL,wp=,lp=)
0009:Call window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_SETCURSEL,wp=,lp=)
0009:Ret window proc 0x7e87a0b0
(hwnd=0x10056,msg=TCM_SETCURSEL,wp=,lp=)
retval=
0009:Ret window proc 0x4eb6b7
Re: New Wine help and discussion forum
Hi, On 10/29/07, Dan Kegel [EMAIL PROTECTED] wrote: So you're the guilty party! Next time you decide to shake up the wine community like that, please consider discussing the move with the developer community first. Yes...well I plead no contest anyway. I did not gather from the Wineconf discussion that we had actually reached consensus on a method. I just thought you we're going to throw the google groups idea out to the community at large. snip As an experiment, I've set up a google groups front end for wine-users. It's at http://groups.google.com/group/wine-users/ For this to become real, we'd have to switch the mailman user list over. Do folks think we should try that? Or do people really think we should kill the mailing list and go to a forum? My vote is for a forum. I am not big on the google groups layout. Tom has offered his services and has a lot of experience with Wine users and support so I think we should go with that. -- Steven Edwards There is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: Extracting rules from comments in wine source code...?
On 10/29/07, Juan Lang [EMAIL PROTECTED] wrote: Supposedly her tool finds bugs in source trees by looking for rules in comments and then checking the software against those rules. Her paper says she found one bug in wine this way... I sure didn't any reference to the actual bug, did you? I didn't look too hard. We could email her and ask...
Re: New Wine help and discussion forum
On 10/29/07, Dan Kegel [EMAIL PROTECTED] wrote: Do folks think we should try that? Or do people really think we should kill the mailing list and go to a forum? I have never said the first word about killing any mailing list. I put up a forum so users would have a singe place to post to, and not have to post to the first forum they ran into that had a Wine section in it. Anyone here can go to any Linux related forum and find post in them about Wine Wine users asking questions to others who may or may not be interested in Wine in the slightest way. I have personally seen people post and ask a question regarding Wine and others have tried there best to steer them away from Wine and the *EVIL* M$ platform software With answers like, if you run a game in Wine *you* are only hurting Linux as this removes incentive for game developers to port to Linux. Or scaring people with the notion a virus could take down there system or turn it into a spam bot! So that I'm clear, I will repeat myself and say I *don't* intend to kill the users mailing list. I do however intend to kill the fact that people didn't have a Wine centric forum to post in, until this morning anyway. If you want to join the forum that is totally your prerogative, its open to the public. Tom - Dan
Re: New Wine help and discussion forum
On 10/29/07, Tom Wickline [EMAIL PROTECTED] wrote: Well, a single forum and a mailing list is a vast improvement over multiple forums and a mailing list. If you get your way it will be a forum and Google groups, and then you and Google will be the one who kills the Wine user mailing list, not me. ? We seem to be on different planets. There are quite a few forums where wine problems are discussed. You might need to shut down all of these to achieve your stated goal. Here are a few: http://www.linuxforums.org/forum/wine/ http://www.playonlinux.com/forums/ http://www.frankscorner.org/yabb/YaBB.pl http://www.tatanka.com.br/ies4linux/forum/ http://www.reactos.org/forum/ My stated goal is to not increase the number of discussion forums / mailing lists, yet still appeal to the I hate email generation. I think the google groups front end for the existing mailing list comes pretty close to that... - Dan
Cleanup of riched20 tests - request for help on test_WM_PASTE
I am currently trying to clean up the riched20 tests that are failing in WinXP. While doing this, I have encountered the following problem: on the function test_WM_PASTE() (at line 1959 of dlls/riched20/tests/editor.c in current git), the test is supposed to feed simulated keystrokes corresponding to Ctrl-C, Ctrl-V, and so on, supposedly to test copy and paste features via the keyboard. The problem is that the verification at line 1989 fails on WinXP, because the text on the control has not been modified - the control seems to disregard simulated WM_CHAR messages of the Ctrl-keystroke variety. The test at line 1977 succeeds accidentally, because the sequence of Ctrl-C, Ctrl-V, Ctrl-Z that is being tested is equivalent to not modifying the control text at all. A more through test would be to send WM_GETTEXT messages after each step to ensure that the text is actually being modified, but the bigger problem is how to make the control obey the keystrokes in the first place. If I place a message loop right before the DestroyWindow() call, I can send keystrokes manually and they work as expected. Only simulated WM_CHAR messages are being discarded. I have tried changing the SendMessage() calls into PostMessage() calls (since Visual Studio's Spy++ shows that WM_CHAR messages were posted, not sent), but to no avail. I have also tried placing message loops between messages, with no luck. I have even tried to simulate the WM_KEYDOWN and WM_KEYUP messages with parameters exactly as seen by Spy++, but this does not work either. So I am asking for help. What could be going wrong with this test? How can I feed the expected keystrokes so that the test works as expected? Has this test ever worked before? It fails in both WinXP (real machine) and inside a QEMU session running Win98. (All tests on WinXP were compiled with CygWin) -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: New Wine help and discussion forum
On 10/29/07, Tom Wickline [EMAIL PROTECTED] wrote: I have never said the first word about killing any mailing list. I put up a forum so users would have a singe place to post to... But unless we kill the wine-users mailing list, you can't achieve your stated goal of having just one place to post. - Dan
Re: opengl problems (commit 00633e37bcc8da1032f34ea2d87814739de07db4)
should i attach the backtraces to the bug submission? Yes, attach them as text file attachments to the bug. Thanks very much! --Juan
Re: opengl problems (commit 00633e37bcc8da1032f34ea2d87814739de07db4)
Juan Lang [EMAIL PROTECTED] writes: wine: Unhandled page fault on read access to 0x at address 0x7da22648 (thread 0014), starting debugger... Unhandled exception: page fault on read access to 0x in 32-bit code (0x7da22648). Gah, please stop spamming us with full back traces. And if you think this is a Wine bug, open a bug in bugzilla - this isn't primarily a bug forum. personally i found a version that works for what i am trying to do so i don't really care any more. i thought somebody else who knows more about this might find the traces of interest. i didn't simply just post back traces, i spent a whole day using git-bisect and recompiling wine until i found the commit that broke things for me. apparently you seem to think this is how wine should behave (and i don't know enough about wine). sorry to have bothered you. good bye. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. |
Trying to submit my first patch
So I tried to submit a patch (to the patch mailing list) a few days ago and got no response (or acceptance), so I'm guessing I need to do something different. It is just a few simple stubs for functions needed to get RO2 (a game) running. The original email is attached. If anyone could tell me what I did wrong it would be appreciated. I'm guessing either because (a) I actually changed the Changelog file and included that in the patch instead of putting it in the email body or (b) nobody is interested in just stubs and I should work on coding them up more (even though it isn't necessary to get the game running.) -- Chris Wulff ---BeginMessage--- 0001-Added-stubs-for-KfAcquireSpinLock-KfLowerIrql-KfRa.patch Description: application/mbox 0002-Added-a-stub-for-FindVolumeMountPointClose.patch Description: application/mbox ---End Message---
Re: opengl problems (commit 00633e37bcc8da1032f34ea2d87814739de07db4)
i thought somebody else who knows more about this might find the traces of interest. i didn't simply just post back traces, i spent a whole day using git-bisect and recompiling wine until i found the commit that broke things for me. Yes, I know you did more than _just_ post backtraces. But they're unreadably long. I could have been more gentle in chiding you about that, I suppose, so I'm sorry if I barked too loud. apparently you seem to think this is how wine should behave (and i don't know enough about wine). I don't know how you could have gotten that conclusion. I asked you to log a bug - that's where problems in wine should be tracked. They can be abandoned either on the mailing list or on bugzilla, of course, but at least on bugzilla we can make an effort to track them. So please, do log that bug, and include the commit that broke it. --Juan
Re: opengl problems (commit 00633e37bcc8da1032f34ea2d87814739de07db4)
Juan Lang [EMAIL PROTECTED] writes: So please, do log that bug, and include the commit that broke it. should i attach the backtraces to the bug submission? --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. |
Re: New Wine help and discussion forum
On 10/29/07, Dan Kegel [EMAIL PROTECTED] wrote: On 10/29/07, Tom Wickline [EMAIL PROTECTED] wrote: I have never said the first word about killing any mailing list. I put up a forum so users would have a singe place to post to... But unless we kill the wine-users mailing list, you can't achieve your stated goal of having just one place to post. - Dan Well, a single forum and a mailing list is a vast improvement over multiple forums and a mailing list. If you get your way it will be a forum and Google groups, and then you and Google will be the one who kills the Wine user mailing list, not me. Tom
Re: Trying to submit my first patch
Hi Chris, So I tried to submit a patch (to the patch mailing list) a few days ago and got no response (or acceptance), so I'm guessing I need to do something different. It is just a few simple stubs for functions needed to get RO2 (a game) running. The original email is attached. If anyone could tell me what I did wrong it would be appreciated. Two small things: 1. You're right, you don't need to include changes to the ChangeLog, they're generated from git commits anyway. 2. Please include your name in your emails. This one does (thanks) but the patch email should as well. Aside from that, I'm guessing the hal patch just looks ugly due to the wacky calling convention and assembly, so you might wait for feedback from Alexandre on that. If you don't hear anything, ask again in a couple days ;) Thanks for contributing, --Juan
Re: Bug in dlls/oleaut32/tests/vartype.c?
Gerald Pfeifer escribió:
On Mon, 15 Oct 2007, Gerald Pfeifer wrote:
dlls/oleaut32/tests/vartype.c has the following snippet of code:
+ f = -1e-400;/* deliberately cause underflow */
+ hres = pVarBstrFromR4(f, lcid, 0, bstr);
+ ok(hres == S_OK, got hres 0x%08lx\n, hres);
+ if (bstr)
+ {
+todo_wine ok(memcmp(bstr, szZero, sizeof(szZero)) == 0, negative
zero (got %s)\n, wtoascii(bstr));
+ }
which was added in
revision 1.27
Alex Villacís Lasso [EMAIL PROTECTED]
Test for behavior of negative underflow formatting.
This doesn't seem to work as intended, because it is a floating point
*constant* which current versions of GCC simply truncate to 0.0.
The following patch tries to address this.
Gerald
ChangeLog:
Avoid truncation of floating point calculation at compile-time.
Index: dlls/oleaut32/tests/vartype.c
===
RCS file: /home/wine/wine/dlls/oleaut32/tests/vartype.c,v
retrieving revision 1.51
diff -u -3 -p -r1.51 vartype.c
--- dlls/oleaut32/tests/vartype.c 20 Aug 2007 12:43:49 - 1.51
+++ dlls/oleaut32/tests/vartype.c 29 Oct 2007 22:40:24 -
@@ -4727,6 +4727,7 @@ static void test_VarBstrFromR4(void)
HRESULT hres;
BSTR bstr = NULL;
+ const float flarge=1e20;
float f;
CHECKPTR(VarBstrFromR4);
@@ -4747,7 +4748,7 @@ static void test_VarBstrFromR4(void)
}
}
- f = -1e-400;/* deliberately cause underflow */
+ f = (-1 / flarge ) / flarge;/* deliberately cause underflow */
hres = pVarBstrFromR4(f, lcid, 0, bstr);
ok(hres == S_OK, got hres 0x%08x\n, hres);
if (bstr)
Sorry to object, but which version of exactly which compiler optimizes
away the negative sign?
Consider the following program:
#include stdio.h
#include stdlib.h
union x
{
float f;
unsigned char b[4];
};
int main(void)
{
union x u;
u.f = -1e-400;
printf(Value as float is %f\n, u.f);
printf(Value as bytes is %02x %02x %02x %02x\n, u.b[0], u.b[1],
u.b[2], u.b[3]);
return 0;
}
On my machine (i386 architecture, Fedora 7, gcc 4.1.2 20070925 (Red Hat
4.1.2-27)), the output is as follows:
[EMAIL PROTECTED] cpp]$ gcc -O2 -Wall test_underflow.c -o test_underflow
[EMAIL PROTECTED] cpp]$ ./test_underflow
Value as float is -0.00
Value as bytes is 00 00 00 80
[EMAIL PROTECTED] cpp]$
What compiler are you using? Which version? What is the output of said
compiler on the test program?
--
perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
Re: Trying to submit my first patch
Juan, Thanks for the quick response. The fastcall assembly I actually copied from another DLL (I think it was in ntoskrnl.exe or ntdll.dll.) There should probably be a standard place for the fastcall macros instead, but I didn't see one off hand. If you happen to know a good place to put them I can always clean that up and submit a new patch. It is too bad that the fastcall conventions aren't standardized between the various compilers so we have to force the windows ones though. -- Chris Wulff - Original Message - From: Juan Lang [EMAIL PROTECTED] Date: Monday, October 29, 2007 7:18 pm Subject: Re: Trying to submit my first patch To: [EMAIL PROTECTED] [EMAIL PROTECTED] Cc: wine-devel@winehq.org Hi Chris, So I tried to submit a patch (to the patch mailing list) a few days ago and got no response (or acceptance), so I'm guessing I need to do something different. It is just a few simple stubs for functions needed to get RO2 (a game) running. The original email is attached. If anyone could tell me what I did wrong it would be appreciated. Two small things: 1. You're right, you don't need to include changes to the ChangeLog, they're generated from git commits anyway. 2. Please include your name in your emails. This one does (thanks) but the patch email should as well. Aside from that, I'm guessing the hal patch just looks ugly due to the wacky calling convention and assembly, so you might wait for feedback from Alexandre on that. If you don't hear anything, ask again in a couple days ;) Thanks for contributing, --Juan
Re: opengl problems (commit 00633e37bcc8da1032f34ea2d87814739de07db4)
Juan Lang [EMAIL PROTECTED] writes: So please, do log that bug, and include the commit that broke it. it's been reported as bug 10234. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. |
Re: New Wine help and discussion forum
Am Montag, 29. Oktober 2007 19:18:29 schrieb Steven Edwards: I can't speak for Tom on this issue, though I was the one to suggest that he start the forum after the Wineconf discussions regarding the mailing list and newsgroup disconnection. I think long term we might want to see about just killing the users mailing list if the forum proves to be much more popular. The idea is to have ONE central place for all user discussions. Most users these days tend to be content with a forum like system, see the proliferation of blogs as an example. I suggested to create a forum because users are familiar with phpbb, but not with mailman. Tom wasn't on wineconf this time, unless I missed him 3 days long. signature.asc Description: This is a digitally signed message part.
Re: Bug in dlls/oleaut32/tests/vartype.c?
On Mon, 15 Oct 2007, Gerald Pfeifer wrote:
dlls/oleaut32/tests/vartype.c has the following snippet of code:
+ f = -1e-400;/* deliberately cause underflow */
+ hres = pVarBstrFromR4(f, lcid, 0, bstr);
+ ok(hres == S_OK, got hres 0x%08lx\n, hres);
+ if (bstr)
+ {
+todo_wine ok(memcmp(bstr, szZero, sizeof(szZero)) == 0, negative zero
(got %s)\n, wtoascii(bstr));
+ }
which was added in
revision 1.27
Alex Villacís Lasso [EMAIL PROTECTED]
Test for behavior of negative underflow formatting.
This doesn't seem to work as intended, because it is a floating point
*constant* which current versions of GCC simply truncate to 0.0.
The following patch tries to address this.
Gerald
ChangeLog:
Avoid truncation of floating point calculation at compile-time.
Index: dlls/oleaut32/tests/vartype.c
===
RCS file: /home/wine/wine/dlls/oleaut32/tests/vartype.c,v
retrieving revision 1.51
diff -u -3 -p -r1.51 vartype.c
--- dlls/oleaut32/tests/vartype.c 20 Aug 2007 12:43:49 - 1.51
+++ dlls/oleaut32/tests/vartype.c 29 Oct 2007 22:40:24 -
@@ -4727,6 +4727,7 @@ static void test_VarBstrFromR4(void)
HRESULT hres;
BSTR bstr = NULL;
+ const float flarge=1e20;
float f;
CHECKPTR(VarBstrFromR4);
@@ -4747,7 +4748,7 @@ static void test_VarBstrFromR4(void)
}
}
- f = -1e-400;/* deliberately cause underflow */
+ f = (-1 / flarge ) / flarge;/* deliberately cause underflow */
hres = pVarBstrFromR4(f, lcid, 0, bstr);
ok(hres == S_OK, got hres 0x%08x\n, hres);
if (bstr)
Re: New Wine help and discussion forum
[Hmm, I thought you wanted to take the discussion offlist, but I see you forwarded to the list. Here's a catchup message.] On 10/29/07, Dan Kegel [EMAIL PROTECTED] wrote: On 10/29/07, Tom Wickline [EMAIL PROTECTED] wrote: My stated goal is to not increase the number of discussion forums / mailing lists, yet still appeal to the I hate email generation. I think the google groups front end for the existing mailing list comes pretty close to that... So your goal is to have a single point for discussion? No, my goal is simply to not make the situation worse. [There were more messages after that. Here's the key bit:] Tom wrote: Whats so bad about both Google groups and a forum? If you try to pull as many people as you can toward the groups and I do the same for the forum. then if we get 90% of the discussion on two groups its better then what the situation was yesterday... do you agree with that? I replied: Having one more forum dilutes the community. ... If you try to pull as many people as you can toward the groups and I do the same for the forum. then if we get 90% of the discussion on two groups its better then what the situation was yesterday... do you agree with that? Not really. That said, I can see your vision, and I agree there is some small chance it might succeed and improve the situation. The real issues are mixed up with a culture war (email vs. forum), which makes the discussion a bit murky. C'est la vie. - Dan
RE: New Wine help and discussion forum
From: [EMAIL PROTECTED] To: wine-devel@winehq.org Subject: Re: New Wine help and discussion forum Date: Tue, 30 Oct 2007 01:10:43 +0100 CC: [EMAIL PROTECTED]; [EMAIL PROTECTED] . I suggested to create a forum because users are familiar with phpbb, but not with mailman. Tom wasn't on wineconf this time, unless I missed him 3 days long. I think phpbb is more user friendly than what we got right now. That and the amount of spam I receive in my inbox directed at the current mail lists. I'm tired of getting emails telling me I've won the lottery directed to my inbox from wine, it takes too long to clear it all out. _ Windows Live Hotmail and Microsoft Office Outlook – together at last. Get it now. http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033
Re: tools/widl/typegen.c pointer initialization
On Sun, Oct 28, 2007 at 07:07:15PM -0700, Dan Kegel wrote: To get uninitialized warnings, you have to also specify optimization (-O2). Without -O, gcc doesn't do the analysis that can detect uninitialized variables. Compiling with -O2 -W -Wall using either gcc 4.0 or 3.4 I don't get any warnings. Even adding -Wuninitialized doesn't do anything: $ make clean make -j1 CFLAGS=-O2 -W -Wall -Wuninitialized 21 | fgrep warning widl.c:189: warning: unused parameter 'sig' parser.yy.c:1276: warning: comparison between signed and unsigned
