Re: Determining how the app is run (intel/ppc/rosetta/os version)?
Re: Determining how the app is run (intel/ppc/rosetta/os version)?
- Subject: Re: Determining how the app is run (intel/ppc/rosetta/os version)?
- From: Gerben Wierda <email@hidden>
- Date: Sat, 27 May 2006 11:31:07 +0200
On 27 May 2006, at 09:09, Dix Lorenz wrote:
On 27.05.2006, at 00:23, Gerben Wierda wrote:
PS. I experience this list as not a very friendly one.
I only saw people trying to help you...
Certainly. They wanted to help me partly by lecturing me. That is help.
Basically, people seem to have very short fuses when they suspect
(but do not know) stupid newbie behaviour.
On the internet, nobody knows who you are. On dev-lists, nobody
knows if you are a newbie or a veteran who just hit a mental block
(and will kick himself 2 minutes after posting).
Or (what is the third option?)...
Finding out what OS Version you are running on is ok if you know
why you need to know (different API...). But to work around some
intermittent bug which you don't know if it is in your code or
Apple's? That's a very optimistic way to work around a bug and
veteran developers tend to be pessimistic about these kind of
"solutions"...
I agree. One should solve problems like this by inspecting code and
understanding what one is doing. For one, I almost never use a
debugger. I read code. And documentation.
If I had known that, I would have not asked my original question
like I did but put the explanations/apologies in beforehand. I
know this list has some very knowledgeable people, but the
reactions I get on a simple technical question are rather negative
in tone and often not about the question or technical issue at
hand. I ask a simple question I have to defend myself first why I
should ever need the information, that I should not release my
code anyway, etc.
What the list is trying to tell you: Fix the bug, not the symptoms.
Where does it say I disagree with that?
What you are doing (and thereby proving my point) is that you
*assume* I think differently about these issues than you do.
Everybody can rest assured, I know this is not a *solution* of any
kind, but it is a way of protecting my users. If they now start up
the app on 10.4.6 with Rosetta, the app will quit instead of run and
trigger Apple's bug (anything that brings the system down with a
normal user process is an OS bug by definition).
Of course Apple might have introduced some bug on the intel side,
which might be fixed in a future version of OSX and which doesn't
exist on the PPC side at all.
Which is a matter of record as far as the partial freezes are
concerned (see www.macfixit.com).
It is far more likely that there is a bug somewhere in your code
which depends on some side effect of some combination of whatever.
This is of course always possible.
Until you find the bug (which clearly exists, either in your code
or in Apple's code) you will have to check your App against every
possible combination of PPC/Intel, OS Version, Rosetta/not Rosetta,
Security Updates and so on. For all eternity, because if the bug is
in your code, sooner or later some OS Version will bring the
symptom back. And if it's on Apple's side, they might reintroduce
it because they might not even know it exists...
Well, for this Apple has Developer Support tickets. If code that
(afaik) strictly follows Apple's instructions delivers corrupted
NSData objects and the problem is triggered deep in Apple's code
there is no way I can find out by debugging how I could have
triggered it and if I or Apple is to blame. Hence, one asks Apple. In
the meantime,as a temporary measure, one can prevent users from
running an app in circumstances that blows up in their face, even if
it is not your fault but Apple's. That is in the user's interest.
Assuming that this workaround-patch-mess around for me is some sort
of 'standard mode of operation' for me is what I was protesting
against. It is not and it never will be. And there has been no reason
to assume it is. And that is what I meant with the way I was addressed.
G
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden