[Wine] Windows Kernel & Executive implementation

[Volodymyr Shcherbyna]

Read comments inline,

2008/2/23, Alan McKinnon <alan.mckinnon at gmail.com>:
>
> On Friday 22 February 2008, Volodymyr Shcherbyna 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?
>
>
> 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
> 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
> 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?

--
> 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-devel/attachments/20080223/2e4055bc/attachment.htm