Hej,
We will provide Universal Binaries, or at least native versions, of
our applications for the new i386 machines. We would at the same time
like to ensure that no customer of ours can run an old ppc binary on
i386 by accident.
app is huge and complex, and initial testing indicates that it
doesn't work 100% K in Rosetta. We don't want to spend any resources
in making it work in Rosetta, or dealing with bug reports from
customers using it in Rosetta.
Is there a way to easily prevent an application from running in
Rosetta? It seems to me that there should be an Info.plist key to
control this, but I can't find it. There is a key to make an app run
in Rosetta (LSPrefersPPC ), but the inverse functionality seems to be
missing.
I would love to NT have to implement some sort of runtime hack fo
ensure this, but if that's the only way to do it, I will - and in
that case I would appreciate suggestions / sample code if you've
tried this already.
Thanx,
j o a r
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com
This email sent to bsdarchive (AT) developershed (DOT) com

27.12.2005, at 13:22, j o a r wrote:

Hej,

We will provide Universal Binaries, or at least native versions, of
our applications for the new i386 machines. We would at the same
time like to ensure that no customer of ours can run an old ppc
binary on i386 by accident.
We don't want to spend any resources in making it work in
Rosetta, or dealing with bug reports from customers using it in
Rosetta.

Is there a way to easily prevent an application from running in
Rosetta?

First of all, this sounds like a feature request. I can completely
agree that I do not want bug reports from people running a perfectly
good i386 binary in Rosetta.

And just to broaden my mind a little: Why, other than for testing
purposes, would anyone want to run an i386 binary in Rosetta?

Alex

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

You can't run an i386 binary in Rosetta. Rosetta is a ppc emulator.
- Steve

Dec 27, 2005, at 4:34am, Alexander von Below wrote:

27.12.2005, at 13:22, j o a r wrote:
>
>Hej,
>>
>We will provide Universal Binaries, or at least native versions,
>of our applications for the new i386 machines. We would at the
>same time like to ensure that no customer of ours can run an old
>ppc binary on i386 by accident.
>We don't want to spend any resources in making it work in
>Rosetta, or dealing with bug reports from customers using it in
>Rosetta.
>>
>Is there a way to easily prevent an application from running in
>Rosetta?
>
First of all, this sounds like a feature request. I can completely
agree that I do not want bug reports from people running a
perfectly good i386 binary in Rosetta.

And just to broaden my mind a little: Why, other than for testing
purposes, would anyone want to run an i386 binary in Rosetta?

Alex

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%
40opencommunity.co.uk

This email sent to steve (AT) opencommunity (DOT) co.uk

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

27 dec 2005, at 13.34, Alexander von Below wrote:

First of all, this sounds like a feature request. I can completely
agree that I do not want bug reports from people running a
perfectly good i386 binary in Rosetta.

And just to broaden my mind a little: Why, other than for testing
purposes, would anyone want to run an i386 binary in Rosetta?

My problem is not that I'm afraid that they will run i386 binaries in
Rosetta on i386 machines (I don't think that's possible).

I will try to explain better: We currently have a lot of customers
with ppc machines, and ppc binaries. Sometime next year they might
start buying i386 machines. their LAN they will now have a mix of
ppc and i386 machines, and possibly a mix of ppc and UB/native
versions of our applications.

What I want to avoid is that a user with a i386 machine will launch
one of our old ppc applications. We will make either UB or native
applications available, and I would like to be able to prevent these
users from running one of the old ppc builds.

j o a r

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

27.12.2005, at 13:42, Steve Palmer wrote:

You can't run an i386 binary in Rosetta. Rosetta is a ppc emulator.

I should have been clearer: Why would anyone want to run a universal
binary in Rosetta on an i386 machine?

And this is not only possible, but "You can force applications that
have a universal binary to launch as a PowerPC binary on an Intel-
based Macintosh":

chapter_7_section_5.html

But now that Joar explained a bit better, I see that his problem is a
different one, and unfortunately I have nothing to say to his issue :(

Alex

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

I think even if it is possible, it is a little bit futile. Let us
imagine that you figure out how to prevent PPC executable from
running in Rosetta, most likely it will require some changes to such
executable (even if just some modifications in Info.plist file). It
will be possible to produce NEW version of PPC application which will
contain the changes, but you will not be able to implement this
changes in copies of your application which ALREADY DEPLYED at
customer site.

Dec 27, 2005, at 7:44 AM, j o a r wrote:

27 dec 2005, at 13.34, Alexander von Below wrote:
>
>First of all, this sounds like a feature request. I can completely
>agree that I do not want bug reports from people running a
>perfectly good i386 binary in Rosetta.
>>
>And just to broaden my mind a little: Why, other than for testing
>purposes, would anyone want to run an i386 binary in Rosetta?
>
My problem is not that I'm afraid that they will run i386 binaries
in Rosetta on i386 machines (I don't think that's possible).

I will try to explain better: We currently have a lot of customers
with ppc machines, and ppc binaries. Sometime next year they might
start buying i386 machines. their LAN they will now have a mix
of ppc and i386 machines, and possibly a mix of ppc and UB/native
versions of our applications.

What I want to avoid is that a user with a i386 machine will launch
one of our old ppc applications. We will make either UB or native
applications available, and I would like to be able to prevent
these users from running one of the old ppc builds.

j o a r
--

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40tchijov.com

This email sent to andrei (AT) tchijov (DOT) com

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

27 dec 2005, at 13.59, Andrei Tchijov wrote:

I think even if it is possible, it is a little bit futile. Let us
imagine that you figure out how to prevent PPC executable from
running in Rosetta, most likely it will require some changes to
such executable (even if just some modifications in Info.plist
file). It will be possible to produce NEW version of PPC
application which will contain the changes, but you will not be
able to implement this changes in copies of your application which
ALREADY DEPLYED at customer site.

I understand this, but time is still on our side. We roll out new
versions to our customers on a regular basis, so there is a good
chance that they would have "fixed" ppc applications when they
purchase their first i386 machines.

j o a r

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

In this case, why you do not want to start distribute Universal
Binaries right now?

Dec 27, 2005, at 8:04 AM, j o a r wrote:

27 dec 2005, at 13.59, Andrei Tchijov wrote:
>
>I think even if it is possible, it is a little bit futile. Let us
>imagine that you figure out how to prevent PPC executable from
>running in Rosetta, most likely it will require some changes to
>such executable (even if just some modifications in Info.plist
>file). It will be possible to produce NEW version of PPC
>application which will contain the changes, but you will not be
>able to implement this changes in copies of your application which
>ALREADY DEPLYED at customer site.
>
I understand this, but time is still on our side. We roll out new
versions to our customers on a regular basis, so there is a good
chance that they would have "fixed" ppc applications when they
purchase their first i386 machines.

j o a r
--

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

27 Dec 2005, at 14:04, j o a r wrote:

27 dec 2005, at 13.59, Andrei Tchijov wrote:
>
>I think even if it is possible, it is a little bit futile. Let us
>imagine that you figure out how to prevent PPC executable from
>running in Rosetta, most likely it will require some changes to such
>executable (even if just some modifications in Info.plist file). It
>will be possible to produce NEW version of PPC application which will
>contain the changes, but you will not be able to implement this
>changes in copies of your application which ALREADY DEPLYED at
>customer site.
>
I understand this, but time is still on our side. We roll out new
versions to our customers on a regular basis, so there is a good
chance that they would have "fixed" ppc applications when they
purchase their first i386 machines.

Maybe the easiest solution is to check for the CPU type in your PPC
code (either with mach API or sysctl hw.cputype). If it does not look
like a PowerPC, then quits with a nice warning message. you could
use the hw.byteorder sysctl.

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

27 dec 2005, at 14.13, Andrei Tchijov wrote:
In this case, why you do not want to start distribute Universal
Binaries right now?

Because they're not ready.

27 dec 2005, at 14.16, Stephane Sudre wrote:
Maybe the easiest solution is to check for the CPU type in your PPC
code (either with mach API or sysctl hw.cputype). If it does not
look like a PowerPC, then quits with a nice warning message. you
could use the hw.byteorder sysctl.

That was my fallback solution. It seems that it will also have to be
the actual solution <sigh>

j o a r

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Hello,

Am 27.12.2005 um 15:16 schrieb Stephane Sudre:

Maybe the easiest solution is to check for the CPU type in your PPC
code (either with mach API or sysctl hw.cputype). If it does not
look like a PowerPC, then quits with a nice warning message. you
could use the hw.byteorder sysctl.

I didn't test yet by myself, but seem to remember others stating that
a program run in Rosetta will see the PPC as its host's architecture.

In case I'm wrong, good for you ;-)

In case I'm right, I just thought about another solution which should
work more reliably -- although I'm not sure how the program's
behaviour will look like in reality:
within your bundled appplication's ressources, you could provide a
minimal DLL which you would try to load at runtime. Depending on the
DLL's architecture and the environment (PPC / Rosetta, or i386) this
will fail or succeed.

Best regards,
Dirk Stegemann,
Syncrosoft Development

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:

dirk.stegemann.lists%40macinsight.de

This email sent to dirk.stegemann.lists (AT) macinsight (DOT) de

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

27 dec 2005, at 18.21, Rosyna wrote:

Aren't these both problems on your end? If they don't work in
Rosetta because an API changed, then file a bug on Rosetta. If they
don't work because of a bug in your code, fix the bug. Don't just
go an disable your app based on the return value of kern_sysctl's
KERN_CLASSIC (44) or sysctlbynames's return of "hw.optional.mmx" as
that's just placing the blame somewhere else and doesn't do
anything to help the other developers with this problem (APIs not
working in Rosetta).

The end users would not be happy if many apps do this (say, to
force an upgrade charge) and apple would not be happy if you
needlessly blame them for bugs in your code.

You talk a lot about blame, while I couldn't care less. I just want
to provide our users with the best experience, while at the same time
allowing us to spend our resources where they make sense.

We will provide UB apps, but I fear that there will be a period in
time when we have ppc binaries in the wild together with i386
machines. Rosetta is a new platform, quite comparable to the other
S / hardware platforms that we support. Each platform that we claim
to support needs to be tested. Testing requires resources. I don't
know about you, but we have limited resources, and think it would be
insane to spend them on supporting Rosetta when our goal is to
provide UB at day one. Even if Rosetta would provide flawless
emulation, it still wouldn't cut it for our application - as our
performance requirements are too high.

I'm just looking for a transition fix, and an Info.plist key to
control this behaviour would in my opinion be perfect. A small
runtime check would be unfortunate, but acceptable.

I'm a very much for reporting problems via Radar - but just like
Apple employees on this list have no obligation to answer questions,
I have no obligation to file bug reports. I'm absolutely certain that
I could spend 100% of my time filing bug reports, and following up on
the feedback I get back from Apple - but I'm equally sure that my
employeer wouldn't like that. You need to find the right balance
between spending time on influencing Apple to fix the problems that
matters to you, while on the other hand still spending some time
doing your job. Rosetta is transition technology that we won't use
for our application, so I will not spend time trying to make it
better. At least not while I'm at the office - I'm such a Mac fan-boy
I might still do it in my free time ;-)

j o a r

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Dec 27, 2005, at 12:21 PM, Rosyna wrote:

The end users would not be happy if many apps do this (say, to
force an upgrade charge) and

that's not what he's requesting.

they'll provide Universal binaries, but don't want to support non-UB
code running on new machines. that does seem sensible if the app is,
say, in a vertical market.

apple would not be happy if you needlessly blame them for bugs in
your code.

don't anthropomorphize Apple, it hates when you do that.

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Dec 27, 2005, at 3:45 PM, j o a r wrote:

We will provide UB apps, but I fear that there will be a period in
time when we have ppc binaries in the wild together with i386
machines. Rosetta is a new platform, quite comparable to the other
S / hardware platforms that we support. Each platform that we
claim to support needs to be tested. Testing requires resources. I
don't know about you, but we have limited resources, and think it
would be insane to spend them on supporting Rosetta when our goal
is to provide UB at day one. Even if Rosetta would provide flawless
emulation, it still wouldn't cut it for our application - as our
performance requirements are too high.

I will also be in a similar situation. My existing flagship app is
Carbon (PPC). The new Cocoa version will be a univ binary. However,
some of my users will probably just want to keep the original Carbon
version (the Cocoa one will be a paid upgrade). In that case, I have
one of two choices:

(a) Do nothing to the app and just document on my web site that
running the app via Rosetta may not work correctly. While this does
seem harsh towards users, these are users that did spend money on new
hardware, yet no money on updating their apps. You can't make money
from such customers :)

(b) Qualify the app to run via Rosetta.

As with you, (b) is not an option for me. And although a Info.plist
key would be cool, that would still require users of the older PPC
software to "update" to get the plist modification. Users could
still run the original unmodified PPC app on an Intel Mac. So, I
think option (a) would make the most sense.

I'm a very much for reporting problems via Radar - but just like
Apple employees on this list have no obligation to answer
questions, I have no obligation to file bug reports. I'm absolutely
certain that I could spend 100% of my time filing bug reports, and
following up on the feedback I get back from Apple - but I'm
equally sure that my employeer wouldn't like that. You need to find
the right balance between spending time on influencing Apple to fix
the problems that matters to you, while on the other hand still
spending some time doing your job. Rosetta is transition technology
that we won't use for our application, so I will not spend time
trying to make it better. At least not while I'm at the office -
I'm such a Mac fan-boy I might still do it in my free time ;-)

I would file the enhancement anyhow. While it may be the case where
you may not end up taking advantage of such a solution, it may help
others.

Ricky A. Sharp mailto:rsharp (AT) instantinteractive (DOT) com
Instant Interactive(tm)

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Am 27.12.2005 um 18:21 schrieb Rosyna:
Ack, at 12/27/05, j o a r said:
>
>app is huge and complex, and initial testing indicates that it
>doesn't work 100% K in Rosetta. We don't want to spend any
>resources in making it work in Rosetta, or dealing with bug
>reports from customers using it in Rosetta.
>
Aren't these both problems on your end? If they don't work in
Rosetta because an API changed, then file a bug on Rosetta. If they
don't work because of a bug in your code, fix the bug. Don't just
go an disable your app based on the return value of kern_sysctl's
KERN_CLASSIC (44) or sysctlbynames's return of "hw.optional.mmx" as
that's just placing the blame somewhere else and doesn't do
anything to help the other developers with this problem (APIs not
working in Rosetta).

Joar,

as a service to your users, I'd also suggest not preventing your
users from running an app in Rosetta. Rather, warn them and tell them
there isn't any support for what they're doing and that certain parts
won't work, and maybe replace any "file a bug report" dialogs with
warning messages that simply say something similar.

There may be users whose Mac broke down and to whom the buggy
version under Rosetta of your app will be completely sufficient to
quickly run on a friend's Intel Mac, and you don't want to annoy
them. Remember: It's the user's data, and probably the user's income
that depends on working applications. Your primary interest should be
to make sure that works. Don't be overly protective.

It's either this, or imagining Phil Schiller in a thong.

Rosyna, could you please change your sig? I really didn't need *that*
image in my head :-)

Cheers,
-- M. Uli Kusterer
http://www.zathras.de

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Am 27.12.2005 um 22:45 schrieb j o a r:

I just want to provide our users with the best experience,

While it is indeed a bad idea to prevent users from doing what they
want, you can start providing Universal Binaries, now. Let the ppc
part as is, #ifdef most of the i386 part out and replace it with a
description about what's going on. Merging two different apps with
lipo should work as well.

You'll get "This app doesn't work on Intel Macs"-type reports then,
of course.

Markus
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. Markus Hitter
http://www.jump-ing.de/

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Tuesday, December 27, 2005, at 07:05PM, Uli Kusterer <kusterer (AT) gmail (DOT) comwrote:

as a service to your users, I'd also suggest not preventing your
>users from running an app in Rosetta. Rather, warn them and tell them
>there isn't any support for what they're doing and that certain parts
>won't work, and maybe replace any "file a bug report" dialogs with
>warning messages that simply say something similar.

You can't really say that, not knowing anything about the app or
the customer base.

If it's an application for planning radiological treatments and
calculating radiation doses and beam angles, do you really
want customers putting it on a configuration that "kinda" works,
but might fail in unknown ways?

No, you certainly don't, no matter how convenient it might be for
them.

(I don't know what joar works on, but there was a company which
used S X for precisely this kind of software.)

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Dec 27, 2005, at 7:44 AM, j o a r wrote:

I will try to explain better: We currently have a lot of customers
with ppc machines, and ppc binaries. Sometime next year they might
start buying i386 machines. their LAN they will now have a mix
of ppc and i386 machines, and possibly a mix of ppc and UB/native
versions of our applications.

What I want to avoid is that a user with a i386 machine will launch
one of our old ppc applications. We will make either UB or native
applications available, and I would like to be able to prevent
these users from running one of the old ppc builds.

I've read (but can't confirm, as I don't have a DTK Mac) that Rosetta
doesn't emulate Altivec.

So you could include a little command-line tool with your app, that
would perform a small Altivec operation, and set a default key if
that succeeds. When your app starts, it can check for that key, and
run the command-line tool if it's not present. If the tool runs and
succeeds at setting the defaults key, your app could continue
normally. , it could complain that Rosetta isn't supported
and bail.

sherm--
Cocoa programming in Perl:
Hire me! My resume: http://www.dot-app.org

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

This is not the case anymore. Altivec code will run on Roseta
( though far from full speed )

But, how about this as an idea:
You need to package small INTELL only program with your application
and try to run it. If it fails, then you are on PPC, if it runs,
then Intel.

Dec 27, 2005, at 10:44 PM, Sherm Pendley wrote:

Dec 27, 2005, at 7:44 AM, j o a r wrote:
>
>I will try to explain better: We currently have a lot of customers
>with ppc machines, and ppc binaries. Sometime next year they might
>start buying i386 machines. their LAN they will now have a mix
>of ppc and i386 machines, and possibly a mix of ppc and UB/native
>versions of our applications.
>>
>What I want to avoid is that a user with a i386 machine will
>launch one of our old ppc applications. We will make either UB or
>native applications available, and I would like to be able to
>prevent these users from running one of the old ppc builds.
>
I've read (but can't confirm, as I don't have a DTK Mac) that
Rosetta doesn't emulate Altivec.

So you could include a little command-line tool with your app, that
would perform a small Altivec operation, and set a default key if
that succeeds. When your app starts, it can check for that key, and
run the command-line tool if it's not present. If the tool runs and
succeeds at setting the defaults key, your app could continue
normally. , it could complain that Rosetta isn't supported
and bail.

sherm--

Cocoa programming in Perl:
Hire me! My resume: http://www.dot-app.org

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40tchijov.com

This email sent to andrei (AT) tchijov (DOT) com

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Dec 27, 2005, at 7:44 PM, Sherm Pendley wrote:

Dec 27, 2005, at 7:44 AM, j o a r wrote:
>
>I will try to explain better: We currently have a lot of customers
>with ppc machines, and ppc binaries. Sometime next year they might
>start buying i386 machines. their LAN they will now have a mix
>of ppc and i386 machines, and possibly a mix of ppc and UB/native
>versions of our applications.
>>
>What I want to avoid is that a user with a i386 machine will
>launch one of our old ppc applications. We will make either UB or
>native applications available, and I would like to be able to
>prevent these users from running one of the old ppc builds.
>
I've read (but can't confirm, as I don't have a DTK Mac) that
Rosetta doesn't emulate Altivec.

Don't depend on that being always the case.
-Shawn

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

FYI:

For the benefit of anyone still interested, and for the archives, I
would just like to add that with the latest documentation update,
Apple made the proper solution to this problem official:

To prevent an application from opening using Rosetta, add the
following key to the Info.plist:
<key>LSRequiresNativeExecution</key>
<true/>

<

It works great, and in the following way:

* It adds a nice overlay crossed-out badge thingie to the application
icon, to denote that it can't be launched
* If you still try to open the application, an alert dialog is presented

and out,

j o a r

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

28/12/05, Sherm Pendley <sherm (AT) dot-app (DOT) orgwrote:

Dec 27, 2005, at 7:44 AM, j o a r wrote:

So you could include a little command-line tool with your app, that
would perform a small Altivec operation, and set a default key if
that succeeds. When your app starts, it can check for that key, and
run the command-line tool if it's not present. If the tool runs and
succeeds at setting the defaults key, your app could continue
normally. , it could complain that Rosetta isn't supported
and bail.

You don't wanna do that. It'd also trigger on a G3, because G3's don't
support AltiVec either.

Cheers,
M. Uli Kusterer

"The Witnesses of TeachText are everywhere"
http://www.zathras.de

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

28/12/05, Jonathan Hendry <jonhendry (AT) mac (DOT) comwrote:
--
Tuesday, December 27, 2005, at 07:05PM, Uli Kusterer <
kusterer (AT) gmail (DOT) comwrote:

as a service to your users, I'd also suggest not preventing your
>users from running an app in Rosetta. Rather, warn them and tell them
>there isn't any support for what they're doing and that certain parts
>won't work, and maybe replace any "file a bug report" dialogs with
>warning messages that simply say something similar.
>
You can't really say that, not knowing anything about the app or
the customer base.

If it's an application for planning radiological treatments and
calculating radiation doses and beam angles, do you really
want customers putting it on a configuration that "kinda" works,
but might fail in unknown ways?

No, you certainly don't, no matter how convenient it might be for
them.

(I don't know what joar works on, but there was a company which
used S X for precisely this kind of software.)

Well, I may be a usability nerd, but I'm also a firm believer in letting the
user shoot themselves in the foot when they want to. Warning the user that
they're on thin ice but still allowing that they run the app if they feel
the need is fair enough for me.

The point is that just as I don't know what joar is really working on,
neither of us can anticipate the needs of the users. Thus, in general I try
to always leave them the option of continuing nonetheless if it could make
the least bit of sense.

Cheers,
M. Uli Kusterer

"The Witnesses of TeachText are everywhere"
http://www.zathras.de

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Jan 17, 2006, at 10:00 AM, M. Uli Kusterer wrote:

28/12/05, Jonathan Hendry <jonhendry (AT) mac (DOT) comwrote:
>>
>Tuesday, December 27, 2005, at 07:05PM, Uli Kusterer <
>kusterer (AT) gmail (DOT) comwrote:
>>
as a service to your users, I'd also suggest not preventing your
users from running an app in Rosetta. Rather, warn them and tell
them
there isn't any support for what they're doing and that certain
parts
won't work, and maybe replace any "file a bug report" dialogs with
warning messages that simply say something similar.
>>
>You can't really say that, not knowing anything about the app or
>the customer base.
>>
>If it's an application for planning radiological treatments and
>calculating radiation doses and beam angles, do you really
>want customers putting it on a configuration that "kinda" works,
>but might fail in unknown ways?
>>
>No, you certainly don't, no matter how convenient it might be for
>them.
>>
>(I don't know what joar works on, but there was a company which
>used S X for precisely this kind of software.)
>
Well, I may be a usability nerd, but I'm also a firm believer in
letting the
user shoot themselves in the foot when they want to.

Um, in the example given above, it's not a matter of shooting oneself
in the foot, but of shooting an innocent patient in the [fill in the
blank], with high-energy photons.

Warning the user that
they're on thin ice but still allowing that they run the app if
they feel
the need is fair enough for me.

Not if we're talking about radiation treatment. See, e.g.

humanerrortalk.html#RTFToC18
-Kevin

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com

Jan 17, 2006, at 6:50 AM, M. Uli Kusterer wrote:

28/12/05, Sherm Pendley <sherm (AT) dot-app (DOT) orgwrote:
>>
>Dec 27, 2005, at 7:44 AM, j o a r wrote:
>>
>So you could include a little command-line tool with your app, that
>would perform a small Altivec operation, and set a default key if
>that succeeds. When your app starts, it can check for that key, and
>run the command-line tool if it's not present. If the tool runs and
>succeeds at setting the defaults key, your app could continue
>normally. , it could complain that Rosetta isn't supported
>and bail.
>
>
You don't wanna do that. It'd also trigger on a G3, because G3's
don't
support AltiVec either.

What makes you think that Rosetta doesn't support Altivec?

Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (Cocoa-dev (AT) lists (DOT) apple.com)
Help/Unsubscribe/Update your Subscription:
%40developershed.com

This email sent to bsdarchive (AT) developershed (DOT) com