Chip switch to promote Windows conversions

On 14/6/2005 10:06 AM, "Hudson Barton" <hhbvhighwinds.com> spake thus:

> I just wonder whether the change of processors makes it easier for
> Windows software to be converted to Mac OS X.

Probably not much difference, given that the system-level APIs are still
significantly different. If you don't access any OS-provided functionality,
then it would be trivial to convert, but whether you'd be able to do much of
any use without all that good stuff is debatable. As soon as you access
anything to do with the GUI, or file handling or any other system-provided
service, you're increasing the porting complexity.

All the change really means is that the compiled code will be the same for
both OSes. You could in theory come up with some kind of API converter, but
I doubt that it would do good enough a job to be worth it, particularly with
GUI-level stuff. The visual conventions in Mac OS vs. Windows are
sufficiently different to make that kind of thing very difficult to do well.
(You only need to look at the GUIs of so-called "cross-platform" Java
applications to see the truth of this.)

You're still going to see separate Mac OS and Windows versions from
developers because of this, and as a result small developers won't bother
(as always).

--
Nigel Stanger, Dunedin, NEW ZEALAND.
http://public.xdi.org/=nigel.stanger

Quoting Hudson Barton <hhbvhighwinds.com>:

> I just wonder whether the change of processors makes it easier for
> Windows software to be converted to Mac OS X. Is there any
> indication that conversion tools are forthcoming? What specific
> aspects of Windows/OS X conversion are and are not likely to be
> positively affected?

Easier -- probably slightly. Easy, no. In application development it's all
about the OS's API, not the processor.

Unix and Linux can port pretty painlessly between various versions
because there
is a base set of API's that are fairly common between them (POSIX). They also
have the benefit (if the project is popular enough) of developers willing to
help port open source software to a new variation of Unix.

Once you get into the GUI applications porting is much more difficult. Even in
Unix it is less frequent (but still not uncommon) to port GUI applications
between the KDE and GNOME environments.

Windows and Mac OS X API's are much more difficult to switch between.

One of my biggest fears is that VirtualPC will become fast enough that it will
actually discourage developers from looking at the Mac as a platform. "Just
use VirtualPC" may become a standard Tech Support answer. Don't get me
wrong, I
love VirtualPC (or hopefully VMWare) but I like native apps better.

I don't see dual booting quite as exciting as others. I hate dual booting --
partitioning drives, the reboot time (although exceptionally fast on the Mac
side, the XP side isn't so quick), the workflow disruption, etc....

At 3:06 PM -0700 6/13/05, Hudson Barton wrote:
>I just wonder whether the change of processors makes it easier for
>Windows software to be converted to Mac OS X. Is there any indication

Probably not. In terms of Windows software, most of the work
involved is adapting to the Mac OS X APIs, and the choice of
processor has nothing to do with this. Programs that rely on Unix
APIs and have no GUI should already be portable to OS X on the Power
PC.

One thing that will be easier is that there won't be any issues of
big-endian vs. little-endian, which would eliminate some potential
bugs. Another is that any applications that have x86-specific
assembly language for performance reasons, should be able to use that
code directly.

--
Larry Rosenstein
lrosensteincatsincharge.com

On 20 Jun 2005, at 16:05 , Larry Rosenstein wrote:
> At 3:06 PM -0700 6/13/05, Hudson Barton wrote:
>
>> I just wonder whether the change of processors makes it easier for
>> Windows software to be converted to Mac OS X. Is there any
>> indication
>
> Probably not.

Yes, but almost certainly you will be able to run most windows
software under OS x 1) without installing Windows 2) at or very near
full speed.

> In terms of Windows software, most of the work
> involved is adapting to the Mac OS X APIs, and the choice of
> processor has nothing to do with this. Programs that rely on Unix
> APIs and have no GUI should already be portable to OS X on the Power
> PC.

Moving to x86 will allow Macs to use WINE to run Windows software.
WINE (Wine is Not an Emulator) is a set of APIs that duplicate the
functionality of the the Windows APIs.

> One thing that will be easier is that there won't be any issues of
> big-endian vs. little-endian,

This is a non-issue for 99.999% of developers, much less users.
Well, maybe 99.9% of developers.

>On 20 Jun 2005, at 16:05 , Larry Rosenstein wrote:
>Moving to x86 will allow Macs to use WINE to run Windows software.
>WINE (Wine is Not an Emulator) is a set of APIs that duplicate the
>functionality of the the Windows APIs.

There's a WINE release under FreeBSD, so perhaps Darwin and the rest
of OS X are not far behind. But that's just a guess.

 From the point of view of both WINE developers and Windows program
developers, what are the most notable waypoints in the WINE
development process that might bring Windows programs to the x86 Mac?
Is it going to be possible for WINE to support any given API that a
Windows program might require?

H.

On 22/6/2005 11:53 PM, "Hudson Barton" <hhbvhighwinds.com> spake thus:

> Is it going to be possible for WINE to support any given API that a
> Windows program might require?

I don't think so. My understanding is that not all Windows software will
work under WINE.

--
Nigel Stanger, Dunedin, NEW ZEALAND.
http://public.xdi.org/=nigel.stanger

Nigel Stanger wrote:

>On 22/6/2005 11:53 PM, "Hudson Barton" <hhbvhighwinds.com> spake thus:
>>>Is it going to be possible for WINE to support any given API that a
>>Windows program might require?
>
>I don't think so. My understanding is that not all Windows software will
>work under WINE.

You're both right. Currently, not all APIs are supported by WINE, but
it is *possible* for WINE to support any given API (although WINE
recently ran in to a patent problem that is preventing them from getting
certain APIs working).

--Chris

Quoting Christopher Smith <xxman.org>:

> Nigel Stanger wrote:
>
>> On 22/6/2005 11:53 PM, "Hudson Barton" <hhbvhighwinds.com> spake thus:
>>>> Is it going to be possible for WINE to support any given API that a
>>> Windows program might require?
>>
>> I don't think so. My understanding is that not all Windows software will
>> work under WINE.
>
> You're both right. Currently, not all APIs are supported by WINE, but
> it is *possible* for WINE to support any given API (although WINE
> recently ran in to a patent problem that is preventing them from getting
> certain APIs working).

There is a database of applications that work under WINE here:
<http://appdb.winehq.org/>

Also WINE maps windows API's to UNIX X API's. That means you'll be running
Windows applications in X in Mac OS X. That does not sound like a good
solution to me. Not to mention that one reason I use a Mac is to get away from the
Windows interface.