Unsupported API Call Implemtation Question

[Roger]

> Roger wrote:
> > Hi All,
> >
> > I would have asked this question on the wine-devel list but winehq made
> > it quite clear that list was not for user questions but for developer
> > use only so I ask it here.
>
> Hmm..., normally I do the list moderation, and I cannot imagine that I
> would have rejected this.


Sorry, I did not mean to imply that wine-devel folks were hard nose.  It
just seemed from the subscribe description that the list was more for
developer to developer talk and user inquiries might not be appropriate -- 
just trying to oberverve protocol,  my misunderstanding.


> > I am attempting to run a native windows VB6 app (United Devices) in
> > wine, fake windows, and continue to encounter an unimplemented
> > API "CreateRemoteThread" call to kernel32 error using any and all RH
> > distro kernels using any wine version.  I was simply wondering as to
> > when that API call might be implemented.  I am in the process of filing
> > a bug report to winehq in the hopes an engineer will be motivated to
> > take it on so here is what my investigation has shown to date.
> >
> > The function appears to be properly declared in winbase.h (wine of
> > course) as is the already implemented function 'CreateThread' along with
> > the structure type SECURITY_ATTRIBUTES common to both calls.  The
> > kernel32.spec file shows 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 as I 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 provide the exe and source to winehq.
>
> The patch submission is easy. But looking at the function description,
> it would appear to require some detailed knowledge of the way things
> work, rather than just a knowledge of C.
>
> Just my personal view here... There is generally no "schedule" for
> implementing functions. For something like this, it generally means that
> someone who actually wants to use the application, and with the detailed
> knowledge required to fix it, be motivated to take it on. Unfortunately,
> I suspect few have the needed skill set (certainly it is way beyond my
> weak understanding of how things work). If you are just an individual,
> that kind of means you are stuck. For a company, there is of course
> always the option to pay someone to fix it.
>
>

Thanks for the above info as it gives me a better perspective as how things
work priority wise.  Would it be worthwhile to post to devel just in case
someone was thinking about working on this soon?  I do think sooner or later
this call must be implemented for ultimate full wine functionality with win
apps and also believe it will make many more apps functional soon under wine
once implemented.  I do have a lot more info which I was planning to use for
a bug report.

Thanks, Roger
 _______________________________________________
> wine-users mailing list
> wine-users at winehq.org
> http://www.winehq.org/mailman/listinfo/wine-users