WineHQ
Wine Forums

Board index » WineHQ » Wine Help




 Page 1 of 1 [ 21 posts ] 



 
Author Message
 Post Posted: Fri Feb 22, 2008 6:03 am 
 
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-us ... chment.htm


Top 
 Post Posted: Fri Feb 22, 2008 10:13 am 
 
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@mvps.org>
wrote:

Quote:
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-us ... chment.htm




--
- Tres.Finocchiaro@gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-us ... chment.htm


Top 
 Post Posted: Fri Feb 22, 2008 10:41 am 
 
Hello Tres,

Yes, agree, there might be Linux equivalents to accomplish the same tasks.
But let me pickup the description of winehq from official web-site : "[...]
a compatibility layer for running Windows programs [...]". Doesn't that
mean, that *all* software should work?

--
with best regards,
Volodymyr

2008/2/22, A. Tres Finocchiaro <tres.finocchiaro@gmail.com>:
Quote:
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@mvps.org> wrote:

Quote:
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-us ... chment.htm




--
- Tres.Finocchiaro@gmail.com




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


Top 
 Post Posted: Fri Feb 22, 2008 11:19 am 
 
In theory, you are completely correct.

Truth is, some of the low level hardware programming requires special
windows drivers. Wine tries to simulate those drivers with native Linux
calls.

Since the request is so closely based to the APIs associated with the
application, you might get a greater stir from the programmers, as the
user's group focuses more on what does, and doesn't work, to support the
wine users in their struggles.

-Tres

On Fri, Feb 22, 2008 at 10:41 AM, Volodymyr Shcherbyna <v_scherbina@mvps.org>
wrote:

Quote:
Hello Tres,

Yes, agree, there might be Linux equivalents to accomplish the same tasks.
But let me pickup the description of winehq from official web-site :
"[...]
a compatibility layer for running Windows programs [...]". Doesn't that
mean, that *all* software should work?

--
with best regards,
Volodymyr

2008/2/22, A. Tres Finocchiaro <tres.finocchiaro@gmail.com>:
Quote:
Probably the most common response you will get is, there are often
freely
Quote:
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@mvps.org> wrote:

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

I discovered that WineHQ project does not have support for drivers (am
I
Quote:
Quote:
wrong?). In other words, quite a big amount of applications will fail
to
Quote:
Quote:
function properly, because many of them are using helper device
drivers
Quote:
Quote:
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
Quote:
Quote:
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
Quote:




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




--
- Tres.Finocchiaro@gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-us ... chment.htm


Top 
 Post Posted: Fri Feb 22, 2008 11:44 am 
 
On Fri, Feb 22, 2008 at 3:02 AM, Volodymyr Shcherbyna
<v_scherbina@mvps.org> wrote:
Quote:
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-cv ... 32546.html
The current set of supported calls can be seen here:
http://source.winehq.org/source/dlls/nt ... ntoskrnl.c

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


Top 
 Post Posted: Fri Feb 22, 2008 2:31 pm 
 
Thank you,

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

2008/2/22, Dan Kegel <dank@kegel.com>:
Quote:
On Fri, Feb 22, 2008 at 3:02 AM, Volodymyr Shcherbyna
<v_scherbina@mvps.org> wrote:

Quote:
I discovered that WineHQ project does not have support for drivers (am
I
Quote:
wrong?). In other words, quite a big amount of applications will fail
to
Quote:
function properly, because many of them are using helper device drivers
to
Quote:
get some extended functionality. I can just mention RegMon, FileMon,
TDIMom,
Quote:
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-cv ... 32546.html
The current set of supported calls can be seen here:
http://source.winehq.org/source/dlls/nt ... 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-us ... chment.htm


Top 
 Post Posted: Fri Feb 22, 2008 2:50 pm 
 
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@kegel.com>:
Quote:
On Fri, Feb 22, 2008 at 3:02 AM, Volodymyr Shcherbyna
<v_scherbina@mvps.org> wrote:

Quote:
I discovered that WineHQ project does not have support for drivers (am
I
Quote:
wrong?). In other words, quite a big amount of applications will fail
to
Quote:
function properly, because many of them are using helper device drivers
to
Quote:
get some extended functionality. I can just mention RegMon, FileMon,
TDIMom,
Quote:
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-cv ... 32546.html
The current set of supported calls can be seen here:
http://source.winehq.org/source/dlls/nt ... 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-us ... chment.htm


Top 
 Post subject:
 Post Posted: Fri Feb 22, 2008 6:32 pm 
Offline
Newbie
Newbie

Joined: Fri Feb 22, 2008 3:37 pm
Posts: 2
Location: Moscow, Russia
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.


Top 
 Post Posted: Fri Feb 22, 2008 7:00 pm 
 
Volodymyr Shcherbyna <v_scherbina@mvps.org> wrote:
Quote:
Quote:
Quote:
[many apps use helper device drivers, e.g. RegMon, FileMon, TDIMom]
http://source.winehq.org/source/dlls/ntoskrnl.exe/ntoskrnl.c
Unfortunately, that code just do stubs, and it is not actually executed in
kernel mode.

The current ntoskrnl.c is enough to run a few apps.
It's not intended to run arbitrary NT drivers.

Now, RegMon uses a VxD, and I don't think we're ever planning on
really supporting those. Wine does ship with nine 'fake' VxD's;
these were added because they were needed by popular apps.
So if you have a particular VxD that's important enough,
we can reimplement it as part of Wine.

I just noticed Microsoft's UMDF (User Mode Driver Framework).
I bet we could support UMDF drivers pretty well if we wanted to.
Have you ever played with that?
- Dan


Top 
 Post Posted: Fri Feb 22, 2008 7:00 pm 
 
I am not sure that ReacOS is a good example. Quite a big amount of code in ReactOS contains leaked code of Windows (from Windows 2k). Recently I did a research, since I have access to Windows code(code premium subscription), I am able to compare things.

2008/2/23, Fireball <wineforum-user@winehq.org (wineforum-user@winehq.org)>:
Quote:
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.








--
with best regards,
Volodymyr


Top 
 Post Posted: Fri Feb 22, 2008 7:12 pm 
 
On Friday 22 February 2008, Volodymyr Shcherbyna wrote:
Quote:
Hello Tres,

Yes, agree, there might be Linux equivalents to accomplish the same
tasks. But let me pickup the description of winehq from official
web-site : "[...] a compatibility layer for running Windows programs
[...]". Doesn't that mean, that *all* software should work?

NO.

It means that applications that users can reasonably expect to run
should be able to run. Note that it is applications that Wine targets.

For example, there is no sane reason in the world that VC++ should
always work under Wine, considering the deep knowledge of Windows that
is built into VC++. If you are developing a Windows app, then you
should compile it on ... Windows. And Wine runs atop a *nix system, so
it has no need to implement any NTFS-specific code as it does not need
to use NTFS as a storage layer. Should you need to manipulate NTFS for
some reason, we have ntfs-ng for that job.

There has to be a point where Wine stops and the correct answer to
anything more is "You should use Windows for that". I believe that line
lies just beyond user-space apps.

--
Alan McKinnon
alan dot mckinnon at gmail dot com


Top 
 Post Posted: Fri Feb 22, 2008 7:18 pm 
 
On Fri, Feb 22, 2008 at 4:09 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
Quote:
For example, there is no sane reason in the world that VC++ should
always work under Wine, considering the deep knowledge of Windows that
is built into VC++.

I don't think that's a good example. While I agree that
Wine is not designed to run ALL windows software
(it'll never run arbitrary VxD's, for instance), it can and
will run Visual C++. Visual C++ 6 works quite well modulo
one bug in ole32, and Visual C++ Toolkit 2003 installs and
runs pretty well module two bugs keeping .net 1.1 from installing.
Visual C++ 6 and 2003 will eventually work well enough to make
Windows developers comfortable. And valgrind will support windows
apps well enough that Windows developers might... actually...
prefer... to develop their Windows apps on Linux sometimes.
- Dan


Top 
 Post Posted: Fri Feb 22, 2008 7:25 pm 
 
RegMon was just one of the examples. But basically, RegMon uses vxd driver
for Windows 9x. For XP it uses NT driver which hooks SDT. On Server 2003 it
uses legacy registry notification API.

UMDF support started from XP. It does not cover 2k. Also, UMDF is just a
part of WDF. However, I think it will be good to implement basic things,
like NT drivers support.

2008/2/23, Dan Kegel <dank06@kegel.com>:
Quote:
Volodymyr Shcherbyna <v_scherbina@mvps.org> wrote:

Quote:
Quote:
Quote:
[many apps use helper device drivers, e.g. RegMon, FileMon, TDIMom]

Quote:
Quote:
http://source.winehq.org/source/dlls/ntoskrnl.exe/ntoskrnl.c

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


The current ntoskrnl.c is enough to run a few apps.
It's not intended to run arbitrary NT drivers.

Now, RegMon uses a VxD, and I don't think we're ever planning on
really supporting those. Wine does ship with nine 'fake' VxD's;
these were added because they were needed by popular apps.
So if you have a particular VxD that's important enough,
we can reimplement it as part of Wine.

I just noticed Microsoft's UMDF (User Mode Driver Framework).
I bet we could support UMDF drivers pretty well if we wanted to.
Have you ever played with that?

- Dan




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


Top 
 Post Posted: Fri Feb 22, 2008 7:37 pm 
 
On Saturday 23 February 2008, Dan Kegel wrote:
Quote:
On Fri, Feb 22, 2008 at 4:09 PM, Alan McKinnon
<alan.mckinnon@gmail.com> wrote:
Quote:
Quote:
For example, there is no sane reason in the world that VC++ should
always work under Wine, considering the deep knowledge of Windows
that is built into VC++.

I don't think that's a good example. While I agree that
Wine is not designed to run ALL windows software
(it'll never run arbitrary VxD's, for instance), it can and
will run Visual C++. Visual C++ 6 works quite well modulo
one bug in ole32, and Visual C++ Toolkit 2003 installs and
runs pretty well module two bugs keeping .net 1.1 from installing.
Visual C++ 6 and 2003 will eventually work well enough to make
Windows developers comfortable. And valgrind will support windows
apps well enough that Windows developers might... actually...
prefer... to develop their Windows apps on Linux sometimes.

Maybe it is a bad example, it's the first one I pulled out of my head.

But really, why would one compile something for Windows on Wine? I can
see that some OSS Windows apps might need a bit of tweaking and
recompiling to run better on a specific setup, but to do that
legitimately you'd need a valid license for the dev tools. Such a
person would also have a Windows machine to hand surely?

It's also a handy way for a Wine dev to check that bits of Wine are
working correctly, but is it really that useful in the general case, is
it something that regular users would do and does it warrant an
especially high priority?

There's also the legal issue. Yes I know this isn't a nice topic but it
has to be confronted at some point. Do the MS dev tools permit
installation and running on a non-MS platform? That might have been
something not explicitly stated in older licenses, but I'll bet it's
certainly not the case with the dev stuff MS released just this week
for example.

I must admit thought that it would be cool to support things like
compilers and get a better more efficient result than MS can <evil
grin>. That kind of technical expertise impresses me greatly but we do
have to stay within reasonable limits

--
Alan McKinnon
alan dot mckinnon at gmail dot com


Top 
 Post Posted: Fri Feb 22, 2008 7:43 pm 
 
Read comments inline,

2008/2/23, Alan McKinnon <alan.mckinnon@gmail.com>:
Quote:
On Friday 22 February 2008, Volodymyr Shcherbyna wrote:
Quote:
Hello Tres,

Yes, agree, there might be Linux equivalents to accomplish the same
tasks. But let me pickup the description of winehq from official
web-site : "[...] a compatibility layer for running Windows programs
[...]". Doesn't that mean, that *all* software should work?


NO.

It means that applications that users can reasonably expect to run
should be able to run. Note that it is applications that Wine targets.


The description is quite non-precise. Who defines the policy of what should
be run and what shouldn't? What I am trying to explain, is that, once
something is designed to be compatible with Windows API, it should be
compatible with at any case at any layers.

For example, there is no sane reason in the world that VC++ should
Quote:
always work under Wine, considering the deep knowledge of Windows that
is built into VC++. If you are developing a Windows app, then you
should compile it on ... Windows. And Wine runs atop a *nix system, so
it has no need to implement any NTFS-specific code as it does not need
to use NTFS as a storage layer. Should you need to manipulate NTFS for
some reason, we have ntfs-ng for that job.


I don't care about file systems. What I would like to see in wine, is a
little more abstractionist things, for example, file system filters support.
NDIS IM filters, TDI providers, WFP, Kernel sockets and other things.

There has to be a point where Wine stops and the correct answer to
Quote:
anything more is "You should use Windows for that". I believe that line
lies just beyond user-space apps.


Any other ideas on this issue?

--
Quote:
Alan McKinnon
alan dot mckinnon at gmail dot com




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


Top 
 Post Posted: Fri Feb 22, 2008 7:46 pm 
 
On 23/02/2008, Volodymyr Shcherbyna <volodymyr.shcherbyna@gmail.com> wrote:

Quote:
I don't care about file systems. What I would like to see in wine, is a
little more abstractionist things, for example, file system filters support.
NDIS IM filters, TDI providers, WFP, Kernel sockets and other things.


Presumably the best thing for you to do at this stage is write the
code and get it into Wine ;-)

(though if you've access to actual Windows code, this might not be possible.)


- d.


Top 
 Post Posted: Fri Feb 22, 2008 7:47 pm 
 
On Fri, Feb 22, 2008 at 6:33 PM, Alan McKinnon <alan.mckinnon@gmail.com> wrote:
Quote:
On Saturday 23 February 2008, Dan Kegel wrote:
Quote:
On Fri, Feb 22, 2008 at 4:09 PM, Alan McKinnon
<alan.mckinnon@gmail.com> wrote:
Quote:
Quote:
For example, there is no sane reason in the world that VC++ should
always work under Wine, considering the deep knowledge of Windows
that is built into VC++.

I don't think that's a good example. While I agree that
Wine is not designed to run ALL windows software
(it'll never run arbitrary VxD's, for instance), it can and
will run Visual C++. Visual C++ 6 works quite well modulo
one bug in ole32, and Visual C++ Toolkit 2003 installs and
runs pretty well module two bugs keeping .net 1.1 from installing.
Visual C++ 6 and 2003 will eventually work well enough to make
Windows developers comfortable. And valgrind will support windows
apps well enough that Windows developers might... actually...
prefer... to develop their Windows apps on Linux sometimes.

Maybe it is a bad example, it's the first one I pulled out of my head.

But really, why would one compile something for Windows on Wine?

Because he doesn't want to use Windows yet he has to use Visual Studio?

Quote:
I can
see that some OSS Windows apps might need a bit of tweaking and
recompiling to run better on a specific setup, but to do that
legitimately you'd need a valid license for the dev tools. Such a
person would also have a Windows machine to hand surely?


Not surely at all. Anyone can acquire Visual Studio without having or
getting Windows.

Quote:
It's also a handy way for a Wine dev to check that bits of Wine are
working correctly, but is it really that useful in the general case, is
it something that regular users would do and does it warrant an
especially high priority?

There's also the legal issue. Yes I know this isn't a nice topic but it
has to be confronted at some point. Do the MS dev tools permit
installation and running on a non-MS platform? That might have been
something not explicitly stated in older licenses, but I'll bet it's
certainly not the case with the dev stuff MS released just this week
for example.

I must admit thought that it would be cool to support things like
compilers and get a better more efficient result than MS can <evil
grin>. That kind of technical expertise impresses me greatly but we do
have to stay within reasonable limits


If you're referring to Visual Studio again, as Dan already stated, it
works pretty well and there aren't many issues left to fix. They're
certainly within reasonable limits.

--
James Hawkins


Top 
 Post Posted: Fri Feb 22, 2008 8:11 pm 
 
<volodymyr.shcherbyna@gmail.com> wrote:
Quote:
The description is quite non-precise. Who defines the policy of what should
be run and what shouldn't? What I am trying to explain, is that, once
something is designed to be compatible with Windows API, it should be
compatible with at any case at any layers.

Wine is for running win32 userspace apps on Unix.
It in general doesn't support NT kernel mode stuff.
We implement a tiny bit of NT kernel mode stuff only
under duress, e.g. when a very, very popular app
won't run without it.
We are willing in principle to implement UMDF because
it's user mode stuff.
End of story.

Thus you should not expect things like NDIS drivers,
TDI providers, or kernel sockets to ever work in Wine.
Sorry.

That said, ndiswrapper is a scheme for using NDIS drivers
inside the Linux kernel. If one wanted to badly enough,
one could do more in that direction. But it has nothing to
do with Wine.
- Dan


Top 
 Post Posted: Fri Feb 22, 2008 8:11 pm 
 
On Saturday 23 February 2008, Volodymyr Shcherbyna wrote:
Quote:
I am not sure that ReacOS is a good example. Quite a big amount of
code in ReactOS contains leaked code of Windows (from Windows 2k).
Recently I did a research, since I have access to Windows code(code
premium subscription), I am able to compare things.

Please don't top post.

Unfortunately, that lessens your chances of being able to submit code to
the Wine project. I don't know what the Wine project's policy is on
such things, it is ultimately Alexandre Julliard's call as the de-facto
BDFL.

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


Top 
 Post Posted: Sat Feb 23, 2008 4:29 am 
Offline
Newbie
Newbie

Joined: Fri Feb 22, 2008 3:37 pm
Posts: 2
Location: Moscow, Russia
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.


Top 
 Post Posted: Sat Feb 23, 2008 2:30 pm 
 
On Friday 22 February 2008 17:12:41 wine-users-request@winehq.org wrote:
Quote:
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.ph ... tent=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.


Top 
Display posts from previous:  Sort by  
 
 Page 1 of 1 [ 21 posts ] 




Board index » WineHQ » Wine Help


Who is online

Users browsing this forum: No registered users and 4 guests

 
 

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: