http://bugs.winehq.org/show_bug.cgi?id=2014
Speeddymon(a)gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
------- Additional Comments From Speeddymon(a)gmail.com 2007-16-03 14:53 -------
Closing
--
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=2014
Speeddymon(a)gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Additional Comments From Speeddymon(a)gmail.com 2007-16-03 14:52 -------
Game now shows on screen properly. Fixed.
--
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=7762
------- Additional Comments From mike.clarkson(a)baesystems.com 2007-16-03 14:40 -------
Have you tested the shortcut (bar.lnk) to see if it works? For me a file is
created with the correct name, but it is NOT a valid shortcut.
If you are creating a valid shortcut, then it may be a difference in the wine
configuration or version, and I'd like to know what version and configuration
you are using.
Thanks
--
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=765
Speeddymon(a)gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
------- Additional Comments From Speeddymon(a)gmail.com 2007-16-03 14:39 -------
So then a different patch was committed in git format that fixed this? I'll
resolve for now. Francois, if this is fixed, could you either mark it as
verified or close it please?
--
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.
You are on the CC list for the bug, or are watching someone who is.
http://bugs.winehq.org/show_bug.cgi?id=219
------- Additional Comments From Speeddymon(a)gmail.com 2007-16-03 14:37 -------
I think the problem (as is with most times a safedisc patch has been written) is
that the patch is either way too hacky, or is made by reverse engineering the
safedisc dll's from windows.. Most likely Ivan did not reverse the dll's as I
know he would not want to poison the tree, so my bet is that it is just too big
of a hack for Alexandre to commit, combined with the fact that it is nearly
impossible to break something like this up into smaller patches without
completely breaking everything.
--
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=7690
juan_lang(a)yahoo.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #5389 is|0 |1
obsolete| |
------- Additional Comments From juan_lang(a)yahoo.com 2007-16-03 14:16 -------
Created an attachment (id=5390)
--> (http://bugs.winehq.org/attachment.cgi?id=5390&action=view)
Revised patch
Whoops - slight error in the last. This patch does get past that particular
error message, but leads to another crash. I'll send this patch and update the
comments shortly.
--
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=7712
------- Additional Comments From focht(a)gmx.net 2007-16-03 14:14 -------
Hello,
>Well I don't think the program itself calls DefWindowProcA, but it gets called
>as part of the CreateWindow sequence.
Yes its correct the program registers unicode classes but creates ANSI windows
(CreateWindowExA) and sets ANSI window procs ((SetWindowLong -> A)
Code later uses "W" versions of api on "A" windows which triggers custom/default
"A" window proc.
This is no problem at all but imposes implicit A<->W conversions.
Take the window title for instance.
The apps calls "SetWindowTextW" version, supplying WCHAR string.
On windows SetWindowTextW() is implemented by SendMessageW (technically
SendMessageWorker) which result in WM_SETTEXT message routed to window proc.
Windows *knows* the target window proc is "ANSI" and converts specific messages
to corresponding ANSI/WCHAR before delivering message.
After conversion, WM_SETTEXT is called with ansi string and gets processed by
default "A" window proc.
The wine side taken from trace:
--- snip ---
0009:Call user32.SetWindowTextW(00060028,006fa440 L"Error") ret=0045a2e9
trace:msg:WINPROC_CallProcWtoA (hwnd=0x60028,msg=WM_SETTEXT,wp=00000000,lp=006fa440)
0009:Call window proc 0x476960 (hwnd=0x60028,msg=WM_SETTEXT,wp=00000000,lp=0034f2b0)
0009:Call user32.GetPropA(00060028,005f87b8 "FxMessageHandler") ret=0047697d
0009:Ret user32.GetPropA() retval=0034fb68 ret=0047697d
0009:Call user32.CallWindowProcA(ffff0021,00060028,0000000c,00000000,0034f2b0)
ret=00476919
trace:msg:WINPROC_CallProcAtoW (hwnd=0x60028,msg=WM_SETTEXT,wp=00000000,lp=0034f2b0)
0009:Call window proc 0x603de034
(hwnd=0x60028,msg=WM_SETTEXT,wp=00000000,lp=0034e830)
0009:Call user32.DefWindowProcA(00060028,0000000c,00000000,0034e830) ret=6047732a
0009:Call winex11.drv.SetWindowText(00060028,001d4430 L"E") ret=6040d3d8
0009:Ret winex11.drv.SetWindowText() retval=00000001 ret=6040d3d8
0009:Ret user32.DefWindowProcA() retval=00000001 ret=6047732a
0009:Ret window proc 0x603de034
(hwnd=0x60028,msg=WM_SETTEXT,wp=00000000,lp=0034e830) retval=00000001
0009:Ret user32.CallWindowProcA() retval=00000001 ret=00476919
0009:Ret window proc 0x476960
(hwnd=0x60028,msg=WM_SETTEXT,wp=00000000,lp=0034f2b0) retval=00000001
0009:Ret user32.SetWindowTextW() retval=00000001 ret=0045a2e9
--- snip ---
The "W" call is translated to ANSI before calling next in chain.
"GetPropA" is called by app's own registered proc which in turn fetches internal
"FxMessageHandler" window proc (ANSI!)
The app's message handler relays to default window proc (hence the call to
CallWindowProcA)
Which in turn calls CallProcAtoW() (unicode conversion again!)
DefWindowProcA() is fed with unicode whichs results in incorrect behaviour.
You see double conversions for each msg which has string based parameters all
along the trace:
trace:msg:WINPROC_CallProcWtoA(hwnd=0x60028,msg=WM_SETTEXT,wp=00000000,lp=006fa440)
...
trace:msg:WINPROC_CallProcAtoW(hwnd=0x60028,msg=WM_SETTEXT,wp=00000000,lp=0034f2b0)
Anyway that apps seems horribly bugged mixing unicode and ansi stuff at several
places.
I guess they linked in some unicode 3rd party stuff but their main code is ansi
or vice versa.
> FYI, make sure to run Weatherscope with the full path or it _will_ crash.
This crash is due to their crappy commandline parser.
Just simulate GetCommandLineArgsA() with "" or "\\" stuff missing. *boom*
Another one is the installer itself.
Why cant they just use standard installshield stuff like <ProgramFilesFolder>.
It insists installing to "c:\Program Files\" on my german install (should do it
to "c:\Programme")
Regards
--
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.