Unhandled API Call to Kernel32 Question
Hi All, I am attempting to run a native windows VB6 app (United Devices) in wine, fake windows, but I continue to encounter an unimplemented/unhandled API call "CreateRemoteThread" to kernel32 error with any and all RH distro kernels using any wine version. I was simply wondering if any engineer might be considering working on implementing this call anytime soon. I am in the process of filling a bug report in the hopes an engineer might be motivated to take it on. Here is what my investigation has shown to date regarding this function. The function appears to be properly declared in winbase.h (wine version) as is the already implemented function 'CreateThread' along with the structure type SECURITY_ATTRIBUTES common to both calls. The kernel32.spec file exports show CreateRemoteThread apparently stubbed "@ stub CreateRemoteThread" but the implemented CreateThread shows "@ stdcall CreateThread (ptr long ptr long long ptr)". I wish I knew C and patch submission procedure and would gladly volunteer to work on this one but I only know some VB and am attempting to code this call in a simple VB6 procedure to replicate the error and, if sucessful, will be happy to provide the exe and source to winehq if desired. Any advice where I go from here as I want to dump win, get more hd space but I need this app? Thanks, Roger
On Sun, 09 May 2004 17:23:18 -0700, Roger wrote:
I am attempting to run a native windows VB6 app (United Devices) in wine, fake windows, but I continue to encounter an unimplemented/unhandled API call "CreateRemoteThread" to kernel32 error with any and all RH distro kernels using any wine version.
Implementing this API would be extremely difficult. I'm not sure if there is even any equivalent in the POSIX APIs. If not then I don't know what we'd have to do - maybe bring back the service thread to respond to wineserver requests to create remote threads. What sort of program is this? The only use of CreateRemoteThread that I'm aware of is for bots like Kore which inject themselves into games to perform remote control. thanks -mike
On Mon, 10 May 2004 10:29:34 +0100, Mike Hearn wrote:
Implementing this API would be extremely difficult.
Me, Mike and Dmitry discussed this on IRC and came up with the following two approaches to implementing it. The first, which is probably the simplest, is just to send a signal to the program which then gets the pending thread creation info from the wineserver and sets up the thread. The second is to have some code at a magic location in memory placed there by Wine beforehand. The caller of CreateRemoteThread then uses ptrace to attach to the remote process and jump the main thread to that code. In other words you literally take control of a pre-existing thread and make it to your bidding. The signal approach is probably easiest. I originally thought signal stacks were too small to do anything like wineserver RPCs on but Mike says that isn't the case anymore, so it's probably the nicest way to implement. In theory it shouldn't even be too hard. A nice project for somebody interested in the lower levels :) thanks -mike
Mon, 10 May 2004 11:06:56 +0100 Mike Hearn wrote:
In theory it shouldn't even be too hard. A nice project for somebody interested in the lower levels :)
It would be great if someone were willing to take this on :-D. I would be more than happy to volunteer for leg work, investigations, testing, timely result feedback, etc. Although I am not a program engineer, I am a fair troubleshooter with enough knowledge to help somewhere. There are a lot of Linux folks that express themselves on the UD forums that would have very happy faces if this app could work under wine. This thread for starters: http://forum.grid.org/phpBB/viewforum.php?f=5&sid=c887122b234167fa1514f6c2d6... Thanks, Roger
On Mon, 10 May 2004 19:23:40 -0700, Roger Olson wrote:
It would be great if someone were willing to take this on :-D. I would be more than happy to volunteer for leg work, investigations, testing, timely result feedback, etc.
I am willing to teach somebody who shows an interest (and is competent) what they need to know but I don't have the time to do this myself.
Tue, 11 May 2004 10:35:08 +0100 Mike Hearn Wrote:
I am willing to teach somebody who shows an interest (and is competent) what they need to know but I don't have the time to do this myself.
That is really a generous offer and greatly appreciated. I am both interested and motived, believe that I am competent, dedicated and a fairly good troubleshooter, a good self studier but only have some VB experience. If this provides enough of a basis for me to become helpful, count me in and point me where to start reading. If things are 'over my head' I'll let you know as I know you are busy, I see your name in the wine weekly newsletter a lot :-) Thanks, Roger
On Tue, 11 May 2004 13:48:38 -0700, Roger Olson wrote:
That is really a generous offer and greatly appreciated. I am both interested and motived, believe that I am competent, dedicated and a fairly good troubleshooter, a good self studier but only have some VB experience. If this provides enough of a basis for me to become helpful, count me in and point me where to start reading.
Sure. Be warned : this would be a major project for you. There is a huge world of difference between writing VB apps and writing a Windows emulator. First thing you need to do is learn C. Unfortunately VB doesn't cut it at this sort of level, C and possibly assembly is what you need, don't worry about asm for now. Once you've got a handle on C (don't worry if you find it hard at first, when I started on Wine I didn't really know C that well either), look at the POSIX signal APIs. Play about with test apps sending signals between them. When you feel comfortable with C and signals, you need to propose a design for the CreateRemoteThread implementation. I can suggest one if you get stuck. If people seem to think it's OK, you need to go ahead and write a patch and submit it. Good luck! thanks -mike
Tue, 11 May 2004 23:22:27 +0100 Mike Hearn Wrote:
Sure. Be warned : this would be a major project for you. There is a huge world of difference between writing VB apps and writing a Windows emulator.
First thing you need to do is learn C. Unfortunately VB doesn't cut it at this sort of level, C and possibly assembly is what you need, don't worry about asm for now.
Once you've got a handle on C (don't worry if you find it hard at first, when I started on Wine I didn't really know C that well either), look at the POSIX signal APIs. Play about with test apps sending signals between them.
When you feel comfortable with C and signals, you need to propose a design for the CreateRemoteThread implementation. I can suggest one if you get stuck. If people seem to think it's OK, you need to go ahead and write a patch and submit it. Good luck!
Just a quick update. That's a challenging list of things to do so it will probably be a bit of time before I get back with more intelligent questions. I have been reading all the wine 'readme' files in an attempt to put things into perspective and started to study C using what reference materials I have at my disposal (MS Win32 SDK). I learned how to print "Hello World" on the screen using C and seriously, that is more than I knew yesterday. When I get up to speed, will contact with further questions. Thanks Again, Roger
Mon, 10 May 2004 10:29:34 +0100 Mike Hearn Wrote:
What sort of program is this? The only use of CreateRemoteThread that I'm aware of is for bots like Kore which inject themselves into games to perform remote control.
United Devices Agent is a distributed computing application like setiathome but used for cancer/smallpox research in an attempt to find cures. It is listed as app 874 in the winedb. When the agent is reopened to continue processing a saved in-progress work unit, it opens a child app (eg: ud_1396140.exe containing an xml file and ud_ligfit_Release.exe). The later file actually preforms the number processing and is a grandchild proess of the agent. Otherwise, it phones home to get a new work unit and proceeds as above. Early after "wine ud.exe" these errors come up, apparently when one or both process children open: <snip> fixme:seh:EXC_RtlRaiseException call to unimplemented function kernel32.dll.CreateRemoteThread fixme:msvcrt:_XcptFilter (-2147483392,0x4074da7c)semi-stub wine: Unhandled exception (thread 000c), starting debugger... fixme:powermgnt:GetSystemPowerStatus (): stub, harmless. WineDbg starting on pid b <snip> I have the full wine and the "ps -Afm" results saved. Thanks Roger
participants (4)
-
Mike Hearn -
Mike Hearn -
Roger -
Roger Olson