Re: [PATCH] Implement BindIoCompletionCallback

[Robert Shearman]

Andrey Turkin wrote:
> /******************************************************************************
> -
> BindIoCompletionCallback (KERNEL32.@)
>
> */
> +extern NTSTATUS WINAPI RtlSetIoCompletionCallback(HANDLE,LPOVERLAPPED_COMPLETION_ROUTINE,ULONG);

This should go in winternl.h.
> BOOL WINAPI BindIoCompletionCallback( HANDLE FileHandle, LPOVERLAPPED_COMPLETION_ROUTINE Function, ULONG Flags)
>  {
> - FIXME("%p, %p, %d, stub!\n", FileHandle, Function, Flags);
> - SetLastError(ERROR_CALL_NOT_IMPLEMENTED);
> - NTSTATUS status;
> -
> - TRACE("(%p, %p, %d)\n", FileHandle, Function, Flags);
> -
> - status = RtlSetIoCompletionCallback( FileHandle, Function, Flags );
> - if (status == STATUS_SUCCESS) return TRUE;
> - SetLastError( RtlNtStatusToDosError(status) );
> return FALSE;
>
> }

[PATCH] Implement BindIoCompletionCallback

[Andrey Turkin]

Robert Shearman wrote:
> Andrey Turkin wrote:
> > /******************************************************************************
> > -
> >    BindIoCompletionCallback (KERNEL32.@)
> >
> > */
> > +extern NTSTATUS WINAPI
> > RtlSetIoCompletionCallback(HANDLE,LPOVERLAPPED_COMPLETION_ROUTINE,ULONG);
>
> This should go in winternl.h.

winternl.h may not depend on winbase.h for some reason, so this would
mean either changing prototype to "(HANDLE,LPVOID,ULONG)", which seems
wrong, or redefining LPOVERLAPPED_COMPLETION_ROUTINE and
OVERLAPPED/LPOVERLAPPED, which seems to be too much duplication.
> > BOOL WINAPI BindIoCompletionCallback( HANDLE FileHandle,
> > LPOVERLAPPED_COMPLETION_ROUTINE Function, ULONG Flags)
> >  {
> > - FIXME("%p, %p, %d, stub!\n", FileHandle, Function, Flags);
> > - SetLastError(ERROR_CALL_NOT_IMPLEMENTED);
> > - NTSTATUS status;
> > -
> > - TRACE("(%p, %p, %d)\n", FileHandle, Function, Flags);
> > -
> > - status = RtlSetIoCompletionCallback( FileHandle, Function, Flags );
> > - if (status == STATUS_SUCCESS) return TRUE;
> > - SetLastError( RtlNtStatusToDosError(status) );
> > return FALSE;
> >
> > }

[PATCH] Implement BindIoCompletionCallback

[Steven Edwards]

On Dec 18, 2007 3:49 PM, Andrey Turkin  wrote:
> winternl.h may not depend on winbase.h for some reason, so this would
> mean either changing prototype to "(HANDLE,LPVOID,ULONG)", which seems
> wrong, or redefining LPOVERLAPPED_COMPLETION_ROUTINE and
> OVERLAPPED/LPOVERLAPPED, which seems to be too much duplication.

Has anyone looked at the latest WDK to see where this goes? Is it
really winternl.h? That header seems to be a bit of a bastard hack
Microsoft threw together to shut-up the anti-trust case. These
functions and others we have had to add to winternl.h have got to be
documented in some other DDK header which we can implement.

Thanks

[PATCH] Implement BindIoCompletionCallback

[Robert Shearman]

Andrey Turkin wrote:
> Robert Shearman wrote:
> > Andrey Turkin wrote:
> > > /******************************************************************************
> > > -
> > >    BindIoCompletionCallback (KERNEL32.@)
> > >
> > > */
> > > +extern NTSTATUS WINAPI
> > > RtlSetIoCompletionCallback(HANDLE,LPOVERLAPPED_COMPLETION_ROUTINE,ULONG);
> >
> > This should go in winternl.h.
>
> winternl.h may not depend on winbase.h for some reason, so this would
> mean either changing prototype to "(HANDLE,LPVOID,ULONG)", which seems
> wrong, or redefining LPOVERLAPPED_COMPLETION_ROUTINE and
> OVERLAPPED/LPOVERLAPPED, which seems to be too much duplication.

I think you should guard the function with an #ifdef __WINE_WINBASE_H 
statement, but I would wait for some other developers to chime in to get 
a consensus before accepting this though.

[PATCH] Implement BindIoCompletionCallback

[Alexandre Julliard]

Robert Shearman  writes:
> Andrey Turkin wrote:
> > Robert Shearman wrote:
> > > Andrey Turkin wrote:
> > > > /******************************************************************************
> > > > -
> > > >    BindIoCompletionCallback (KERNEL32.@)
> > > >
> > > > */
> > > > +extern NTSTATUS WINAPI
> > > > RtlSetIoCompletionCallback(HANDLE,LPOVERLAPPED_COMPLETION_ROUTINE,ULONG);
> > >
> > > This should go in winternl.h.
> >
> > winternl.h may not depend on winbase.h for some reason, so this would
> > mean either changing prototype to "(HANDLE,LPVOID,ULONG)", which seems
> > wrong, or redefining LPOVERLAPPED_COMPLETION_ROUTINE and
> > OVERLAPPED/LPOVERLAPPED, which seems to be too much duplication.
>
> I think you should guard the function with an #ifdef __WINE_WINBASE_H 
> statement, but I would wait for some other developers to chime in to get 
> a consensus before accepting this though.

It doesn't seem right for an ntdll function to use an OVERLAPPED
pointer. Shouldn't it take an IO_STATUS_BLOCK instead?

[PATCH] Implement BindIoCompletionCallback

[Andrey Turkin]

Alexandre Julliard wrote:
> Robert Shearman  writes:
> > Andrey Turkin wrote:
> > > Robert Shearman wrote:
> > > > Andrey Turkin wrote:
> > > > > /******************************************************************************
> > > > > -
> > > > >    BindIoCompletionCallback (KERNEL32.@)
> > > > >
> > > > > */
> > > > > +extern NTSTATUS WINAPI
> > > > > RtlSetIoCompletionCallback(HANDLE,LPOVERLAPPED_COMPLETION_ROUTINE,ULONG);
> > > >
> > > > This should go in winternl.h.
> > >
> > > winternl.h may not depend on winbase.h for some reason, so this would
> > > mean either changing prototype to "(HANDLE,LPVOID,ULONG)", which seems
> > > wrong, or redefining LPOVERLAPPED_COMPLETION_ROUTINE and
> > > OVERLAPPED/LPOVERLAPPED, which seems to be too much duplication.
> >
> > I think you should guard the function with an #ifdef __WINE_WINBASE_H 
> > statement, but I would wait for some other developers to chime in to get 
> > a consensus before accepting this though.
>
> It doesn't seem right for an ntdll function to use an OVERLAPPED
> pointer. Shouldn't it take an IO_STATUS_BLOCK instead?

It is not used in the function itself, it is only passed to
user-provided callback. So, I see several possibilities:
1) change RtlSetIoCompletionCallback to use another callback prototype,
with LPVOID or ULONG_PTR or something instead of LPOVERLAPPED
2) leave callback prototype as in BindIoCompletionCallback, and protect
RtlSetIoCompletionCallback with #ifdefs as Robert suggested
3) do not implement RtlSetIoCompletionCallback at all and move all code
in kernel32

[PATCH] Implement BindIoCompletionCallback

[Alexandre Julliard]

Andrey Turkin  writes:
> It is not used in the function itself, it is only passed to
> user-provided callback. So, I see several possibilities:

I know it's in the callback, what I meant is that the ntdll function
should not be taking a LPOVERLAPPED_COMPLETION_ROUTINE, which is a
kernel32 thing, it should be taking some sort of IO_COMPLETION_CALLBACK
routine, that uses an IO_STATUS_BLOCK (or probably better a void*, since
it's opaque) instead of an OVERLAPPED pointer.

dll to .so wrapper

[bridd]

Hi there,

I've got a bit of a specific task, that I don't know if it's achievable
via wine in some way or not.  I'd like to make a windows dll available
to linux programs as a .so file.

The dll itself is a video plugin (freeframe.sourceforge.net).  These are
available commercially to buy, and I'd like to be able to use them in a
linux application that supports the plugin format for native linux
compiled plugins, without having to request linux native versions from
the commercial developers.

I've been doing some searching, and have found a few mails on this list
about this sort of thing in the past, but haven't been able to find a
conclusive method.

I guess that this might be possible via some sort of wrapper that maps
the inputs/outputs to the dll .  Does anyone know if there is anything
that runs like this already out there that I could take a look at as an
example piece of code to hack about with?

Cheers

Dave

dll to .so wrapper

[Maarten Lankhorst]

Hi bridd,

bridd schreef:
> Hi there,
>
> I've got a bit of a specific task, that I don't know if it's achievable
> via wine in some way or not.  I'd like to make a windows dll available
> to linux programs as a .so file.
>
> The dll itself is a video plugin (freeframe.sourceforge.net).  These are
> available commercially to buy, and I'd like to be able to use them in a
> linux application that supports the plugin format for native linux
> compiled plugins, without having to request linux native versions from
> the commercial developers.
>
> I've been doing some searching, and have found a few mails on this list
> about this sort of thing in the past, but haven't been able to find a
> conclusive method.
>
> I guess that this might be possible via some sort of wrapper that maps
> the inputs/outputs to the dll .  Does anyone know if there is anything
> that runs like this already out there that I could take a look at as an
> example piece of code to hack about with?

This topic comes up from time to time, usually with mild variations. The
problem is that wine sets up its own environment and memory layout. In
the end you will need a .exe (or winelib binary) that uses wine, and a
socket/pipe/shm function to communicate with the .so, there is no easy
way to just  dynamically load a dll in an existing program.

Cheers,
Maarten.

dll to .so wrapper

[Marcus Meissner]

On Wed, Dec 19, 2007 at 10:26:38PM +0100, Maarten Lankhorst wrote:
> Hi bridd,
>
> bridd schreef:
> > Hi there,
> >
> > I've got a bit of a specific task, that I don't know if it's achievable
> > via wine in some way or not.  I'd like to make a windows dll available
> > to linux programs as a .so file.
> >
> > The dll itself is a video plugin (freeframe.sourceforge.net).  These are
> > available commercially to buy, and I'd like to be able to use them in a
> > linux application that supports the plugin format for native linux
> > compiled plugins, without having to request linux native versions from
> > the commercial developers.
> >
> > I've been doing some searching, and have found a few mails on this list
> > about this sort of thing in the past, but haven't been able to find a
> > conclusive method.

Yes, it is called "MPlayer", which has a rudimentary WIne derived
Codec loading and executing framework.

You are perhaps easier off using it ;)

Ciao, Marcus

dll to .so wrapper

[bridd]

On Wed, 2007-12-19 at 23:06 +0100, Marcus Meissner wrote:
> > > The dll itself is a video plugin (freeframe.sourceforge.net).  These are
> > > available commercially to buy, and I'd like to be able to use them in a
> > > linux application that supports the plugin format for native linux
> > > compiled plugins, without having to request linux native versions from
> > > the commercial developers.
> > >
> > > I've been doing some searching, and have found a few mails on this list
> > > about this sort of thing in the past, but haven't been able to find a
> > > conclusive method.
>
> Yes, it is called "MPlayer", which has a rudimentary WIne derived
> Codec loading and executing framework.
>
> You are perhaps easier off using it ;)

That kind-of misses my point though; freeframe is a plug-in format for
adding effects to a video input (usually used in live VJ applications).
As far as I know, MPlayer doesn't support it, nor would that enable
support in any linux VJ'ing software! :)

I was simply looking at the possibility of running freeframe plugins
compiled under windows, in linux using wine as the middle-layer.

Cheers

Dave

dll to .so wrapper

[bridd]

On Wed, 2007-12-19 at 22:26 +0100, Maarten Lankhorst wrote:
> This topic comes up from time to time, usually with mild variations. The
> problem is that wine sets up its own environment and memory layout. In
> the end you will need a .exe (or winelib binary) that uses wine, and a
> socket/pipe/shm function to communicate with the .so, there is no easy
> way to just  dynamically load a dll in an existing program.

I see, so it's sounding like to do this I'd need to have something more
akin to a VST host, that acts as an intermediatory and pumps the video
data from the linux application via a native plugin (.so), into a
winelib compiled program that executes the windows compiled plugin
(.dll) and the sends it back out again.

Probably beyond my skills right now, but thought it was worth seeing if
anyone had trodden a similar route already!

Thanks,

Dave

dll to .so wrapper

[Kuba Ober]

On Wednesday 19 December 2007, bridd wrote:
> On Wed, 2007-12-19 at 22:26 +0100, Maarten Lankhorst wrote:
> > This topic comes up from time to time, usually with mild variations. The
> > problem is that wine sets up its own environment and memory layout. In
> > the end you will need a .exe (or winelib binary) that uses wine, and a
> > socket/pipe/shm function to communicate with the .so, there is no easy
> > way to just  dynamically load a dll in an existing program.
>
> I see, so it's sounding like to do this I'd need to have something more
> akin to a VST host, that acts as an intermediatory and pumps the video
> data from the linux application via a native plugin (.so), into a
> winelib compiled program that executes the windows compiled plugin
> (.dll) and the sends it back out again.
>
> Probably beyond my skills right now, but thought it was worth seeing if
> anyone had trodden a similar route already!

Should be doable via shm, i.e. without overhead - you can share your 
framebuffer (or a few) between applications that way. Remember that you can 
do linux syscalls from a PE (windows) executable that runs under Wine.

Cheers, Kuba