http://bugs.winehq.org/show_bug.cgi?id=5503
------- Additional Comments From Ronny.Standtke(a)gmx.net 2006-13-10 17:51 -------
Same bug with wine-0.9.23. Does any developer actually care or am I preaching
in the desert?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=5774
------- Additional Comments From citizenr(a)gmail.com 2006-13-10 17:33 -------
blah, and even when I do get /high ID/open all I have to do is wait a while to
see KAd disconnecting and never connecting again :(((
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=5774
------- Additional Comments From citizenr(a)gmail.com 2006-13-10 17:19 -------
just tried emule 0.47c, It gets low ID/firewalled once in 2-10 times
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=6440
truiken(a)gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|wine-net |wine-ole
------- Additional Comments From truiken(a)gmail.com 2006-13-10 17:11 -------
Correcting component.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=6425
truiken(a)gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|wine-msi |wine-ole
------- Additional Comments From truiken(a)gmail.com 2006-13-10 17:09 -------
This is a bug in ole. Running with native ole32,oleaut32,rpcrt4 gets past this
bug (and the app installs successfully). There is a condition in the
ControlEvents table that prevents the next dialog from showing:
AgreeToLicense = "Yes" and PROVIDEX_INSTALLED_COUNT = 0 and RC1 <> "Y"
AgreeToLicense is "Yes" and RC1 is not "Y", but PROVIDEX_INSTALLED_COUNT is not
an initialized property. PROVIDEX_INSTALLED_COUNT should be set to 0 in the
FindInstalledProvidex custom action, but it is not. I'm not an ole guru by any
means, but if I read the log correctly, the custom action tries to call a method
in an IDispatch interface that is remote (different process).
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=6440
Summary: emule Call from 0x7ee65f30 to unimplemented function
rpcrt4.dll.I_RpcExceptionFilter, aborting
Product: Wine
Version: 0.9.22.
Platform: Other
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-net
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: citizenr(a)gmail.com
When running emule with wine set to XP I get:
wine: Call from 0x7ee65f30 to unimplemented function
rpcrt4.dll.I_RpcExceptionFilter, aborting
wine: Call from 0x7ee65f30 to unimplemented function
rpcrt4.dll.I_RpcExceptionFilter, aborting
wine: Call from 0x7ee65f30 to unimplemented function
rpcrt4.dll.I_RpcExceptionFilter, aborting
wine: Call from 0x7ee65f30 to unimplemented function
rpcrt4.dll.I_RpcExceptionFilter, aborting
err:seh:setup_exception stack overflow 836 bytes in thread 0015 eip b7d21dc3
esp 7bcdecbc stack 0x7bcdf000-0x7bdef000
after that program runs, but in the background, doesnt draw its interface (only
tray icon, but its dead, no RMB menu)
it downloads and uploads (i can see it with wireshark). Only way to turn it off
is to 'kill -9' it, ordinary kill leaves "emule.exe<defunc>" or something like
that.
I tried to force native rpcrt4.dll, that gave me this :
fixme:ntdll:NtConnectPort (0x1a8baa8,L"\\RPC
Control\\DNSResolver",0x7bde923c,(nil),(nil),(nil),0x7bde9264,0x7bde924c),stub!
fixme:ntdll:NtConnectPort (0x1a8baa8,L"\\RPC
Control\\DNSResolver",0x7bde923c,(nil),(nil),(nil),0x7bde9264,0x7bde924c),stub!
fixme:ntdll:NtConnectPort (0x1a8baa8,L"\\RPC
Control\\DNSResolver",0x7bde923c,(nil),(nil),(nil),0x7bde9264,0x7bde924c),stub!
wine: Call from 0x77e78887 to unimplemented function
ntdll.dll.RtlDllShutdownInProgress, aborting
running with Win98 gives same
wine: Call from 0x7ee65f30 to unimplemented function
rpcrt4.dll.I_RpcExceptionFilter, aborting
err:seh:setup_exception stack overflow 836 bytes in thread 001d eip b7ce4dc3
esp 7bbcbcbc stack 0x7bbcc000-0x7bcdc000
error, but the interface is going up and program works normal.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=3902
damjan.jov(a)gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #3761 is|0 |1
obsolete| |
------- Additional Comments From damjan.jov(a)gmail.com 2006-13-10 16:41 -------
Created an attachment (id=3848)
--> (http://bugs.winehq.org/attachment.cgi?id=3848&action=view)
dirty rectangle patch, v2
Well, found out why the dirty rectangle patch sometimes crashes winecfg (a
pointer is sometimes NULL), so I posted a new patch that doesn't crash crash.
It's against wine-0.9.23, but it should apply cleanly to 0.9.22 (since the
0.9.22 patch applies cleanly against 0.9.23).
As far as the client-side DIB copy patch goes, the width and height of the
source and destination rectangles have to be the same, otherwise X11DRV_BitBlt
(and hence my code) never gets called. I did thorough checks against the x-y
coordinates and width and height - they're always valid, positive, in-range -
perfect in every way.
But I tried to copy the original destination pixels into a buffer, then copy
pixels from source to destination, then mark the image DIB_Status_GdiMod and
coerce it to DIB_Status_InSync (forcing the image to be downloaded from the X
server again), and compare the newly downloaded image with the originally
downloaded image. The result? They differ! Somehow, the X server is modifying
the image while the pixels are being copied client-side. I've tried using
wine_tsx11_lock(), XFlush(), GdiFlush(), glFinish(), tried locking the image in
DIB_Status_AppMod or DIB_Status_InSync instead of the current DIB_Status_None,
and nothing worked.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
http://bugs.winehq.org/show_bug.cgi?id=3902
------- Additional Comments From kfiaciarka(a)gentoo.pl 2006-13-10 15:52 -------
Under gentoo I added these patches and compiled wine 0.9.22. Patches applied
cleanly. But when I run
rm -rf .wine
konrad@test ~ $ winecfg
wine: creating configuration directory '/home/konrad/.wine'...
fixme:midi:OSS_MidiInit Synthesizer supports MIDI in. Not yet supported.
Failed to open the service control manager.
fixme:ole:ITypeInfo_fnRelease destroy child objects
wine: '/home/konrad/.wine' created successfully.
fixme:midi:OSS_MidiInit Synthesizer supports MIDI in. Not yet supported.
wine: Unhandled page fault on read access to 0x00000054 at address 0x7e5b04b4
(thread 0009), starting debugger...
Modules:
Cannot get info on module while no process is loaded
Threads:
process tid prio (all id:s are in hex)
0000000a
0000000c 0
0000000b 0
00000008 (D) (null)
00000009 0
I got this message and winecfg crashes:/
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.