SDL 1.2 and OS X 10.6

SDL Development
21

Any idea why I’m getting this?

i686-apple-darwin10-gcc-4.0.1:
/Users/steven/Development/SDL-1.2/Xcode/SDL/…/…/src/video/quartz/SDL_QuartzYUV.m:
No such file or directory
i686-apple-darwin10-gcc-4.0.1: warning: ‘-x objective-c’ after last
input file has no effect
i686-apple-darwin10-gcc-4.0.1: no input files

I removed it from the project and things seem to build fine, so
maybe it was removed from the repository but not the project?

  • StevenOn Sun, Sep 20, 2009 at 11:30 PM, Ryan C. Gordon wrote:

Allen McBride wrote:

Hello from the world of MacPorts users. ?I just saw Ryan Gordon’s ?latest
note at http://bugzilla.libsdl.org/show_bug.cgi?id=581, which ?I take to
mean that this issue may never be fixed. ?On the MacPorts

This fix just hit subversion, and it’s a serious change to the codebase.
PLEASE test the hell out of this. We’d like to know that making SDL 1.2
compatible with 10.6 wasn’t a big mistake at this late stage of the game.

–ryan.

22

Also, I recommend that some settings be changed:

ARCHS = ppc i386 x86_64
GCC_VERSION_x86_64 = 4.2
GCC_VERSION_i386 = 4.0
GCC_VERSION_ppc = 3.3
MACOSX_DEPLOYMENT_TARGET_x86_64 = 10.5
MACOSX_DEPLOYMENT_TARGET_i386 = 10.4
MACOSX_DEPLOYMENT_TARGET_ppc = 10.3
SDKROOT_x86_64 = /Developer/SDKs/MacOSX10.5.sdk
SDKROOT_i386 = /Developer/SDKs/MacOSX10.4u.sdk
SDKROOT_ppc = /Developer/SDKs/MacOSX10.3.9.sdk

It’s going to get hard to build for 10.2 and even 10.3.9 these days.
Xcode 3.2 only comes with the 10.6, 10.5, and 10.4 SDKs. Is it even
possible to do a universal build which includes 10.2? Anyway, at the
very least, these changes would be nice, so that we get 64-bit SDL
builds by default:

ARCHS = ppc i386 x86_64
GCC_VERSION_x86_64 = 4.2
MACOSX_DEPLOYMENT_TARGET_x86_64 = 10.5
SDKROOT_x86_64 = /Developer/SDKs/MacOSX10.5.sdk

I suppose the ARCHS line could contain ppc64, too, but I don’t have a
G5 to do test runs of it.

  • StevenOn Mon, Sep 21, 2009 at 12:10 AM, Steven Noonan <@Steven_Noonan> wrote:

On Sun, Sep 20, 2009 at 11:30 PM, Ryan C. Gordon wrote:

Allen McBride wrote:

Hello from the world of MacPorts users. ?I just saw Ryan Gordon’s ?latest
note at http://bugzilla.libsdl.org/show_bug.cgi?id=581, which ?I take to
mean that this issue may never be fixed. ?On the MacPorts

This fix just hit subversion, and it’s a serious change to the codebase.
PLEASE test the hell out of this. We’d like to know that making SDL 1.2
compatible with 10.6 wasn’t a big mistake at this late stage of the game.

–ryan.

Any idea why I’m getting this?

i686-apple-darwin10-gcc-4.0.1:
/Users/steven/Development/SDL-1.2/Xcode/SDL/…/…/src/video/quartz/SDL_QuartzYUV.m:
No such file or directory
i686-apple-darwin10-gcc-4.0.1: warning: ‘-x objective-c’ after last
input file has no effect
i686-apple-darwin10-gcc-4.0.1: no input files

I removed it from the project and things seem to build fine, so
maybe it was removed from the repository but not the project?

  • Steven
23

I removed it from the project and things seem to build fine, so
maybe it was removed from the repository but not the project?
Also, I recommend that some settings be changed:

I think Eric is fixing the Xcode projects.

If you build from the configure script, you’ll probably need to rerun
it, so it notices that a source file has been removed.

As for 10.2: I’m not sure the best way to handle it…I guess you’d need
to keep an old Xcode install around to target it, since even without the
Xcode IDE, you’d need gcc-3.3, which is missing in the latest Xcode.

–ryan.

24

I removed it from the project and things seem to build fine, so
maybe it was removed from the repository but not the project?

Also, I recommend that some settings be changed:

I think Eric is fixing the Xcode projects.

Well, I just tried to build an x86_64/ppc/i386 universal. It bombs a
lot less than SDL 1.2.13, but SDL_romaudio is breaking the build. Oh
well, maybe SDL 1.2.15 will have x86_64 support.On Mon, Sep 21, 2009 at 12:37 AM, Ryan C. Gordon wrote:

If you build from the configure script, you’ll probably need to rerun it, so
it notices that a source file has been removed.

As for 10.2: I’m not sure the best way to handle it…I guess you’d need to
keep an old Xcode install around to target it, since even without the Xcode
IDE, you’d need gcc-3.3, which is missing in the latest Xcode.

25

FYI, as we update SDL to work with Mac OS X 10.6, we’re dropping
support for 10.3 and earlier. This is because Apple’s new tools don’t
support those anymore. If you need a version of SDL that works with
the older systems, you can use SDL 1.2.13 or older.

See ya!On Mon, Sep 21, 2009 at 12:37 AM, Ryan C. Gordon wrote:

I removed it from the project and things seem to build fine, so
maybe it was removed from the repository but not the project?

Also, I recommend that some settings be changed:

I think Eric is fixing the Xcode projects.

If you build from the configure script, you’ll probably need to rerun it, so
it notices that a source file has been removed.

As for 10.2: I’m not sure the best way to handle it…I guess you’d need to
keep an old Xcode install around to target it, since even without the Xcode
IDE, you’d need gcc-3.3, which is missing in the latest Xcode.

–ryan.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

26

Don’t worry, we’re getting all this fixed up for the SDL 1.2.14 release. :)On Mon, Sep 21, 2009 at 12:40 AM, Steven Noonan wrote:

On Mon, Sep 21, 2009 at 12:37 AM, Ryan C. Gordon wrote:

I removed it from the project and things seem to build fine, so
maybe it was removed from the repository but not the project?

Also, I recommend that some settings be changed:

I think Eric is fixing the Xcode projects.

Well, I just tried to build an x86_64/ppc/i386 universal. It bombs a
lot less than SDL 1.2.13, but SDL_romaudio is breaking the build. Oh
well, maybe SDL 1.2.15 will have x86_64 support.

If you build from the configure script, you’ll probably need to rerun it, so
it notices that a source file has been removed.

As for 10.2: I’m not sure the best way to handle it…I guess you’d need to
keep an old Xcode install around to target it, since even without the Xcode
IDE, you’d need gcc-3.3, which is missing in the latest Xcode.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

27

Good to hear! I’ve got several projects that are waiting only on SDL
to be able to build for 64-bit on Mac OS X. It’ll be great to finally
be able to do so. :slight_smile:

  • StevenOn Mon, Sep 21, 2009 at 12:42 AM, Sam Lantinga wrote:

Don’t worry, we’re getting all this fixed up for the SDL 1.2.14 release. :slight_smile:

On Mon, Sep 21, 2009 at 12:40 AM, Steven Noonan <@Steven_Noonan> wrote:

On Mon, Sep 21, 2009 at 12:37 AM, Ryan C. Gordon wrote:

I removed it from the project and things seem to build fine, so
maybe it was removed from the repository but not the project?

Also, I recommend that some settings be changed:

I think Eric is fixing the Xcode projects.

Well, I just tried to build an x86_64/ppc/i386 universal. It bombs a
lot less than SDL 1.2.13, but SDL_romaudio is breaking the build. Oh
well, maybe SDL 1.2.15 will have x86_64 support.

If you build from the configure script, you’ll probably need to rerun it, so
it notices that a source file has been removed.

As for 10.2: I’m not sure the best way to handle it…I guess you’d need to
keep an old Xcode install around to target it, since even without the Xcode
IDE, you’d need gcc-3.3, which is missing in the latest Xcode.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
? ? ? ?-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

28

FYI, as we update SDL to work with Mac OS X 10.6, we’re dropping
support for 10.3 and earlier. This is because Apple’s new tools don’t
support those anymore. If you need a version of SDL that works with
the older systems, you can use SDL 1.2.13 or older.

As far as I know projects compiled for 10.4u SDK works also on 10.3.9, at
least if u don’t use 10.4+ specific features in your code.On Mon, Sep 21, 2009 at 9:41 AM, Sam Lantinga wrote:

–
Bye, Gabry

29

I removed it from the project and things seem to build fine, so
maybe it was removed from the repository but not the project?
Also, I recommend that some settings be changed:

I think Eric is fixing the Xcode projects.

Yes, I’m working on them now.

Also, I recommend that some settings be changed:

ARCHS = ppc i386 x86_64
GCC_VERSION_x86_64 = 4.2
GCC_VERSION_i386 = 4.0
GCC_VERSION_ppc = 3.3
MACOSX_DEPLOYMENT_TARGET_x86_64 = 10.5
MACOSX_DEPLOYMENT_TARGET_i386 = 10.4
MACOSX_DEPLOYMENT_TARGET_ppc = 10.3
SDKROOT_x86_64 = /Developer/SDKs/MacOSX10.5.sdk
SDKROOT_i386 = /Developer/SDKs/MacOSX10.4u.sdk
SDKROOT_ppc = /Developer/SDKs/MacOSX10.3.9.sdk

It’s going to get hard to build for 10.2 and even 10.3.9 these days.
Xcode 3.2 only comes with the 10.6, 10.5, and 10.4 SDKs. Is it even
possible to do a universal build which includes 10.2? Anyway, at the
very least, these changes would be nice, so that we get 64-bit SDL
builds by default:

ARCHS = ppc i386 x86_64
GCC_VERSION_x86_64 = 4.2
MACOSX_DEPLOYMENT_TARGET_x86_64 = 10.5
SDKROOT_x86_64 = /Developer/SDKs/MacOSX10.5.sdk

I suppose the ARCHS line could contain ppc64, too, but I don’t have a
G5 to do test runs of it.

So in my tests so far, 64-bit for 10.5 is currently not possible due
to at least one piece of code we use. When trying to build for PowerPC
64-bit for curiosity sake, I encountered an undefined variable:
‘UsrActivity’ in SDL_QuartzEvents.m. This uses something from Apple’s
Power Management headers. In my research, I came across a thread that
said all that functionality was not exposed to 64-bit in Leopard,
meaning you had to wait for Snow Leopard.

So for 64-bit, I think we need to require Snow Leopard as a minimum.

As far as I know projects compiled for 10.4u SDK works also on 10.3.9, at least if u don’t use 10.4+ specific features in your code.

As for this, we could try playing some games with the
-mmacosx-version-min flag and set it to 10.3 while using the 10.4 SDK,
but is it really worth it? Do we have anybody that can do testing for
us?

-EricOn 9/21/09, Ryan C. Gordon wrote:

30

I removed it from the project and things seem to build fine, so
maybe it was removed from the repository but not the project?
Also, I recommend that some settings be changed:

I think Eric is fixing the Xcode projects.

Yes, I’m working on them now.

Also, I recommend that some settings be changed:

ARCHS = ppc i386 x86_64
GCC_VERSION_x86_64 = 4.2
GCC_VERSION_i386 = 4.0
GCC_VERSION_ppc = 3.3
MACOSX_DEPLOYMENT_TARGET_x86_64 = 10.5
MACOSX_DEPLOYMENT_TARGET_i386 = 10.4
MACOSX_DEPLOYMENT_TARGET_ppc = 10.3
SDKROOT_x86_64 = /Developer/SDKs/MacOSX10.5.sdk
SDKROOT_i386 = /Developer/SDKs/MacOSX10.4u.sdk
SDKROOT_ppc = /Developer/SDKs/MacOSX10.3.9.sdk

It’s going to get hard to build for 10.2 and even 10.3.9 these days.
Xcode 3.2 only comes with the 10.6, 10.5, and 10.4 SDKs. Is it even
possible to do a universal build which includes 10.2? Anyway, at the
very least, these changes would be nice, so that we get 64-bit SDL
builds by default:

ARCHS = ppc i386 x86_64
GCC_VERSION_x86_64 = 4.2
MACOSX_DEPLOYMENT_TARGET_x86_64 = 10.5
SDKROOT_x86_64 = /Developer/SDKs/MacOSX10.5.sdk

I suppose the ARCHS line could contain ppc64, too, but I don’t have a
G5 to do test runs of it.

So in my tests so far, 64-bit for 10.5 is currently not possible due
to at least one piece of code we use. When trying to build for PowerPC
64-bit for curiosity sake, I encountered an undefined variable:
‘UsrActivity’ in SDL_QuartzEvents.m. This uses something from Apple’s
Power Management headers. In my research, I came across a thread that
said all that functionality was not exposed to 64-bit in Leopard,
meaning you had to wait for Snow Leopard.

So for 64-bit, I think we need to require Snow Leopard as a minimum.

I wonder how Leopard would handle this. Leopard is capable of
running 64-bit apps even without a 64-bit kerenl, so I’m wondering if
the app would simply bomb if the x86_64 portion was compiled for 10.6
or if it’d try the 10.5 i386 portion if the x86_64 portion has linkage
issues.On Mon, Sep 21, 2009 at 3:52 AM, E. Wing wrote:

On 9/21/09, Ryan C. Gordon wrote:

As far as I know projects compiled for 10.4u SDK works also on 10.3.9, at least if u don’t use 10.4+ specific features in your code.

As for this, we could try playing some games with the
-mmacosx-version-min flag and set it to 10.3 while using the 10.4 SDK,
but is it really worth it? Do we have anybody that can do testing for
us?

-Eric

31

I removed it from the project and things seem to build fine, so
maybe it was removed from the repository but not the project?
Also, I recommend that some settings be changed:

I think Eric is fixing the Xcode projects.

Yes, I’m working on them now.

Also, I recommend that some settings be changed:

ARCHS = ppc i386 x86_64
GCC_VERSION_x86_64 = 4.2
GCC_VERSION_i386 = 4.0
GCC_VERSION_ppc = 3.3
MACOSX_DEPLOYMENT_TARGET_x86_64 = 10.5
MACOSX_DEPLOYMENT_TARGET_i386 = 10.4
MACOSX_DEPLOYMENT_TARGET_ppc = 10.3
SDKROOT_x86_64 = /Developer/SDKs/MacOSX10.5.sdk
SDKROOT_i386 = /Developer/SDKs/MacOSX10.4u.sdk
SDKROOT_ppc = /Developer/SDKs/MacOSX10.3.9.sdk

It’s going to get hard to build for 10.2 and even 10.3.9 these days.
Xcode 3.2 only comes with the 10.6, 10.5, and 10.4 SDKs. Is it even
possible to do a universal build which includes 10.2? Anyway, at the
very least, these changes would be nice, so that we get 64-bit SDL
builds by default:

ARCHS = ppc i386 x86_64
GCC_VERSION_x86_64 = 4.2
MACOSX_DEPLOYMENT_TARGET_x86_64 = 10.5
SDKROOT_x86_64 = /Developer/SDKs/MacOSX10.5.sdk

I suppose the ARCHS line could contain ppc64, too, but I don’t have a
G5 to do test runs of it.

So in my tests so far, 64-bit for 10.5 is currently not possible due
to at least one piece of code we use. When trying to build for PowerPC
64-bit for curiosity sake, I encountered an undefined variable:
‘UsrActivity’ in SDL_QuartzEvents.m. This uses something from Apple’s
Power Management headers. In my research, I came across a thread that
said all that functionality was not exposed to 64-bit in Leopard,
meaning you had to wait for Snow Leopard.

So for 64-bit, I think we need to require Snow Leopard as a minimum.

I wonder how Leopard would handle this. Leopard is capable of
running 64-bit apps even without a 64-bit kerenl, so I’m wondering if
the app would simply bomb if the x86_64 portion was compiled for 10.6
or if it’d try the 10.5 i386 portion if the x86_64 portion has linkage
issues.

Good lord, that was convoluted. I’m going to bed.On Mon, Sep 21, 2009 at 4:06 AM, Steven Noonan <@Steven_Noonan> wrote:

On Mon, Sep 21, 2009 at 3:52 AM, E. Wing wrote:

On 9/21/09, Ryan C. Gordon wrote:

As far as I know projects compiled for 10.4u SDK works also on 10.3.9, at least if u don’t use 10.4+ specific features in your code.

As for this, we could try playing some games with the
-mmacosx-version-min flag and set it to 10.3 while using the 10.4 SDK,
but is it really worth it? Do we have anybody that can do testing for
us?

-Eric

32

So for 64-bit, I think we need to require Snow Leopard as a minimum.

I wonder how Leopard would handle this. Leopard is capable of
running 64-bit apps even without a 64-bit kerenl, so I’m wondering if
the app would simply bomb if the x86_64 portion was compiled for 10.6
or if it’d try the 10.5 i386 portion if the x86_64 portion has linkage
issues.

Yes, I had the same thought. I don’t have a 64-bit intel mac with
Leopard on it so I built Sam a test program which he will test
tomorrow.

I have heard of this case before between 10.4 and 10.5, so I think
there is a way to deal with this case if the default doesn’t do what
you want. I think it may involve setting a LaunchServices key in the
Info.plist. I need to sift through the mailing list archives if this
becomes an issue.

Another convoluted thought: Should we be compiling the SDL frameworks
in dual mode (garbage collection/non-garbage collection) so if
somebody wanted to link against SDL in an app they were utilizing
garbage collection elsewhere in, they could do so? Obviously, it will
be up to the end user to understand that they must manually manage SDL
memory regardless. And I don’t even know if SDL actually will compiled
in gc mode.

-Eric

33

As far as I know projects compiled for 10.4u SDK works also on 10.3.9,
at least if u don’t use 10.4+ specific features in your code.

As for this, we could try playing some games with the
-mmacosx-version-min flag and set it to 10.3 while using the 10.4 SDK,
but is it really worth it? Do we have anybody that can do testing for
us?

I know of several Aleph One users who still run 10.3.9, and it would be
nice to continue to ship a single build supporting as many versions of Mac
OS X as possible. We plan to use the same trick, of setting the min
version to 10.3 and compiling against the 10.4 SDK.

Unfortunately, the only testing I can offer in the near future is to try
to send a build to a user I know is running 10.3.9 just to make sure it
works.

GregoryOn Mon, 21 Sep 2009, E. Wing wrote:

34

I just remembered, we are switching SDL_image over to the ImageIO
backend. These functions do require 10.4. ImageIO has a bunch of
advantages for us including reduced binary size (about 10x), much
easier build process to maintain (don’t have to maintain separate 3rd
party binaries and build systems), and support for more image formats.

Setting the -mmacosx-version-min flag to 10.3 in this case allowed the
library to dutifully build but we got no compiler warnings about the
fact that this code wasn’t going to work. I’m worried that if any 10.4
functions do into the SDL core, we won’t know about it if we set this
flag. It seems like we’re asking for trouble here.

-EricOn 9/21/09, Gregory Smith wrote:

On Mon, 21 Sep 2009, E. Wing wrote:

As far as I know projects compiled for 10.4u SDK works also on 10.3.9,
at least if u don’t use 10.4+ specific features in your code.

As for this, we could try playing some games with the
-mmacosx-version-min flag and set it to 10.3 while using the 10.4 SDK,
but is it really worth it? Do we have anybody that can do testing for
us?

I know of several Aleph One users who still run 10.3.9, and it would be
nice to continue to ship a single build supporting as many versions of Mac
OS X as possible. We plan to use the same trick, of setting the min
version to 10.3 and compiling against the 10.4 SDK.

Unfortunately, the only testing I can offer in the near future is to try
to send a build to a user I know is running 10.3.9 just to make sure it
works.

35

There’s a new Xcode project file checked in for SDL 1.2.On Mon, Sep 21, 2009 at 6:04 PM, E. Wing wrote:

On 9/21/09, Gregory Smith wrote:

On Mon, 21 Sep 2009, E. Wing wrote:

As far as I know projects compiled for 10.4u SDK works also on 10.3.9,
at least if u don’t use 10.4+ specific features in your code.

As for this, we could try playing some games with the
-mmacosx-version-min flag and set it to 10.3 while using the 10.4 SDK,
but is it really worth it? Do we have anybody that can do testing for
us?

I know of several Aleph One users who still run 10.3.9, and it would be
nice to continue to ship a single build supporting as many versions of Mac
OS X as possible. We plan to use the same trick, of setting the min
version to 10.3 and compiling against the 10.4 SDK.

Unfortunately, the only testing I can offer in the near future is to try
to send a build to a user I know is running 10.3.9 just to make sure it
works.

I just remembered, we are switching SDL_image over to the ImageIO
backend. These functions do require 10.4. ImageIO has a bunch of
advantages for us including reduced binary size (about 10x), much
easier build process to maintain (don’t have to maintain separate 3rd
party binaries and build systems), and support for more image formats.

Setting the -mmacosx-version-min flag to 10.3 in this case allowed the
library to dutifully build but we got no compiler warnings about the
fact that this code wasn’t going to work. I’m worried that if any 10.4
functions do into the SDL core, we won’t know about it if we set this
flag. It seems like we’re asking for trouble here.

-Eric

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

36

I just remembered, we are switching SDL_image over to the ImageIO
backend. These functions do require 10.4. ImageIO has a bunch of
advantages for us including reduced binary size (about 10x), much
easier build process to maintain (don’t have to maintain separate 3rd
party binaries and build systems), and support for more image formats.

There are a lot of things where I’ve given up on OS version
concerns…if it’s an Intel build, do the smart thing, if it’s PowerPC,
use the old and crusty path. It seems to work well enough in most cases,
mostly because 10.4 had most of the good APIs we care about so all Intel
boxes can use them, and 10.6 cut off PowerPC support and most of the
crusty APIs, so we can stop caring about them.

YMMV. I’m at the point where keeping a known-good binary of SDL 1.2 that
works back to 10.2 around makes sense, and never ever compile it for
PowerPC again…and just use lipo to glue it to the latest and greatest
Intel binary. :slight_smile:

I am 90% to the point where if you have a PowerPC system, tough luck.
But that’s just me. :slight_smile:

–ryan.

37

Ryan C. Gordon wrote:

I am 90% to the point where if you have a PowerPC system, tough luck.
But that’s just me. :slight_smile:

I really hate this attitude. I try to write platform independent code,
which to me means “all past and future platforms”, not “whatever is
common now, but don’t expect it to work five years from now”. I have a
PowerPC MacMini, it works well enough for all I use it for, and I resent
the idea that I have to upgrade just for software version compatibility.

(This isn’t direct at you personally. It’s entirely Apple’s fault that
backwards compatibility is such a pain in the ass on Macs.)–
Rainer Deyke - rainerd at eldwood.com

38

Hear hear.

-bill!On Tue, Sep 22, 2009 at 04:34:55PM -0600, Rainer Deyke wrote:

(This isn’t direct at you personally. It’s entirely Apple’s fault that
backwards compatibility is such a pain in the ass on Macs.)

39

2009/9/22 Bill Kendrick :> On Tue, Sep 22, 2009 at 04:34:55PM -0600, Rainer Deyke wrote:

(This isn’t direct at you personally. ?It’s entirely Apple’s fault that
backwards compatibility is such a pain in the ass on Macs.)

Hear hear.

Backwards compatibility is a pain in the ass everywhere. Imagine how
much simpler newer processors would be if they didn’t need to be
backwards compatible with the 8086. There is something to be said for
throwing it all out and starting from scratch with the knowledge we’ve
gained.

40

Kenneth Bull wrote:

2009/9/22 Bill Kendrick :

(This isn’t direct at you personally. It’s entirely Apple’s fault that
backwards compatibility is such a pain in the ass on Macs.)
Hear hear.

Backwards compatibility is a pain in the ass everywhere. Imagine how
much simpler newer processors would be if they didn’t need to be
backwards compatible with the 8086. There is something to be said for
throwing it all out and starting from scratch with the knowledge we’ve
gained.

Whatever happened to all those processor architectures that were
supposed to replace x86? Oh, that’s right, they where replaced by x86
instead.

Compatibility (whether forward, backwards, or sidewards) is the single
most important feature of any computing platform. Otherwise you will
force everyone who uses that platform to continually reinvent the wheel.

If the old architecture is really completely broken, here’s what you do:

  • Design the new architecture for total forward compatibility from the
    start. Don’t repeat the mistakes that forced you to drop the old
    architecture.
  • Stick with your new architecture.
  • Create a compatibility layer that works, and maintain it forever.
    Apple hasn’t done any of those things.>> On Tue, Sep 22, 2009 at 04:34:55PM -0600, Rainer Deyke wrote:

–
Rainer Deyke - rainerd at eldwood.com