wine users - Feb 2008 - Windows Kernel & Executive implementation

Hello everyone, my name is Volodymyr, I am driver developer mostly doing
stuff for Windows.

I discovered that WineHQ project does not have support for drivers (am I
wrong?). In other words, quite a big amount of applications will fail to
function properly, because many of them are using helper device drivers to
get some extended functionality. I can just mention RegMon, FileMon, TDIMom,
and others.

Theoretically, this task is possible to be implemented, but it requires
quite a lot amount of work, of course. Is there any movements to overcome
this limitation? Have you ever considered to achieve compatibility at this
level?

Basically, I am talking about implementation of analogs of Windows Kernel
and Executive subsystems. On top of them, there might be implemented such
popular subsystems as:

- TDI subsystem (up to Vista)
- WFP (starting from Vista)
- Support for FS filters
- and the rest

Any comments are highly appreciated,

-- 
with best regards,
Volodymyr
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.winehq.org/pipermail/wine-users/attachments/20080222/f9269789/attachment.htm

Probably the most common response you will get is, there are often freely
available tools that can already do this in Linux.

I'm interested to see more responses.

-Tres


On Fri, Feb 22, 2008 at 6:02 AM, Volodymyr Shcherbyna <v_scherbina at
mvps.org>
wrote:
> Hello everyone, my name is Volodymyr, I am driver developer mostly doing
> stuff for Windows.
>
> I discovered that WineHQ project does not have support for drivers (am I
> wrong?). In other words, quite a big amount of applications will fail to
> function properly, because many of them are using helper device drivers to
> get some extended functionality. I can just mention RegMon, FileMon,
> TDIMom,
> and others.
>
> Theoretically, this task is possible to be implemented, but it requires
> quite a lot amount of work, of course. Is there any movements to overcome
> this limitation? Have you ever considered to achieve compatibility at this
> level?
>
> Basically, I am talking about implementation of analogs of Windows Kernel
> and Executive subsystems. On top of them, there might be implemented such
> popular subsystems as:
>
> - TDI subsystem (up to Vista)
> - WFP (starting from Vista)
> - Support for FS filters
> - and the rest
>
> Any comments are highly appreciated,
>
> --
> with best regards,
> Volodymyr
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
>
http://www.winehq.org/pipermail/wine-users/attachments/20080222/f9269789/attachment.htm
>


-- 
- Tres.Finocchiaro at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.winehq.org/pipermail/wine-users/attachments/20080222/1d6fd370/attachment.htm

On Fri, Feb 22, 2008 at 3:02 AM, Volodymyr Shcherbyna
<v_scherbina at mvps.org> wrote:
>  I discovered that WineHQ project does not have support for drivers (am I
>  wrong?). In other words, quite a big amount of applications will fail to
>  function properly, because many of them are using helper device drivers to
>  get some extended functionality. I can just mention RegMon, FileMon,
TDIMom,
>  and others.
I know very little about this, but my impression is that
Wine supports a limited set of NT os kernel APIs already.
The initial support was added by this patch:
http://www.winehq.org/pipermail/wine-cvs/2007-May/032546.html
The current set of supported calls can be seen here:
http://source.winehq.org/source/dlls/ntoskrnl.exe/ntoskrnl.c

Feel free to implement more, or file enhancement requests
describing what nt os apis a popular app needs.
- Dan

Thank you,

I missed that code. Okay, I will take a more detailed look.

2008/2/22, Dan Kegel <dank at kegel.com>:
>
> On Fri, Feb 22, 2008 at 3:02 AM, Volodymyr Shcherbyna
> <v_scherbina at mvps.org> wrote:
>
> >  I discovered that WineHQ project does not have support for drivers
(am
> I
> >  wrong?). In other words, quite a big amount of applications will fail
> to
> >  function properly, because many of them are using helper device
drivers
> to
> >  get some extended functionality. I can just mention RegMon, FileMon,
> TDIMom,
> >  and others.
>
>
> I know very little about this, but my impression is that
> Wine supports a limited set of NT os kernel APIs already.
> The initial support was added by this patch:
> http://www.winehq.org/pipermail/wine-cvs/2007-May/032546.html
> The current set of supported calls can be seen here:
> http://source.winehq.org/source/dlls/ntoskrnl.exe/ntoskrnl.c
>
> Feel free to implement more, or file enhancement requests
> describing what nt os apis a popular app needs.
>
> - Dan
>


-- 
with best regards,
Volodymyr
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.winehq.org/pipermail/wine-users/attachments/20080222/cf9fce7d/attachment.htm

Unfortunately, that code just do stubs, and it is not actually executed in
kernel mode.

-- 
with best regards,
Volodymyr

2008/2/22, Dan Kegel <dank at kegel.com>:
>
> On Fri, Feb 22, 2008 at 3:02 AM, Volodymyr Shcherbyna
> <v_scherbina at mvps.org> wrote:
>
> >  I discovered that WineHQ project does not have support for drivers
(am
> I
> >  wrong?). In other words, quite a big amount of applications will fail
> to
> >  function properly, because many of them are using helper device
drivers
> to
> >  get some extended functionality. I can just mention RegMon, FileMon,
> TDIMom,
> >  and others.
>
>
> I know very little about this, but my impression is that
> Wine supports a limited set of NT os kernel APIs already.
> The initial support was added by this patch:
> http://www.winehq.org/pipermail/wine-cvs/2007-May/032546.html
> The current set of supported calls can be seen here:
> http://source.winehq.org/source/dlls/ntoskrnl.exe/ntoskrnl.c
>
> Feel free to implement more, or file enhancement requests
> describing what nt os apis a popular app needs.
>
> - Dan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.winehq.org/pipermail/wine-users/attachments/20080222/9fdca897/attachment.htm

You could have a look at ReactOS about this (www.reactos.org). But anyway,
Wine's way of supporting this will [most probably] be different from
reactos' way.

Alan McKinnon wrote:
> 
> But prior access to competing, proprietary closed-source code puts FLOSS 
> projects at increased legal risk, especially when the closed-source 
> company is making serious public statements about starting law suits 
> over patents. Double especially when that company is Microsoft.
> 
> -- 
> Alan McKinnon
> alan dot mckinnon at gmail dot com

As for ReactOS, this automatically means person's inability to submit code
to the main tree, like it happened to a few our developers who got a job at
Microsoft now.

I didn't really want to touch this flammable topic about ReactOS, and was
just suggesting the *right* direction for exactly drivers development (like
CaptiveNTFS for filesystems drivers, etc). But since
1) Volodymyr has access to proprietary Windows source code and
2) Volodymyr thinks, that even having the same #define names and values from
public DDK in ReactOS DDK is a violation of Microsoft's copyright
I think it would be hard to work out anything useful from this.

Thanks anyway.

On Friday 22 February 2008 17:12:41 wine-users-request at winehq.org
wrote:
> Hello everyone, my name is Volodymyr, I am driver developer mostly doing
> stuff for Windows.
>
> I discovered that WineHQ project does not have support for drivers (am I
> wrong?). In other words, quite a big amount of applications will fail to
> function properly, because many of them are using helper device drivers to
> get some extended functionality. I can just mention RegMon, FileMon,
> TDIMom, and others.
>
> Theoretically, this task is possible to be implemented, but it requires
> quite a lot amount of work, of course. Is there any movements to overcome
> this limitation? Have you ever considered to achieve compatibility at this
> level?
>
> Basically, I am talking about implementation of analogs of Windows Kernel
> and Executive subsystems. On top of them, there might be implemented such
> popular subsystems as:
>
> - TDI subsystem (up to Vista)
> - WFP (starting from Vista)
> - Support for FS filters
> - and the rest
>
> Any comments are highly appreciated,
http://www.kde-apps.org/content/show.php/Linux+Unified+Kernel+?content=75484

This is there but has nothing to do with kde. Unfortunately, this is the only 
information you will be able to read as the company's site is in Chinese!

You need to patch wine, make a custom patched kernel to check this out.