[Big Mac]

This seems like a case in which Apple removed a capability on Macs that supported it just for the sake of doing so, and that's just wrong. If, on the other hand, Apple made architectural changes to Leopard's core that caused Classic to break and which would have required non-trivial modification to Classic in order to get it working again, then I could accept its removal. I just don't see that as being the case, but I could be wrong.

[CharlesS]

Originally Posted by SirCastor 

On the plus side of all that, there are a few groups which produce PPC and 68K emulators which should (theoretically) serve purposes of folks who need to run legacy OSs

There's only one such emulator that can emulate a PPC and run OS 9 on it, and that's SheepShaver, which sucks. It crashes or locks up every five minutes.

[Big Mac]

Hey Charles, I just figured out another reason to reject the notion of built-in PPC emulation on Mactels. Intel processors are register starved unless they're run in 64-bit mode, and for a while there were no 64-bit Mactels available. There's no way to run good performance emulation of a register rich processor on a register starved processor.

On a related tangent. . . . . . . . . . x86 suxx0rs, Intel can bite me, I hate the Intel defection, Apple sold us out, I despise Mactels, PPC4EVER, PPCRULES, etc., etc. Now that felt good to write.

[SirCastor]

Originally Posted by Big Mac 

This seems like a case in which Apple removed a capability on Macs that supported it just for the sake of doing so, and that's just wrong. If, on the other hand, Apple made architectural changes to Leopard's core that caused Classic to break and which would have required non-trivial modification to Classic in order to get it working again, then I could accept its removal. I just don't see that as being the case, but I could be wrong.

It's probably a matter of Quality control more than anything. In terms of economics, they likely don't have a significant percentage of users using classic to warrant the extra effort. If it were flat out perfect then it wouldn't have hurt to leave it in, but it does cost them money for QA, revision, and more QA, and it probably made more sense to drop as their current machines can't run it anyway.

As much as I don't like it, Apple looks at it's older machines as minor annoyances. Their interested in selling Leopard to their current machine's customers, and that's where it's going to perform. Apple doesn't care if Leopard will run on my souped-up G4, because they're way beyond that. They want me to buy a new machine to get leopard.

[CharlesS]

Originally Posted by Big Mac 

Hey Charles, I just figured out another reason to reject the notion of built-in PPC emulation on Mactels. Intel processors are register starved unless they're run in 64-bit mode, and for a while there were no 64-bit Mactels available. There's no way to run good performance emulation of a register rich processor on a registered starved processor.

SheepShaver's performance is fine. It's just the fact that it crashes all the time that makes it suck (well, and the fact that it doesn't work with Mac OS 9.1 and up).

[ebah]

Well - If I can't run hypercard - anyone know of a leopard compatible app that will easily run hypercard stacks?
Thanks

[Big Mac]

Some links from Gooooooogle:

HyperCard Stacks Native on OS X: Hail the Revolution!

Alternatives to HyperCard

Converting Stacks to MetaCard - Intro

[TETENAL]

Originally Posted by Big Mac 

Hey Charles, I just figured out another reason to reject the notion of built-in PPC emulation on Mactels. Intel processors are register starved unless they're run in 64-bit mode, and for a while there were no 64-bit Mactels available. There's no way to run good performance emulation of a register rich processor on a register starved processor.

Then why does Rosetta work?

[Big Mac]

Originally Posted by TETENAL 

Then why does Rosetta work?

Rosetta is more than just emulation, it's dynamic recompilation, and in addition, Rosetta is only dealing with native OS X applications. Apple has said there are far too many technical hurdles to getting Rosetta technology to work below the application layer.

Aside from Charles' post, every other comment about Sheepshaver Intel says it's very slow, and I think I hit on the reason why.

[CharlesS]

Originally Posted by Big Mac 

Aside from Charles' post, every other comment about Sheepshaver Intel says it's very slow, and I think I hit on the reason why.

Because it's emulation?

Here's a hint: how fast is Virtual PC running on PPC?

SheepShaver isn't as fast as running the apps natively on a PPC processor, obviously. But it's usable, or at least it would be if it didn't crash so much.

[Chuckit]

Originally Posted by Big Mac 

Hey Charles, I just figured out another reason to reject the notion of built-in PPC emulation on Mactels. Intel processors are register starved unless they're run in 64-bit mode, and for a while there were no 64-bit Mactels available. There's no way to run good performance emulation of a register rich processor on a register starved processor.

"Good" is relative. Considering the systems these programs were originally written for, the performance should be sufficient.

[Pierre B.]

Originally Posted by Chuckit 

…but somehow in your mind this means that resolution independence is not coming? This is like a logical leap into a black hole. Seriously, I'm not following at all.

You should though. Apple has a precedent in this, making people here and elsewhere suspicious.

[.Neo]

Originally Posted by - - e r i k - - 

There's just no way the end user will see RI in Leopard at this pace. Apple has the technology, but isn't even utilising it in their core apps making for a very poor example for third party developers.

Yet, most of Mac OS X Leopard's resources are already vector rather than raster based.

[Eug]

Originally Posted by .Neo 

Yet, most of Mac OS X Leopard's resources are already vector rather than raster based.

Interesting. What parts? Was any of this present in Tiger? (Sorry for the n00b questions.)

Has anyone done speed comparisons using different GPUs?

[.Neo]

Originally Posted by Eug 

Interesting. What parts? Was any of this present in Tiger? (Sorry for the n00b questions.)

Has anyone done speed comparisons using different GPUs?

Most of the Aqua resources (scroll bars, buttons, min/max/close buttons etc.) are present as scalable PDF files. In Mac OS X 10.4 Tiger they're all .tiff files.

[Eug]

Originally Posted by .Neo 

Most of the Aqua resources (scroll bars, buttons, min/max/close buttons etc.) are present as scalable PDF files. In Mac OS X 10.4 Tiger they're all .tiff files.

Cool. My 7600GT should help to speed things up nicely.

It's disappointing that the apps themselves aren't RI though. One step at a time I suppose...

I wonder how much CPU-juice this will suck up on my MacBook though, considering it's GMA 950. Mind you, considering it's only a portion of the Aqua stuff, my guess is it will be quite OK with any dual-CPU or dual-core Intel or G5 machine.

[TheoCryst]

Well if that's true, it makes sense why they had to pull the plug on G3s and older G4s. They just don't have the power for that type of work.

My guess? RI in either 10.5.2/3, or 10.6.

[.Neo]

Native transparent PDF support is already part of the core since Mac OS X' initial release, further supporting frameworks for an resolution independent UI came with Mac OS X 10.4 Tiger and Mac OS X 10.5 Leopard offers the actual scalable PDF Aqua elements. It strikes me as weird that Apple didn't finish the proper algorithms to stick the whole thing together as one coherent part.

[Horsepoo!!!]

Originally Posted by .Neo 

Most of the Aqua resources (scroll bars, buttons, min/max/close buttons etc.) are present as scalable PDF files. In Mac OS X 10.4 Tiger they're all .tiff files.

Yes...they've been this way for a long time. Who cares if the apps themselves still have their Tiger resolution .tiffs? Unless Apple pulls a horseshoe out of its butt, around 90% of the apps that will ship in 10.5.0 will be far from being RI-ready with the exception of iChat and Font Book which seem to have all their .tiffs ready for 288dpi resolutions.

But who knows...maybe Apple's been sitting on 288dpi .tiffs for all their apps for a long time but haven't put them into any of the builds...you never know with Apple or Steve Jobs...because Steve is a chronic liar and Apple has unpredictable quality problem spikes.

Anyway, I don't give a ****. I don't own a high pixel-density monitor nor do I own a MacBook Pro with a higher pixel-density monitor...and I won't for a while. But it's unacceptable that a publicly announced feature seems so far from being ready in the final builds. Imagine the outcry if Apple pulled a feature that was closer to public interest...like say, Time Machine. There'd be riots everywhere...it would be the end of the frickin' world. Ok...maybe not but, still, I don't think it's right that Apple is putting less effort in RI with the thought that it'll go unnoticed because most people wouldn't care since they most likely have no clue what RI is or what it can do for them.

Also...the longer MS and Apple sit on RI, the longer high density screens will remain niche and the longer they'll remain expensive. Even though I don't want such a monitor now, it doesn't mean I want to wait 5 years for them to become inexpensive.

[mdc]

That RI screenshot a few pages back. What app would someone use to make a window/app RI 'zoomed in'?

I read somewhere that Coda is fully Resolution Independant. Could someone try 'zoom in' on that app and see what happens?

[Scarpa]

Sorry for the n00bish question, but even after searching this thread I can't quite get the info I'm looking for.

Is Leopard looking to be released or just announced in late October? I've been hearing something about an announcement in Oct related to the slim-book rumors.

I'm looking to buy a MacBook soon, and am willing to wait until I can get the new OS with it, or at least a free upgrade to it if it's not pre-installed. I'm not in a huge hurry but since making the decision to get a MacBook the impatience is growing. I'm definitely not waiting on any rumors, just the new OS.

[mdc]

Apple said 10.5 would be released in Spring, around June, but then had to delay it to October.
According to reports 10.5 is getting very close to GM (final release that will be duplicated to distrubtion DVDs). I'm assuming in the coming weeks Apple will either have a short annoucement, or have one on their website, stating that 10.5 will be released on October the xxth.

Will there be new hardware released alongside 10.5? No one knows but, like you know, there is a lot of speculation.

[Kevin]

Originally Posted by Horsepoo!!! 

Y
But who knows...maybe Apple's been sitting on 288dpi .tiffs for all their apps for a long time but haven't put them into any of the builds...you never know with Apple or Steve Jobs...because Steve is a chronic liar and Apple has unpredictable quality problem spikes.

You rant alot about something you aren't sure of don't you.

And chronic liar? Is that like a chronic exaggerator?

[Horsepoo!!!]

Originally Posted by Kevin 

You rant alot about something you aren't sure of don't you.

And chronic liar? Is that like a chronic exaggerator?

Yes and yes. Gotta rant before it's released or it'll get released because nobody was ranting about it. Steve lies, exaggerates and breaks promises (and hearts ).

[Kevin]

at that last part.

[- - e r i k - -]

Originally Posted by .Neo 

Yet, most of Mac OS X Leopard's resources are already vector rather than raster based.

Not true at all. Apart from a few buttons, scroll bars, stoplight buttons and text fields most resources are still the old raster ones, like the back and forward buttons. Heck, as I have pointed out several time, even the new web clip button in Safari is a raster image.

[Taylor C]

How is removing support for an OS that's over eight years old, and no longer developed in any shape or form, stupid? :/

[Chuckit]

Originally Posted by Taylor C 

How is removing support for an OS that's over eight years old, and no longer developed in any shape or form, stupid? :/

It's not about removing support for the OS — it's about removing support for thousands of apps.

[goMac]

Originally Posted by Chuckit 

It's not about removing support for the OS — it's about removing support for thousands of apps.

To be fair, these are thousands of apps that very few people run. Classic doesn't even run on the Intels, and it can be pretty flakey on the PPC's.

[Big Mac]

Classic has never given me a problem.

[CharlesS]

Classic works quite a bit better than any other virtual machine of its type that I've used.

[goMac]

Originally Posted by Big Mac 

Classic has never given me a problem.

I've got a decent amount of software that just runs too glitchy under Classic.

[CharlesS]

The great majority of Classic apps I have run just fine in the Classic environment.

100% of the Classic apps I need to work run perfectly in the Classic environment (whereas one of them won't even launch in SheepShaver).

[Chuckit]

Originally Posted by goMac 

I've got a decent amount of software that just runs too glitchy under Classic.

I know a decent amount of software that doesn't run outside of Classic. I think that beats glitchy. (Also, the only software I can recall using that was glitchy in Classic was Quark 5.)

[analogika]

Originally Posted by Chuckit 

I know a decent amount of software that doesn't run outside of Classic. I think that beats glitchy. (Also, the only software I can recall using that was glitchy in Classic was Quark 5.)

VectorWorks, Freehand, anything audio.

[Big Mac]

I don't know about VectorWorks and Freehand, but Audio apps being incompatible with Classic is pretty obvious because audio software is often deeply tied to hardware.

[JLL]

Originally Posted by Horsepoo!!! 

Yes...they've been this way for a long time. Who cares if the apps themselves still have their Tiger resolution .tiffs? Unless Apple pulls a horseshoe out of its butt, around 90% of the apps that will ship in 10.5.0 will be far from being RI-ready with the exception of iChat and Font Book which seem to have all their .tiffs ready for 288dpi resolutions.

But who knows...maybe Apple's been sitting on 288dpi .tiffs for all their apps for a long time but haven't put them into any of the builds...you never know with Apple or Steve Jobs...because Steve is a chronic liar and Apple has unpredictable quality problem spikes.

Anyway, I don't give a ****. I don't own a high pixel-density monitor nor do I own a MacBook Pro with a higher pixel-density monitor...and I won't for a while. But it's unacceptable that a publicly announced feature seems so far from being ready in the final builds.

When did Apple publicly announce that RI would be a feature in 10.5.0?

[Horsepoo!!!]

Originally Posted by JLL 

When did Apple publicly announce that RI would be a feature in 10.5.0?

On their very own website. Sure, Apple put a safeguard with the little warning "All features referenced in the Mac OS X Leopard website are subject to change" at the bottom of each page but does that make it alright? Imagine if 64-bit and CoreAnimation were not ready and had to be removed? Developers would go apeshit. RI affects developers to a lesser degree but I'm sad for those that spent time and money making their app 100%-RI-ready only to be told that it won't be ready...possibly until 10.6. And if you're thinking these guys now have a headstart with their RI-ready graphics, you'd be wrong because apps evolve and I'm quite certain a lot of devs won't be using 2007 graphics made for their Leopard apps in 2009 when Liger comes out (with 200 announced features, 3 TOP SECRET OMG OMG BOOOORING features and, oh wait, 198 features.)

[analogika]

Originally Posted by Horsepoo!!! 

On their very own website.

I don't recall this.

[brokenjago]

Originally Posted by analogika 

I don't recall this.

Neither do I.

[Eug]

Leopard Technology Overview for Developers

Resolution Independence
The old assumption that displays are 72dpi has been rendered obsolete by advances in display technology. Macs now ship with displays that sport native resolutions of 100dpi or better. Furthermore, the number of pixels per inch will continue to increase dramatically over the next few years. This will make displays crisper and smoother, but it also means that interfaces that are pixel-based will shrink to the point of being unusable. The solution is to remove the 72dpi assumption that has been the norm. In Leopard, the system, including the Carbon and Cocoa frameworks, will be able to draw user interface elements using a scale factor. This will let the user interface maintain the same physical size while gaining resolution and crispness from high dpi displays.

The introduction of resolution independence may mean that there is work that you’ll need to do in order to make your application look as good as possible. For modern Cocoa and Carbon applications, most of the work will center around raster-based resources. For older applications that use QuickDraw, more work will be required to replace QuickDraw-based calls with Quartz ones.

Updated: 2006-11-29

Note: These Leopard overview articles show features and interface elements that are pre-release and may change.

[Mac User #001]

Originally Posted by CharlesS 

There's only one such emulator that can emulate a PPC and run OS 9 on it, and that's SheepShaver, which sucks. It crashes or locks up every five minutes.

I might be wrong, but isn't Q (Q - [kju:]) capable of running Mac OS 9? And its available as a Universal Binary.

[CharlesS]

Last time I checked, QEMU wasn't able to run OS 9.

[.Neo]

Originally Posted by - - e r i k - - 

Not true at all. Apart from a few buttons, scroll bars, stoplight buttons and text fields most resources are still the old raster ones, like the back and forward buttons. Heck, as I have pointed out several time, even the new web clip button in Safari is a raster image.

Where are those located? Because Safari 3 doesn't seem to draw it's new styles buttons from the package contents as it still contains the old Safari 2.0 ones. Same goes for Mail, Preview etc.

[Mac User #001]

Originally Posted by CharlesS 

Last time I checked, QEMU wasn't able to run OS 9.

Hmm. It has a tutorial link on how to install Mac OS 9, but the link leads no where.

[CharlesS]

Where did you find that?

The latest mention of support for the classic Mac OS in QEMU that I was able to find was this mailing list post back in May, saying that it's pretty much dead:

Re: [Qemu-devel] Classic Mac OS

edit: and this one from March:

Re: [Qemu-devel] PowerPC: Doesn't boot OS 8.5

[- - e r i k - -]

Originally Posted by .Neo 

Where are those located? Because Safari 3 doesn't seem to draw it's new styles buttons from the package contents as it still contains the old Safari 2.0 ones. Same goes for Mail, Preview etc.

They must have updated lately, seems all of Safari's buttons are now vectors:




However, Mail's are not (though their background is ):


Apple menu is very odd indeed:

but selected:

[Mac User #001]

Originally Posted by CharlesS 

Where did you find that?

The latest mention of support for the classic Mac OS in QEMU that I was able to find was this mailing list post back in May, saying that it's pretty much dead:

Re: [Qemu-devel] Classic Mac OS

edit: and this one from March:

Re: [Qemu-devel] PowerPC: Doesn't boot OS 8.5

[kju:] - Trac

Under "Find help using Q", Tutorials. But, like I said, the link leads no where.

[JLL]

Originally Posted by Eug 

Leopard Technology Overview for Developers

Resolution Independence
The old assumption that displays are 72dpi has been rendered obsolete by advances in display technology. Macs now ship with displays that sport native resolutions of 100dpi or better. Furthermore, the number of pixels per inch will continue to increase dramatically over the next few years. This will make displays crisper and smoother, but it also means that interfaces that are pixel-based will shrink to the point of being unusable. The solution is to remove the 72dpi assumption that has been the norm. In Leopard, the system, including the Carbon and Cocoa frameworks, will be able to draw user interface elements using a scale factor. This will let the user interface maintain the same physical size while gaining resolution and crispness from high dpi displays.

The introduction of resolution independence may mean that there is work that you’ll need to do in order to make your application look as good as possible. For modern Cocoa and Carbon applications, most of the work will center around raster-based resources. For older applications that use QuickDraw, more work will be required to replace QuickDraw-based calls with Quartz ones.

Updated: 2006-11-29

Note: These Leopard overview articles show features and interface elements that are pre-release and may change.

Nothing about 10.5.0 there, and please remember that three months earlier at WWDC06 Apple said that developers had until the end of 2008 to get ready.

[.Neo]

double post