Hello Everyone,
I am trying to run a windows application under WINE program loader, but it fails when trying to find other local application windows, It seems when it run under wine, it can't "SEE" other Local X application.
How can I solve this problem?
Thanks in advance
--------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month!
it can't "SEE" other Local X application.
Can you send precisely the error printed on your screen? Also can you send an error log .
Stephan
Hello Stephan,
Thanks a lot for your help!
The error printed on my screen is:
fixme:class:get_class_ptr reading from class of other process window 0x2002a err:win:WIN_FindWndPtr window 0x2003a belongs to other process
Also I found other errors when I launch my window appication under wine:
err:module:import_dll No implementation for USER32.dll.GetTitleBarInfo imported from C:\ping\exe\ping.exe, setting to 0xdeadbeef err:module:import_dll No implementation for USER32.dll.GetMenuBarInfo imported from C:\ping\exe\ping.exe, setting to 0xdeadbeef
Actually I found all these problems reported by someone else, but I don't know how to fix them?
Thanks for answering.
Best wishes.
BiGgUn fbiggun@hotmail.com wrote:
it can't "SEE" other Local X application.
Can you send precisely the error printed on your screen? Also can you send an error log .
Stephan
--------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month!
fixme:class:get_class_ptr reading from class of other process window 0x2002a err:win:WIN_FindWndPtr window 0x2003a belongs to other process
Well these two are known problems. I think it's something Alexandre will be working on at some point, inter-process window communication isn't really implemented well in Wine at present.
Also I found other errors when I launch my window appication under wine:
err:module:import_dll No implementation for USER32.dll.GetTitleBarInfo imported from C:\ping\exe\ping.exe, setting to 0xdeadbeef err:module:import_dll No implementation for USER32.dll.GetMenuBarInfo imported from C:\ping\exe\ping.exe, setting to 0xdeadbeef
Unless the program actually uses them, this isn't a problem. If it does, the app will crash, at which point we'd need to write those functions or stub them out.
thanks -mike
Thank you for response. The following is my further question:
Here is my case:
Now I am trying to run our own developed application under wine, the original function of this app is working as a background daemon without GUI who is trying to figure out some window information under the current cursor, such as the window title, class name using GetWindowTitle, GetClassName ... WIN32 API calls.
When I run this under WINE, it can't "see" any other Local X application windows such as Xterm, Xclock... which don't run under WINE.
I am wondering whether I can recompile the codes to generate a lcoal X application using winelib to solve this problem, or I must write X11 based codes?
Thanks a lot!
-Lechun
Mike Hearn mike@theoretic.com wrote:
fixme:class:get_class_ptr reading from class of other process window 0x2002a err:win:WIN_FindWndPtr window 0x2003a belongs to other process
Well these two are known problems. I think it's something Alexandre will be working on at some point, inter-process window communication isn't really implemented well in Wine at present.
Also I found other errors when I launch my window appication under wine:
err:module:import_dll No implementation for USER32.dll.GetTitleBarInfo imported from C:\ping\exe\ping.exe, setting to 0xdeadbeef err:module:import_dll No implementation for USER32.dll.GetMenuBarInfo imported from C:\ping\exe\ping.exe, setting to 0xdeadbeef
Unless the program actually uses them, this isn't a problem. If it does, the app will crash, at which point we'd need to write those functions or stub them out.
thanks -mike
--------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month!
Programs run under emulation are only aware of other Wine programs. If you want to write an app like that, you'd need to rewrite it for Linux.
BTW, you might want to talk to a guy named Bill Haneman (i think that's the spelling). He does Gnome accessibility, and i think they have an app that can read info about stuff under the mouse cursor.
On Thu, 2003-07-10 at 20:41, dd jj wrote:
Thank you for response. The following is my further question:
Here is my case:
Now I am trying to run our own developed application under wine, the original function of this app is working as a background daemon without GUI who is trying to figure out some window information under the current cursor, such as the window title, class name using GetWindowTitle, GetClassName ... WIN32 API calls.
When I run this under WINE, it can't "see" any other Local X application windows such as Xterm, Xclock... which don't run under WINE.
I am wondering whether I can recompile the codes to generate a lcoal X application using winelib to solve this problem, or I must write X11 based codes?
Thanks a lot!
-Lechun
Mike Hearn mike@theoretic.com wrote: > fixme:class:get_class_ptr reading from class of other process window > 0x2002a > err:win:WIN_FindWndPtr window 0x2003a belongs to other process
Well these two are known problems. I think it's something Alexandre will be working on at some point, inter-process window communication isn't really implemented well in Wine at present. > Also I found other errors when I launch my window appication under > wine: > > err:module:import_dll No implementation for USER32.dll.GetTitleBarInfo > imported from C:\ping\exe\ping.exe, setting to 0xdeadbeef > err:module:import_dll No implementation for USER32.dll.GetMenuBarInfo > imported from C:\ping\exe\ping.exe, setting to 0xdeadbeef > Unless the program actually uses them, this isn't a problem. If it does, the app will crash, at which point we'd need to write those functions or stub them out. thanks -mike
Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month!
Hello Mike,
So as my understanding, even recompile the original windows codes using WINELIB will not work, am I correct?
Since finding window info under cursor is only one of the functionality in this application, it will be a huge work to rewrite all the codes for X window. Is there any Avenue to port such a windows application to Linux? Using Visual Mainwin or Win/U is better choices? or any other comments on it?
Thanks a lot!
-Lechun
Mike Hearn mike@theoretic.com wrote: Programs run under emulation are only aware of other Wine programs. If you want to write an app like that, you'd need to rewrite it for Linux.
BTW, you might want to talk to a guy named Bill Haneman (i think that's the spelling). He does Gnome accessibility, and i think they have an app that can read info about stuff under the mouse cursor.
On Thu, 2003-07-10 at 20:41, dd jj wrote:
Thank you for response. The following is my further question:
Here is my case:
Now I am trying to run our own developed application under wine, the original function of this app is working as a background daemon without GUI who is trying to figure out some window information under the current cursor, such as the window title, class name using GetWindowTitle, GetClassName ... WIN32 API calls.
When I run this under WINE, it can't "see" any other Local X application windows such as Xterm, Xclock... which don't run under WINE.
I am wondering whether I can recompile the codes to generate a lcoal X application using winelib to solve this problem, or I must write X11 based codes?
Thanks a lot!
-Lechun
Mike Hearn wrote:
fixme:class:get_class_ptr reading from class of other
process window
0x2002a err:win:WIN_FindWndPtr window 0x2003a belongs to other
process
Well these two are known problems. I think it's something Alexandre will be working on at some point, inter-process window communication isn't really implemented well in Wine at present.
Also I found other errors when I launch my window appication
under
wine:
err:module:import_dll No implementation for
USER32.dll.GetTitleBarInfo
imported from C:\ping\exe\ping.exe, setting to 0xdeadbeef err:module:import_dll No implementation for
USER32.dll.GetMenuBarInfo
imported from C:\ping\exe\ping.exe, setting to 0xdeadbeef
Unless the program actually uses them, this isn't a problem. If it does, the app will crash, at which point we'd need to write those functions or stub them out.
thanks -mike
Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month!
--------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month!
What you can do is rewrite only the parts that need rewriting and turn them into shared libraries. Then you can use WineLib to combine the Win32 code and the Linux code into one program.
On Thu, 2003-07-10 at 22:36, dd jj wrote:
Hello Mike,
So as my understanding, even recompile the original windows codes using WINELIB will not work, am I correct?
Since finding window info under cursor is only one of the functionality in this application, it will be a huge work to rewrite all the codes for X window. Is there any Avenue to port such a windows application to Linux? Using Visual Mainwin or Win/U is better choices? or any other comments on it?
Thanks a lot!
-Lechun
Mike Hearn mike@theoretic.com wrote: Programs run under emulation are only aware of other Wine programs. If you want to write an app like that, you'd need to rewrite it for Linux.
BTW, you might want to talk to a guy named Bill Haneman (i think that's the spelling). He does Gnome accessibility, and i think they have an app that can read info about stuff under the mouse cursor. On Thu, 2003-07-10 at 20:41, dd jj wrote: > Thank you for response. The following is my further question: > > Here is my case: > > Now I am trying to run our own developed application under wine, the > original function of this app is working as a background daemon > without GUI who is trying to figure out some window information under > the current cursor, such as the window title, class name using > GetWindowTitle, GetClassName ... WIN32 API calls. > > When I run this under WINE, it can't "see" any other Local X > application windows such as Xterm, Xclock... which don't run under > WINE. > > > I am wondering whether I can recompile the codes to generate a lcoal X > application using winelib to solve this problem, or I must write X11 > based codes? > > Thanks a lot! > > -Lechun > > Mike Hearn wrote: > > fixme:class:get_class_ptr reading from class of other > process window > > 0x2002a > > err:win:WIN_FindWndPtr window 0x2003a belongs to other > process > > Well these two are known problems. I think it's something > Alexandre will > be working on at some point, inter-process window > communication isn't > really implemented well in Wine at present. > > > Also I found other errors when I launch my window appication > under > > wine: > > > > err:module:import_dll No implementation for > USER32.dll.GetTitleBarInfo > > imported from C:\ping\exe\ping.exe, setting to 0xdeadbeef > > err:module:import_dll No implementation for > USER32.dll.GetMenuBarInfo > > imported from C:\ping\exe\ping.exe, setting to 0xdeadbeef > > > > Unless the program actually uses them, this isn't a problem. > If it does, > the app will crash, at which point we'd need to write those > functions or > stub them out. > > thanks -mike > > > ______________________________________________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month!
Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month!
Hi,
As I understand it you have a Windows app that needs to have access to some X stuff. To access that you somehow need to extend your app with some X functionality. There are several ways to do that. An easy way is to put this X functionality in a winelib dll. This dll can then be used by your app. The advantage of a winelib dll is that it can use win32 api's but also native Linux api's. The other option is to completely build your app using winelib and also add the native code. Personally I think the dll is the easiest way.
Roderick
On Thursday 10 July 2003 23:36, dd jj wrote:
Hello Mike,
So as my understanding, even recompile the original windows codes using WINELIB will not work, am I correct?
Since finding window info under cursor is only one of the functionality in this application, it will be a huge work to rewrite all the codes for X window. Is there any Avenue to port such a windows application to Linux? Using Visual Mainwin or Win/U is better choices? or any other comments on it?
Thanks a lot!
-Lechun
Mike Hearn mike@theoretic.com wrote: Programs run under emulation are only aware of other Wine programs. If you want to write an app like that, you'd need to rewrite it for Linux.
BTW, you might want to talk to a guy named Bill Haneman (i think that's the spelling). He does Gnome accessibility, and i think they have an app that can read info about stuff under the mouse cursor.
On Thu, 2003-07-10 at 20:41, dd jj wrote:
Thank you for response. The following is my further question:
Here is my case:
Now I am trying to run our own developed application under wine, the original function of this app is working as a background daemon without GUI who is trying to figure out some window information under the current cursor, such as the window title, class name using GetWindowTitle, GetClassName ... WIN32 API calls.
When I run this under WINE, it can't "see" any other Local X application windows such as Xterm, Xclock... which don't run under WINE.
I am wondering whether I can recompile the codes to generate a lcoal X application using winelib to solve this problem, or I must write X11 based codes?
Thanks a lot!
-Lechun
Mike Hearn wrote:
fixme:class:get_class_ptr reading from class of other
process window
0x2002a err:win:WIN_FindWndPtr window 0x2003a belongs to other
process
Well these two are known problems. I think it's something Alexandre will be working on at some point, inter-process window communication isn't really implemented well in Wine at present.
Also I found other errors when I launch my window appication
under
wine:
err:module:import_dll No implementation for
USER32.dll.GetTitleBarInfo
imported from C:\ping\exe\ping.exe, setting to 0xdeadbeef err:module:import_dll No implementation for
USER32.dll.GetMenuBarInfo
imported from C:\ping\exe\ping.exe, setting to 0xdeadbeef
Unless the program actually uses them, this isn't a problem. If it does, the app will crash, at which point we'd need to write those functions or stub them out.
thanks -mike
Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month!
Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month!
Hello Roderick,
Thank you for your answering. Actually, now I am trying to use WINE to port an windows application to linux. But if I use program loader provided by WINE to directly run the exe file under linux, some of the functionalities are involved with IPC between WINE and other local X processes, which is not supported by WINE.
So, I need to rewrite the local codes for them, as Mike explained before,
"What you can do is rewrite only the parts that need rewriting and turn them into shared libraries. Then you can use WineLib to combine the Win32 code and the Linux code into one program."
Here, I am glad to learn from you there seems a more easy way: (As my understanding, the other way you mentioned is the same one as Mike's)
"An easy way is to put this X functionality in a winelib dll. This dll can then be used by your app. The advantage of a winelib dll is that it can use win32 api's but also native Linux api's."
Could you please make sure whether this method can meet the need to "find any process's window info", not only "windows under WINE" ?
And could you please give some more implementation details about that?
Thanks a lot!
-Lechun
Roderick Colenbrander thunderbird2k@gmx.net wrote: Hi,
As I understand it you have a Windows app that needs to have access to some X stuff. To access that you somehow need to extend your app with some X functionality. There are several ways to do that. An easy way is to put this X functionality in a winelib dll. This dll can then be used by your app. The advantage of a winelib dll is that it can use win32 api's but also native Linux api's. The other option is to completely build your app using winelib and also add the native code. Personally I think the dll is the easiest way.
Roderick
On Thursday 10 July 2003 23:36, dd jj wrote:
Hello Mike,
So as my understanding, even recompile the original windows codes using WINELIB will not work, am I correct?
Since finding window info under cursor is only one of the functionality in this application, it will be a huge work to rewrite all the codes for X window. Is there any Avenue to port such a windows application to Linux? Using Visual Mainwin or Win/U is better choices? or any other comments on it?
Thanks a lot!
-Lechun
Mike Hearn wrote: Programs run under emulation are only aware of other Wine programs. If you want to write an app like that, you'd need to rewrite it for Linux.
BTW, you might want to talk to a guy named Bill Haneman (i think that's the spelling). He does Gnome accessibility, and i think they have an app that can read info about stuff under the mouse cursor.
On Thu, 2003-07-10 at 20:41, dd jj wrote:
Thank you for response. The following is my further question:
Here is my case:
Now I am trying to run our own developed application under wine, the original function of this app is working as a background daemon without GUI who is trying to figure out some window information under the current cursor, such as the window title, class name using GetWindowTitle, GetClassName ... WIN32 API calls.
When I run this under WINE, it can't "see" any other Local X application windows such as Xterm, Xclock... which don't run under WINE.
I am wondering whether I can recompile the codes to generate a lcoal X application using winelib to solve this problem, or I must write X11 based codes?
Thanks a lot!
-Lechun
Mike Hearn wrote:
fixme:class:get_class_ptr reading from class of other
process window
0x2002a err:win:WIN_FindWndPtr window 0x2003a belongs to other
process
Well these two are known problems. I think it's something Alexandre will be working on at some point, inter-process window communication isn't really implemented well in Wine at present.
Also I found other errors when I launch my window appication
under
wine:
err:module:import_dll No implementation for
USER32.dll.GetTitleBarInfo
imported from C:\ping\exe\ping.exe, setting to 0xdeadbeef err:module:import_dll No implementation for
USER32.dll.GetMenuBarInfo
imported from C:\ping\exe\ping.exe, setting to 0xdeadbeef
Unless the program actually uses them, this isn't a problem. If it does, the app will crash, at which point we'd need to write those functions or stub them out.
thanks -mike
Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month!
Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month!
--------------------------------- Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month!
-
BiGgUn -
dd jj -
Mike Hearn -
Roderick Colenbrander