WineHQ
Wine Forums

Board index » WineHQ » Wine Help




 Page 1 of 1 [ 23 posts ] 



 
Author Message
 Post Posted: Tue May 31, 2011 4:28 am 
Offline
Newbie
Newbie

Joined: Tue May 31, 2011 2:43 am
Posts: 2
Since Apple's Mac X and iOS share the same kernel -- Darwin. And WINE has port for Mac X.

Is it possible to port (part of) WINE to iOS? For example, "winbase.h", etc.


Top 
 Post subject:
 Post Posted: Tue May 31, 2011 5:32 am 
Offline
Newbie
Newbie

Joined: Tue May 31, 2011 2:43 am
Posts: 2
The purpose for porting WINE to iOS is to provide source code level compatibility for exist Win32 application.


Top 
 Post subject:
 Post Posted: Tue May 31, 2011 8:49 am 
Offline
Moderator
Moderator
User avatar

Joined: Wed May 14, 2008 11:44 am
Posts: 1163
Well, maybe, but there are some challenges.

The app store guidelines say the upper limit on app size is 20MB,
and Wine takes up more than that.

Wine uses X at the moment, which isn't on iOS. (Eventually
that problem will go away when the DIB Engine and Quarz driver
are finished... )

The app store guidelines say that you must use apple's provided
webkit for all web browsing, so any app that uses IExplore may
be in trouble.

There are challenges related to the app store and LGPL code, see
http://stackoverflow.com/questions/4598 ... -app-store
http://multinc.com/2009/08/24/compatibi ... -the-lgpl/
You may need to open source your app or at least provide .o files
for it to obey the LGPL in the context of the apple app store.

There are probably others.


Top 
 Post subject:
 Post Posted: Tue May 31, 2011 9:24 am 
Offline
Level 4
Level 4

Joined: Sat Feb 20, 2010 2:31 am
Posts: 159
yea sounds cool also on Android and I even have a very small *.exe that I'd use on my HTC smartphone...


Top 
 Post subject:
 Post Posted: Tue May 31, 2011 10:06 am 
Offline
Level 4
Level 4

Joined: Sat Feb 20, 2010 2:31 am
Posts: 159
well the app store charges 100.- and the licence restrictions sound weird...maybe only Android then? Would be cool thanks. :D


Top 
 Post Posted: Sat Jun 04, 2011 1:05 am 
Offline
Level 5
Level 5
User avatar

Joined: Sun Feb 06, 2011 5:57 am
Posts: 272
The reason why I've been gone from the forums for the last few days is because I've been researching this.
There are ways of getting apps into iOS other than the app store. And I'm not necessarily referring to jailbreaking, though that is one method. Please note that jailbreaking is no longer illegal.
You might have memories of Pre-iPod Touch iPods showing up as a storage disk that could be mounted, viewed in the file browser, and you could copy files on and off and thus use it as an external hard drive. iPhones, iPod Touches, and I'm assuming iPads, do not do "show" themselves as hard drives, are not recognized as such by the kernel (heart of the operating system), and thus cannot be mounted or even formatted. I found out about some geniuses that figured out how to mount an iPhone or iPod Touch or iPad as a hard drive in Linux. For some more details on why this is a big deal and what's going on with this mounting business, I wrote this: http://pastebin.com/L806qmYZ.
Anyways, it was quite the trick to mount an iOS device. I thought, "Maybe people could just mount their iOS device in Linux, and copy over a WINE app into the applications folder. I think I'll post that as something that might work. Wait - I'd have to admit that I haven't tried it. That wouldn't sound good. I better try first." So I did. It doesn't let you copy apps off or put a file or a folder where it shows your apps being. Oddly, it only showed apps that I put on, and not the apps that came with the iPhone. I wonder if this is different with a jailbroken iPhone, and if you could just copy a WINE app over like that. I also wonder if you would see more files and folders. Prehaps a non-jailbroken iPhone is not mounted at its root directory. If you could, I think you have to put an SHA1 hash of the app in a plist file somewhere for it to allow you to run the app.
Next thought, "Hmm. Can they get a WINE app through Cydia? What exactly is jailbreaking? Will that let it in somehow?" Wikipedia says that jailbreaking is simply removing all the restrictions from an iPhone.
You open source people are going to love this: the jailbroken iPhone crowd has set up repositories and APT stuff for installing apps onto iPhones. So I would think that you wouldn't even need to go through Cydia to get a WINE app onto a jailbroken iPhone. Just make an APT repository for the WINE app, and they do the equivalent of adding your PPA, and they tell it to install! Furthermore, Cydia says the packages actually follow Debian format: http://cydia.saurik.com/faq/repositories.html
Then my third main thought occurred to me, "These apps in the AppStore don't just appear there. Someone has to make them. That implies the makers of the apps tested them as they were making them. That implies that they got their app onto their iPhone for testing without the AppStore. Surely Apple provides a way of doing this without jailbreaking." They do.
The way it works is that all apps ran by a non-jailbroken iPhone have to have a signature on them. Unless an app has a trusted signature, the iPhone won't run it. So before you can even test an app you are working on, you are supposed to request a signature from Apple, approved by Apple, and that new signature you obtain is in the "trusted signatures list". You can sign apps with that signature. Then you have to set your iPhone to "Use for Development": [url]http://developer.apple.com/library/ios/#documentation/Xcode/Conceptual/iphone_development/128-Managing_Devices_and_Digital_Identities/devices_and_identities.html#//apple_ref/doc/uid/TP40007959-CH4-SW2[/url] .
Then you set up this special "Portal" through which you can put your signature onto the iPhone, which has been set to "Use for Development", allowing the iPhone to run any apps signed by your signature. Then you can work on an app, sign it, and move it to your iPhone for testing, through the Portal.
Or instead of getting a signature issued by Apple, you can create your own signature, called self-signing. You can mark a jailbroken-iPhone (though I haven't seen it explicitly stated that you can't do this self-signing workaround on a non-jailbroken iPhone) to "Use for Development", and load the self-signed signature to the iPhone through the "Portal", and you can sign the app you made with that signature, put the app onto the iPhone with through the "Portal", and it will run on the iPhone because the signature is in it's "trusted" list. See here: http://www.alexwhittemore.com/?p=398
Now what about developing an iOS app in Linux? There's some people working on making that a possibility, the iphone-dev project: http://code.google.com/p/iphone-dev/
To tie this back to Android, a jailbroken iPhone can be dual booted with Android.

There is another issue to overcome, that is indeed possible to overcome. The assemblby instuction set of the iOS device processor. Processors are arrangements of electrical components arrangened in such a way that they process and give outputs for certain commands. Different processors are designed to process different commands. The set of commands a given processor can process is its assembly instruction set. The main one right now is the x86 instruction set. If you wrote a program in terms of x86 instructions, it would only work on processors designed for that instruction set. If you wrote a program in a set of terms not related to a processor, but were instead terms created to be easier to think in, called a programming language, and then had a translator (compiler) for each instruction set that could convert that programming language's terms into assembly instructions for a given processor's instruction set, you could translate (compile) your program to work on whatever processor you want to. Except that most programs don't run directly on the processor; instead they run on the kernel which runs on the processor and passes code to the processor. So programs are actually compiled taking into consideration both kernel and processor instruction set. The kernel is effectively the processor as far as an average program is concerned, to my understanding.
How is this a problem? WINE is a kernel that runs already compiled programs. That means WINE is running programs already in terms of a processor's instruction set - the x86 instruction set. These instuctions get executed by being passed to the processor. The iOS device processor uses an ARM instruction set rather than an x86 instruction set. How can WINE pass x86 instructions on to a processor that only does ARM instructions, and have the instructions executed? It can't. They have to be converted in live time from x86 to ARM to run on the ARM processor, the A4.
The thing that translates the instructions is called a processor emulator. You create a program that can process x86 instructions, probably with a programming language. If you used a programming language, you compile this program for an ARM processor, taking into consideration the iOS kernel that it will directly be running on. You run the WINE kernel on top of this virtual processor.
Darwine is a project that put WINE on a processor emulator, so we know that it is possible. See here: http://en.wikipedia.org/wiki/Darwine. How did I know Darwine had an emulator? What else but a James McKenzie post, of course!


Top 
 Post subject:
 Post Posted: Sat Jun 04, 2011 3:36 am 
Offline
Level 4
Level 4

Joined: Sat Feb 20, 2010 2:31 am
Posts: 159
darwine is obsolete...you mac freaks are weird...thinking of opensource as illegal but basing their OS onto...


I've a very small command line exe, which i desperately would need while im on the road.
Basically it does encrypt a simple text file nothing else.

If someone could help me with that to run on a HTC Android would be cool.


Top 
 Post Posted: Sat Jun 04, 2011 6:53 am 
Offline
Moderator
Moderator

Joined: Wed Apr 27, 2011 11:01 pm
Posts: 1153
On 6/4/11 1:36 AM, ahso wrote:
Quote:
darwine is obsolete...you mac freaks are weird...thinking of opensource as illegal but basing their OS onto...

Watch what you say. Some people would take that as an insult as best.
Yes, MacOSX IS based and uses the FreeBSD Mach-o kernel.
Quote:
I've a very small command line exe, which i desperately would need while im on the road.
Basically it does encrypt a simple text file nothing else.
This should be very easy to port to an operating system with the
appropriate library files. It should basically be 'plug and play'.
Quote:
If someone could help me with that to run on a HTC Android would be cool.

Contact an Android programmer. With sufficient money, I'm sure they
would be willing to help you out.

James McKenzie'
Quote:




Top 
 Post Posted: Sat Jun 04, 2011 10:32 am 
 
On 6/4/11 5:52 AM, James McKenzie wrote:
Quote:
Yes, MacOSX IS based and uses the FreeBSD Mach-o kernel.
@jjmckenzie: You mean it's part Mach and part FreeBSD.
Quote:
On 6/4/11 1:36 AM, ahso wrote:
Quote:
If someone could help me with that to run on a HTC Android would be cool.
@ahso: Please don't hijack threads.

Chip


Top 
 Post subject: Go back and try again
 Post Posted: Sat Jun 04, 2011 1:32 pm 
Offline
Level 5
Level 5
User avatar

Joined: Sun Feb 06, 2011 5:57 am
Posts: 272
Ahso,
First of all, I'm not a Mac freak, Linux in my main OS. Second, I never said that open source was illegal. I said that JAILBREAKING is NO LONGER illegal, to prevent people from thinking that I was posting about illegal things, especially given that that is against forum rules. Third, whether Darwine is obsolete or not is irrelevant - I was merely referring to it to show that it is possible to run WINE on a processor emulator. Fourth, don't bite the hand that feeds you.

Everyone,
Anyways, I hope I have shown how it is possible to develop a WINE app for iOS running on the A4 without the AppStore, and without having to get a signature from Apple, bypassing any of Apple's restrictions, which, to remind again, isn't illegal anymore - details in my previous post and the links therein.

Cheers,
Jake


Top 
 Post subject:
 Post Posted: Sat Jun 04, 2011 2:49 pm 
Offline
Level 2
Level 2

Joined: Wed Jun 01, 2011 6:42 am
Posts: 14
Is it possible to run Wine on a non-Intel processor? I didn't know that, I thought it really depended on having an Intel CPU. If Wine is ready to emulate Intel code on a non-Intel machine, then it could be a solution to the other thread about running win64 apps on OSX: if the OSX kernel has ABI incompatibilities with win64 that are impossible to workaround, then emulating the Intel CPU (in X86_64 mode) would be a solution. Maybe it's slow, but it would run, and I don't need speed.


Top 
 Post Posted: Sat Jun 04, 2011 4:49 pm 
 
On 6/4/11 1:49 PM, asiga wrote:
Quote:
Is it possible to run Wine on a non-Intel processor?
Yeah, but you can't run i386 code. In general, "Wine Is Not an
Emulator". It's a compatibility layer that sits on top of whatever
kernel and libraries you have. That's why we still can't run Wine64 on Mac.


Top 
 Post subject: Let me clarify this...
 Post Posted: Sat Jun 04, 2011 5:33 pm 
Offline
Level 5
Level 5
User avatar

Joined: Sun Feb 06, 2011 5:57 am
Posts: 272
I said that you can place wine ON TOP OF a processor emulator, not that it is one.
Let's break this down. A processor runs a program called a kernel. That is the only program the processor runs directly, unless you have a rootkit, which is usually pretty bad.
All your other programs are ran by the kernel, which passes code onto the processor.
Therefore the kernel and the pieces of programs that get passed onto the processor must be in terms that the processor can directly execute.
WINE is a kernel ran by another kernel. It passes code from the Windows applications it is running onto the host kernel to be passed to the processor.
There is no translation of processor-level instructions being translated from one processor's instruction set to another processor's instruction set anywhere in there.
Therefore, in order for WINE to run programs compiled for (in terms of) an x86 processor, WINE must have an x86 processor.
That processor can be a physical x86 processor, or it can be an emulated one.
I said that you can place wine ON TOP OF a processor emulator, not that it is one. A WINE app would have to come with it's own x86 processor emulator packaged as a part of the app. To make such an emulator would be an endeavor separate from the WINE project. That doesn't mean we'll have to hate that dev team or anything; it would just be a separate project.
Hope that clears it up. I didn't mean to make any confusion.
And by the way, Ahso, I wrote this post on my iPhone. Come on, you got to have some humor.
Cheers,
Jake


Top 
 Post Posted: Sat Jun 04, 2011 5:38 pm 
 
Quote:
Let's break this down. A processor runs a program called a kernel. That is the only program the processor runs directly, unless you have a rootkit, which is usually pretty bad.

Whoa whoa whoa. Can you go more into this "kernel" thing? I'm really confused - is that like a kernel of corn or something? Any any links you can send about the rotkit or an emluator or indestruction sets would be ├╝ber helpful.

I normally just press the power button on my computer and use The Windows. -r


Top 
 Post Posted: Sat Jun 04, 2011 6:50 pm 
Offline
Moderator
Moderator

Joined: Wed Apr 27, 2011 11:01 pm
Posts: 1153
SpawnHappyJake wrote:
I said that you can place wine ON TOP OF a processor emulator, not that it is one.

This is what the Darwine project tried to do for Power PC based MacIntosh computers. I was horribly slow.
The good thing is that Wine can still be built on PowerPC based computers and is in the process of being configured to run on ARM based processing devices. The main holdup after that is an ARM <-> x86 emulator that will not bring everything to a crawl.
SpawnHappyJake wrote:
WINE is a kernel ran by another kernel.

No, WINE is NOT a kernel. It is a user-space program the acts as an interface providing Windows Application Programming calls to and from Windows based programs and translates them into Linux/UNIX programming calls. Thus if a program calls a DirectX 10 function, the call and its data are translated into an equivalent Linux/UNIX OpenGL call. DirectX 10, in and of itself does not exist 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.


Top 
 Post subject: ?
 Post Posted: Sat Jun 04, 2011 10:19 pm 
Offline
Level 5
Level 5
User avatar

Joined: Sun Feb 06, 2011 5:57 am
Posts: 272
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?
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, I caught that you said
Quote:
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.
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?
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.
Over at one of the Wine wiki's, "[The Wine server] can be seen, from a functional point of view, as a NT kernel." - http://www.winehq.org/site/docs/winedev-guide/x2591
Furthermore it manages memory, which is rather kernelesque.
I thought that Wine was a kernel without being an operating system. I thought of Wine as a "parasitic operating system" dependent on the host kernel to obtain hardware info and to be passed onto the processor.
Can we call Wine a supervisory program? How about a kerneloid? A virtual kernel? A kernel emulator?
I'm not trying to prove you wrong, James McKenzie, I just want all these things homogenized into one understanding.


Top 
 Post Posted: Sat Jun 04, 2011 10:38 pm 
Offline
Moderator
Moderator

Joined: Wed Apr 27, 2011 11:01 pm
Posts: 1153
On 6/4/11 8:19 PM, SpawnHappyJake wrote:
Quote:
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.
Quote:
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.
Quote:
Yes, I caught that you said
Quote:
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.

Quote:
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.
Quote:
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


Top 
 Post subject: Wow! Thanks
 Post Posted: Sun Jun 05, 2011 1:51 am 
Offline
Level 5
Level 5
User avatar

Joined: Sun Feb 06, 2011 5:57 am
Posts: 272
Wow! Thanks a lot James McKenzie! I have a much better understanding of Wine now, as well as what it takes to have a true kernel.

Ryan Woodsmal, l didn't forget about you. Wikipedia has great stuff on explaining what a kernel is. Here's one:http://en.wikipedia.org/wiki/Kernel_%28computing%29. Wikipedia says that the supervisory program is usually called the kernel, so here's another: http://en.wikipedia.org/wiki/Supervisory_program. Maybe we can talk about what a kernel is later, I got to get to bed. Maybe a Pastebin or something.

Anyways, are there any smart phones that use the x86 instruction set?

I know that running Crysis on Wine on a processor emulator on the iOS kernel on the iPhone hardware is NOT a good idea. That said, running a Windows program in Wine on a processor emulator on the iOS kernel on the iPhone hardware is a much better idea than using DOSBox for iOS to run a Windows program in Windows 98 in DOSBox on DOSBox's emulated processor on the iOS kernel on the iPhone/ iPad hardware.
Ahso said he just wanted to run a Windows command line program. Something microscopic like that should be able to run on Wine on a processor emulator on the iOS kernel on the iPhone/ iPad/ iPod Touch hardware, right? I guess it depends on the command line program, but I would hope it's small. But James McKenzie is right that it would be ASTRONOMICALLY better to port the command line program to be a native iOS app, but that may or may not happen. Not like Wine for iOS would happen.

But if anybody can find a smartphone with a physical processor that uses the x86 instruction set, that might be able to run Windows programs in a port of Wine well.

Cheers,
Jake


Top 
 Post subject: Re: Wow! Thanks
 Post Posted: Sun Jun 05, 2011 3:17 am 
Offline
Level 2
Level 2

Joined: Tue Feb 24, 2009 9:50 pm
Posts: 20
SpawnHappyJake wrote:
Ryan Woodsmal, l didn't forget about you. Wikipedia has great stuff on explaining what a kernel is. Here's one:http://en.wikipedia.org/wiki/Kernel_%28computing%29. Wikipedia says that the supervisory program is usually called the kernel, so here's another: http://en.wikipedia.org/wiki/Supervisory_program. Maybe we can talk about what a kernel is later, I got to get to bed. Maybe a Pastebin or something.


I'm so glad you didn't forget about me!!! I'd feel insulted if you did. Thank you for the Wikileaks link on kernals, those guys got the best infos on everything!

Maybe you should start a new open source operation system project to keep all your great ideas moving. Looking forward to talking about supervision program kernals!


Top 
 Post subject: Correction
 Post Posted: Sun Jun 05, 2011 10:08 am 
Offline
Level 5
Level 5
User avatar

Joined: Sun Feb 06, 2011 5:57 am
Posts: 272
No Ryan, those were NOT links to the site that must not be named, those were links to Wikipedia.
I'm sure it was a "thinko" on your part (like a typo, but it happens in your brain).
This whole kernel thing comes back to smartphones. Ever since phones had kernels, they were on their way to being near-personal computers. With some people, their smartphone has actually become their main computing device.

To put it simply, the kernel is the program that all your other programs are ran by (plus the lower half of dealing with the processor, other hardware, and as well as other technical details). The kernel is like a gatekeeper to the processor. In order for a program's code to be passed onto the processor, the kernel has to allow it.


Top 
 Post Posted: Sun Jun 05, 2011 11:06 am 
 
On 6/5/11 9:08 AM, SpawnHappyJake wrote:
Quote:
No Ryan, those were NOT links to the site that must not be named, those were links to Wikipedia.
I'm sure it was a "thinko" on your part (like a typo, but it happens in your brain).
This whole kernel thing comes back to smartphones. Ever since phones had kernels, they were on their way to being near-personal computers. With some people, their smartphone has actually become their main computing device.

To put it simply, the kernel is the program that all your other programs are ran by (plus the lower half of dealing with the processor, other hardware, and as well as other technical details). The kernel is like a gatekeeper to the processor. In order for a program's code to be passed onto the processor, the kernel has to allow it.
*sigh* He'll never figure it out on his own...

@SpawnHappyJake: Ryan was being sarcastic.

Chip


Top 
 Post Posted: Sun Jun 05, 2011 2:02 pm 
 
Quote:
*sigh* He'll never figure it out on his own...

@SpawnHappyJake: Ryan was being sarcastic.

Sorry Chip, you figured me out. I normally try to avoid feeding the trolls or reciprocating. Sometimes though... I could just say "kernal" again but I'll try to address this like an adult.

Jake: for real, what you're saying is not impossible. Nobody worth their salt would simply say "impossible!" to that because most folks around here A.) know what kernels, operating systems & instruction sets are and B.) know intrinsically that a Turing-complete machine (i.e., any modern computer's instruction set) can simulate any other Turing-complete machine, albeit with some caveats.

However, what you're proposing has been beaten to death by people wanting to run everything from Windows mobile PIM apps on their Android phones to World of Warcraft on their iPads. Yes it can be done. But no, it would likely not be worthwhile due to speed/time/development constraints. Furthermore it's well outside the scope of the Wine project to implement a full machine emulator and enough tooling necessary to simulate a complete skeleton operating system to then run slowly-emulated applications. Wine is a reimplementation of the Windows API with an inbuilt compatibility layer that relies on the underlying operating system. It is not a full system emulator, and should not be.

If you want to see how hard these problems are take look at ReactOS. Or qemu. Or the myriad other projects that aim to achieve these ends. There are a number of problems you'd encounter such as:

- slow machine emulation; i.e., instruction set differences (even with a JIT CPU simulator)
- endian translation issues
- missing/incomplete display technology (Wine is basically tied to X11; Android uses Skia and iOS Quartz)
- underlying OS and API/SDK features missing or disabled due to security constraints and embeddedness
- hardware resource constraints such as limited memory, minimal GPU features, etc.

Unless you want to undertake all that work, and the integration pieces necessary to make it all fit together nicely, this is basically a dead end for any near-term development. Darwine was a decent stab at this but it's dead for a reason. Cost/benefit is something you need to consider in any open source project. The benefit, in terms of usefulness and performance, is basically not there while the cost, in terms of time, is exorbitant. -r


Top 
 Post Posted: Sun Jun 05, 2011 3:16 pm 
Offline
Moderator
Moderator

Joined: Wed Apr 27, 2011 11:01 pm
Posts: 1153
On 6/5/11 12:01 PM, ryan woodsmall wrote:
Quote:
Unless you want to undertake all that work, and the integration pieces necessary to make it all fit together nicely, this is basically a dead end for any near-term development. Darwine was a decent stab at this but it's dead for a reason. Cost/benefit is something you need to consider in any open source project. The benefit, in terms of usefulness and performance, is basically not there while the cost, in terms of time, is exorbitant. -r

Just a short thank you for taking the time to state this. Darwine died
because Apple switched from the PowerPC to Intel platform and the need
to integrate qemu and Wine was not there anymore. No or very little ROI
on just the time it would take to build/test/fix. Several people have
tried to breathe life back into the project only to realize why it was
abandoned in the first place.
Respectfully submitted.


Top 
Display posts from previous:  Sort by  
 
 Page 1 of 1 [ 23 posts ] 




Board index » WineHQ » Wine Help


Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 10 guests

 
 

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: