Any chance of a hand with this please?
I have just traced a problem to the fact that __pthread_atfork is passed a
couple of null pointers, which I presume is an illegal thing to do. Can
anyone point me at the code that results in __pthread_atfork being called
and/or explain why it would be called with null pointers?
TIA
Bill
"David Hammerton" <david(a)transgaming.com> writes:
> BTW, One of the siderfects of this is: in dlls/x11drv/window.c line 1143,
> GetMessageTime() is sometimes 0 (depends on the applicatoin, for example the
> game Alice seems to make it return 0) - so the value sent to XSetInputFocus for
> the time is too small, and hence X refuses to give the window focus.
The real fix is that XSetInputFocus should not use GetMessageTime at
all, this is only a temporary hack. To conform to the ICCCM the focus
time should be based on the timestamp of a previous X event, and the
focus should never be changed if we didn't receive an event. To do
this right probably requires supporting the take focus protocol, as
was discussed some time ago.
--
Alexandre Julliard
julliard(a)winehq.com
In my pitiful attempt to hack on WINE I have come to an impasse. I have
managed to find portable equivalents to get the interface name and the number
of interfaces in winsock/wsock32 but I can't seem to find a portable way to
get to the routing table. In Solaris (why I'm doing the hacking) there is a
vague mention in the man pages of being able to get this info by reading
/dev/ip but no information about how to actually do it.
Can anyone provide a hint on how this can be done portably or to a multi-os
implementation of netstat that might serve as an example. (Only netstat
sources I have found are OS specific)
Hurry because in desperation I am actually thinking of piping the output of
netstat -r
Thanks
Bob
Hi all,
the game Undying emits lots and lots of
err:msg:DispatchMessageA BeginPaint not called on WM_PAINT for hwnd 20029!
errors.
This is because it simply does:
0806d2c8:Call user32.DispatchMessageA(406c29b0) ret=1090e313
0806d2c8:Call window proc 0x11001530 (hwnd=00020029,msg=WM_PAINT,wp=00000000,lp=00000000)
0806d2c8:Call user32.ValidateRect(00020029,00000000) ret=11107b57
0806d2c8:Ret user32.ValidateRect() retval=00000001 ret=11107b57
0806d2c8:Ret window proc 0x11001530 (hwnd=00020029,msg=WM_PAINT,wp=00000000,lp=00000000) retval=00000000
This seems to be perfectly legal in order to validate the whole window
update rect (NULL) and thus prevent further WM_PAINTs.
(as http://www.intrepidhero.com/articles/wgpfd_errata/part2.html hints)
In short: the wine error message is erroneous in this case.
The Wine check is:
if (painting && wndPtr &&
(wndPtr->flags & WIN_NEEDS_BEGINPAINT) && wndPtr->hrgnUpdate)
{
ERR("BeginPaint not called on WM_PAINT for hwnd %04x!\n",
msg->hwnd);
So I assume that either
a)
some flag or so doesn't get updated properly by that ValidateRect()
or
b)
the error message check condition is (slightly) wrong.
Could someone please fix this ?
This happened to #WineHQ nick Thunderbird with latest version of
winex (20010824).
--
Andreas Mohr Stauferstr. 6, D-71272 Renningen, Germany
Tel. +49 7159 800604 http://home.nexgo.de/andi.mohr/
Hey,
Durings my hunting down for why SetFocus wasnt always working, I have traced it
back to a problem with GetMessageTime(). (which I have made a temporary fix
for, haven't sent it to wine-patches because its not the 'right' way of fixing
it)
GetMessageTime() is supposed to return the time of the last message received by
GetMessage().
But there are two cases where the time set (req->time) is 0 - and I can't fix
it.
If you turn your eyes to server/queue.c, around line 910 and 926 you will see
the two times this value gets set to 0. Statically.
I believe the only way to fix this is some sort of restructuring, since
GetCurrentTime() (used by all other functions that set req->time) relies on a
variable thats not available to the wine server.
Anyone else have any suggestions?
BTW, One of the siderfects of this is: in dlls/x11drv/window.c line 1143,
GetMessageTime() is sometimes 0 (depends on the applicatoin, for example the
game Alice seems to make it return 0) - so the value sent to XSetInputFocus for
the time is too small, and hence X refuses to give the window focus.
As I said i've written a small patch for this, I may send it to wine-patches if
its worth it, but I really think that the source of the problem should be
addressed more urgently.
David.
--
David Hammerton, web programmer
TransGaming Technologies Inc.
http://www.transgaming.com
david(a)transgaming.com
Hello all.
This patch fixes a couple of problems with keyboard group switching
reported in the news group:
1. Group switch had never worked before, if the keyboard has been
switched outside of Wine.
2. I was clearly stated that Group switch is active if event->state & 0x2000,
not event->state & 0x6000.
Please test it on your local configurations and report back. If there will be
no objections, I'll send it to wine-patches.
Thanks.
--
Dmitry.
Hello,
with MS WinWord I am encountering the following problem:
If there's something selected, GetClipboardData is called.
In GetClipboardData, there is the line:
HWND hWnd = (hWndClipWindow) ? hWndClipWindow : GetActiveWindow();
hWndClipWindow is 0, so GetActiveWindow() is called which also returns
0.
I tracked this down to PERQDATA_GetActiveWnd returning 0.
This leads later to "w" bening 0 which results in an X error calling
XConvertSelection.
It happens in all modes, desktop managed, non managed.
Does anybody have any clues ?
Dominik
--
Dominik Strasser | Phone: +49 89 636-43691
SIEMENS AG | Fax: +49 89 636-42284
CT SE 4 | E-Mail:[email protected]
Otto-Hahn-Ring 6 |
D-81739 Muenchen | Room: 53-263
Is this a known problem? When I try to run the callwave install
program, or the callwave program itself, I merely get:
fixme:win32:PE_CreateModule Security directory ignored
err:seh:start_debugger Couldn't start debugger (debugger/winedbg 134640112 24) (2)
Read the Wine Developers Guide on how to set up winedbg or another debugger
Is this a configuration error on my part? Either way, is there some
information I need to give to get this fixed? I appreciate it.
Thanks
--
-Steven
In a time of universal deceit, telling the truth is a revolutionary act.
-- George Orwell
Freedom is slavery. Ignorance is strength. War is peace.
-- George Orwell
Jeremy White <jwhite(a)codeweavers.com> writes:
> Okay, so it's a slow news day, and I feel like stirring up trouble.
Bad boy...
> I would argue that it is, in fact, counterintuitive, to have this
> sort of comment solely in the change log. The only time I ever think
> to look at a diff (or even the change log) is when something has broken
> recently.
Well, because *you* don't look at it doesn't mean it's not the right
place, does it? <g> I look at the CVS history quite often, and I find
that in many cases it's the best way to find out why things are done a
certain way.
I don't see any reason to duplicate this info inside the code itself;
since we are using a source control system we might as well take
advantage of it. Plus it guarantees the info is stored permanently,
unlike a comment that may get moved or lost next time the code is
changed.
--
Alexandre Julliard
julliard(a)winehq.com
Aric Stewart <aric(a)codeweavers.com> writes:
> I think this is part of what the change log is for.
>
> Alexandre has committed the patch, i will ask him if he wants me to
> document something further and submit another patch.
I added a comment in wsprintf16 to make Andreas happy. But I agree
that the change log (and cvs diff) is the best way to store this kind
of information.
--
Alexandre Julliard
julliard(a)winehq.com
