On Wed, 8 Jan 2003, Michael F. March wrote: [...]
Once you can run Linux/x86 application like Mozilla with acceptable performance in Bochs on MacOS X you should be able to run applications such as Word in Wine with similar performance. Similarly, once Linux/x86 Gimp runs with acceptable performance in Bochs on MacOS X you can run Photoshop in Wine with similar performance (well, once it runs in Wine that is).
Wine should be able to achieve greater performance than Bochs on the same system configuration. IIRC, WABI sent only 25% of its cycles emulating X86 instructions, the rest of the API calls were implemented and executed in native mode. In Bochs case, it spends 100% of its time emulating X86 instructions.
Not really. My understanding of it is that the system libraries (C library, X libraries, etc.) would be native MacOS X libraries (or at least PPC libraries). Thus even running Wine in Bochs would execute native PPC code something like 50% of the time.
By converting Wine's libraries so they are native PPC libraries you can save the extra 25% or so but only at the cost of tremendously increased complexity. I think it would be much harder than improvinig the performance of Bochs by implementing things such as just-in0time compiling (note I don't know exactly what optimisations Bochs already has).
Furthermore this is all assuming that your application spends most of its time executing code in Wine dlls or system libraries. This is most likely to be wrong for applications such as Photoshop, all games, and even to some extent Access or Excel (depends how you use these).
Thus, IMHO, improving the performance of Bochs and sticking to running Windows applications in Wine in Bochs is the best approach for now. Once Bochs is highly optimized, then it will be worth considering integrating it in Wine as a way to squeeze a few extra percents of performance... if it proves necessary.
Plus, making it possible to run any Linux/x86 application on MacOS X has benefits beyond Wine that should not be neglected.