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:
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.
On Fri, Feb 22, 2008 at 7:00 PM, Volodymyr Shcherbyna volodymyr.shcherbyna@gmail.com wrote:
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.
I was the project cordinator for ReactOS for a while and still have a pretty good relationship with a lot of the active developers. Can you provide me a list of all code (just a list of offending functions would be fine) that is in ReactOS that you know to be from leaked windows sources and I will work with them to remove all offending code.
Thanks Steven
On Sat, Feb 23, 2008 at 2:00 AM, Steven Edwards winehacker@gmail.com wrote:
On Fri, Feb 22, 2008 at 7:00 PM, Volodymyr Shcherbyna volodymyr.shcherbyna@gmail.com wrote:
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.
I was the project cordinator for ReactOS for a while and still have a pretty good relationship with a lot of the active developers. Can you provide me a list of all code (just a list of offending functions would be fine) that is in ReactOS that you know to be from leaked windows sources and I will work with them to remove all offending code.
Thanks Steven
Essentially the same claims were made (I believe by the same party) on the microsoft public newsgroups about a month ago, with the same offer to expunge the offending code, and AFAICT, no action taken.
With regard to the other things in this thread, if the sysInternals group at Microsoft is willing to share the interface between their application and driver, wine could easily implement it (ultimately far more secure than the Windows solution), then the tools could run on wine. Unless you're expecting filemon running in wine to magically start showing all file access even from applications not using the Win32 API.
The goal should not be to run Windows kernel drivers in Linux kernel mode, that's insanity, but to implement the userspace/kernel interface API with Linux device drivers behind. Yes, that means people will be limited to hardware supported by Linux, but those drivers have far better minimum reliability than even the Windows ones carrying that joke called WHQL certification.
Ben Voigt C++ MVP https://mvp.support.microsoft.com/Profile/voigt (and MS has removed all the information on my public profile since they changed the format...)
Am Mittwoch, 27. Februar 2008 01:52:32 schrieb richardvoigt@gmail.com:
With regard to the other things in this thread, if the sysInternals group at Microsoft is willing to share the interface between their application and driver, wine could easily implement it (ultimately far more secure than the Windows solution), then the tools could run on wine. Unless you're expecting filemon running in wine to magically start showing all file access even from applications not using the Win32 API.
What is the use of just running those tools? Aren't there Linux equivalents for it?
If it was a test case for better driver support, then yeah, it is useful, but just running those apps by cloning parts of them seems wasted effort to me
On Wed, Feb 27, 2008 at 8:26 AM, Stefan Dösinger stefandoesinger@gmx.at wrote:
Am Mittwoch, 27. Februar 2008 01:52:32 schrieb richardvoigt@gmail.com:
With regard to the other things in this thread, if the sysInternals group at Microsoft is willing to share the interface between their application and driver, wine could easily implement it (ultimately far more secure than the Windows solution), then the tools could run on wine. Unless you're expecting filemon running in wine to magically start showing all file access even from applications not using the Win32 API.
What is the use of just running those tools? Aren't there Linux equivalents for it?
I don't know. Certainly procmon is lightyears ahead of strace in terms of usability, plus isn't limited to a single process. A google found that KDE will be providing a GUI app named "inspektor" but I couldn't find very much on it. What is your preferred utility for filling that niche (logging I/O calls)?
If it was a test case for better driver support, then yeah, it is useful, but just running those apps by cloning parts of them seems wasted effort to me
Those particular apps are useful to the point that every competent Windows sysadmin knows of them.
Am Mittwoch, 27. Februar 2008 21:18:28 schrieb richardvoigt@gmail.com:
What is your preferred utility for filling that niche (logging I/O calls)?
I never needed that; All I am logging are d3d calls, there I am using PixWin or simple wine logs, and bugle or the apple opengl profiler on the gl side.
Those particular apps are useful to the point that every competent Windows sysadmin knows of them.
Ya, but do you expect the Windows tools to be able profile Linux processes, and know about Linux syscalls, etc? So all you could use them for is auditing Windows processes inside Wine. They are Windows system utilities and thus tied to the Windows API. Trying to use them on Wine is similar to trying to use sudo in mingw on Windows, or trying to check an NTFS partition with e2fsck. Running Windows system tools is way beyond the scope of Wine IMHO.
-
richardvoigt＠gmail.com -
Stefan Dösinger -
Steven Edwards -
Volodymyr Shcherbyna