[Wine] Is it possible to port (part of) WINE to iOS?

[James McKenzie]

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