On 6/4/11 8:19 PM, SpawnHappyJake wrote:
James McKenzie, I know you develop for Wine, so you know what you are talking about. Could you please walk me through how Wine is NOT a kernel?
Is it because it translates things into Unix program calls, rather than passing them right onto the processor?
Correct in your statement. Also, kernels ALWAYS run in 'ring 0' and
have UNRESTRICTED access to all things computer (memory and devices).
However, the kernel knows nothing about the capabilities of your video
card, thus we have an interface, called a driver, at ring 1/2.
Userspace programs run at ring 3 or 4.
I already knew that Wine runs in user space as opposed to the reserved kernel space, from a rights perspective of which the processor's "protected mode" reenforces. I also knew that Wine gets all hardware information from the operating system's kernel, so Wine doesn't have all the pieces necessary to be an independent operating system.
Is that why you're saying it's not a kernel?
Yes. That is one of the reasons I'm saying it is not a kernel. If a
kernel 'crashes' you cannot use your computer anymore without restarting
it. Some drivers can cause the kernel to 'panic' and crash. Wine, in
and of itself, cannot do this. It just stops running and you can
restart it.
Yes, I caught that you said
The reason I state that WINE is not a kernel is because it cannot run any Windows hardware/software drivers. If this were possible, many of the complaints about WINE would not exist.
but I just want a more thorough understanding by which to model how Wine works in my head.
Wine runs in a translation mode. Say you make a call to a DirectX
function. Wine interprets that call and translates it to an OpenGL call
that has the same function. Sometimes this is quite complex. The same
is done for any Windows call. They are converted into calls that Linux
can understand.
But from a less strict standpoint, aren't the Windows programs you run in Wine ran through Wine's "kernel", which is further executed by the operating system's REAL kernel?
Yes. After all calls are translated from Windows calls to Linux/UNIX
calls. Read through the source code. There are hundreds and thousands
of calls that Windows uses through the Windows kernel to control program
operation. Some of those calls are easy to implement, some are very
difficult.
I know that one part of the Wine program is a kernel. It's "ntoskrnl.exe", and it's talked about over here:http://source.winehq.org/WineAPI/ntoskrnl.html Somewhere there is a list of the pieces of Wine, and each piece has a name next to it saying who develops that piece. One of them was the Wine kernel.
It is an interface to the Linux/UNIX kernel. So is kernel32.dll.
I think I detect the issue here. All Operating Systems have a 'kernel'
that is the piece that makes them run. It is the direct interface
between the core hardware (CPU/Memory and some limited hardware
functions). Wine interfaces between the Linux/UNIX kernel and hardware
drivers and the Windows program. It is NOT an emulator because it does
NOT appear to the Program as having the full capabilities of Windows.
It is not a virtualizer either. It is an interface/translation
program. That is ALL it is. That is why we cannot run hardware
drivers. That said, there are some very limited driver support
capabilities being worked on for Universal Serial Bus devices, like
iPods and USB dongles that do NOT emulate either a hard drive or
communications port (and these are detected by the underlying OS, not by
Wine.) Thus, if you wanted to use a high end video card, you would have
to find high quality Linux/UNIX video drivers and install them. You
could NOT use the Windows drivers, as we do not have a 'kernel' in the
product.
James McKenzie
