Windows Kernel & Executive implementation
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-us ... chment.htm
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
Windows Kernel & Executive implementation
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 <[email protected]>
wrote:
--
- [email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-us ... chment.htm
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 <[email protected]>
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-us ... chment.htm
--
- [email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-us ... chment.htm
Windows Kernel & Executive implementation
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 <[email protected]>:
--
with best regards,
Volodymyr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-us ... chment.htm
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 <[email protected]>:
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 <
[email protected]> 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-us ... chment.htm
--
- [email protected]
--
with best regards,
Volodymyr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-us ... chment.htm
Windows Kernel & Executive implementation
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 <[email protected]>
wrote:
--
- [email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-us ... chment.htm
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 <[email protected]>
wrote:
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 <[email protected]>:freelyProbably the most common response you will get is, there are oftendoingavailable 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 <
[email protected]> wrote:
Hello everyone, my name is Volodymyr, I am driver developer mostlyIstuff for Windows.
I discovered that WineHQ project does not have support for drivers (amtowrong?). In other words, quite a big amount of applications will faildriversfunction properly, because many of them are using helper devicerequiresto
get some extended functionality. I can just mention RegMon, FileMon,
TDIMom,
and others.
Theoretically, this task is possible to be implemented, but ithttp://www.winehq.org/pipermail/wine-us ... chment.htmquite 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:
--
with best regards,
Volodymyr
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://www.winehq.org/pipermail/wine-us ... chment.htm
--
- [email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-us ... chment.htm
Windows Kernel & Executive implementation
On Fri, Feb 22, 2008 at 3:02 AM, Volodymyr Shcherbyna
<[email protected]> wrote:
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
<[email protected]> wrote:
I know very little about this, but my impression is thatI 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.
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
Windows Kernel & Executive implementation
Thank you,
I missed that code. Okay, I will take a more detailed look.
2008/2/22, Dan Kegel <[email protected]>:
--
with best regards,
Volodymyr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-us ... chment.htm
I missed that code. Okay, I will take a more detailed look.
2008/2/22, Dan Kegel <[email protected]>:
On Fri, Feb 22, 2008 at 3:02 AM, Volodymyr Shcherbyna
<[email protected]> wrote:
II discovered that WineHQ project does not have support for drivers (amtowrong?). In other words, quite a big amount of applications will failtofunction properly, because many of them are using helper device driversTDIMom,get some extended functionality. I can just mention RegMon, FileMon,I know very little about this, but my impression is thatand others.
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
Windows Kernel & Executive implementation
Unfortunately, that code just do stubs, and it is not actually executed in
kernel mode.
--
with best regards,
Volodymyr
2008/2/22, Dan Kegel <[email protected]>:
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-us ... chment.htm
kernel mode.
--
with best regards,
Volodymyr
2008/2/22, Dan Kegel <[email protected]>:
-------------- next part --------------On Fri, Feb 22, 2008 at 3:02 AM, Volodymyr Shcherbyna
<[email protected]> wrote:
II discovered that WineHQ project does not have support for drivers (amtowrong?). In other words, quite a big amount of applications will failtofunction properly, because many of them are using helper device driversTDIMom,get some extended functionality. I can just mention RegMon, FileMon,I know very little about this, but my impression is thatand others.
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
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-us ... chment.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.
Windows Kernel & Executive implementation
Volodymyr Shcherbyna <[email protected]> wrote:
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
The current ntoskrnl.c is enough to run a few apps.Unfortunately, that code just do stubs, and it is not actually executed inhttp://source.winehq.org/source/dlls/nt ... ntoskrnl.c[many apps use helper device drivers, e.g. RegMon, FileMon, TDIMom]
kernel mode.
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
Windows Kernel & Executive implementation
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 <[email protected] ([email protected])>:
--
with best regards,
Volodymyr
2008/2/23, Fireball <[email protected] ([email protected])>:
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
Windows Kernel & Executive implementation
On Friday 22 February 2008, Volodymyr Shcherbyna wrote:
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
NO.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?
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
Windows Kernel & Executive implementation
On Fri, Feb 22, 2008 at 4:09 PM, Alan McKinnon <[email protected]> wrote:
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
I don't think that's a good example. While I agree thatFor 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++.
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
Windows Kernel & Executive implementation
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 <[email protected]>:
--
with best regards,
Volodymyr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-us ... chment.htm
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 <[email protected]>:
Volodymyr Shcherbyna <[email protected]> wrote:
inUnfortunately, that code just do stubs, and it is not actually executedThe current ntoskrnl.c is enough to run a few apps.kernel mode.
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
Windows Kernel & Executive implementation
On Saturday 23 February 2008, Dan Kegel wrote:
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
<[email protected]> wrote:On Fri, Feb 22, 2008 at 4:09 PM, Alan McKinnon
Maybe it is a bad example, it's the first one I pulled out of my head.I don't think that's a good example. While I agree thatFor 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++.
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.
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
Windows Kernel & Executive implementation
Read comments inline,
2008/2/23, Alan McKinnon <[email protected]>:
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
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
--
with best regards,
Volodymyr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-us ... chment.htm
2008/2/23, Alan McKinnon <[email protected]>:
The description is quite non-precise. Who defines the policy of what shouldOn Friday 22 February 2008, Volodymyr Shcherbyna wrote:NO.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?
It means that applications that users can reasonably expect to run
should be able to run. Note that it is applications that Wine targets.
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
I don't care about file systems. What I would like to see in wine, is aalways 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.
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
Any other ideas on this issue?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
with best regards,
Volodymyr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-us ... chment.htm
Windows Kernel & Executive implementation
On 23/02/2008, Volodymyr Shcherbyna <[email protected]> wrote:
code and get it into Wine
(though if you've access to actual Windows code, this might not be possible.)
- d.
Presumably the best thing for you to do at this stage is write theI 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.
code and get it into Wine
(though if you've access to actual Windows code, this might not be possible.)
- d.
Windows Kernel & Executive implementation
On Fri, Feb 22, 2008 at 6:33 PM, Alan McKinnon <[email protected]> wrote:
getting Windows.
works pretty well and there aren't many issues left to fix. They're
certainly within reasonable limits.
--
James Hawkins
Because he doesn't want to use Windows yet he has to use Visual Studio?On Saturday 23 February 2008, Dan Kegel wrote:<[email protected]> wrote:On Fri, Feb 22, 2008 at 4:09 PM, Alan McKinnonMaybe it is a bad example, it's the first one I pulled out of my head.I don't think that's a good example. While I agree thatFor 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++.
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.
But really, why would one compile something for Windows on Wine?
Not surely at all. Anyone can acquire Visual Studio without having orI 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?
getting Windows.
If you're referring to Visual Studio again, as Dan already stated, itIt'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
works pretty well and there aren't many issues left to fix. They're
certainly within reasonable limits.
--
James Hawkins
Windows Kernel & Executive implementation
<[email protected]> wrote:
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
Wine is for running win32 userspace apps on Unix.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.
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
Windows Kernel & Executive implementation
On Saturday 23 February 2008, Volodymyr Shcherbyna wrote:
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
Please don't top post.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.
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
Re: Windows Kernel & Executive implementation
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.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
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.
Windows Kernel & Executive implementation
On Friday 22 February 2008 17:12:41 [email protected] wrote:
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.
http://www.kde-apps.org/content/show.ph ... tent=75484Hello 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,
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.