JoeyBlades says:
Give me a break. Just because the stuff on disk isn’t byte-for-byte what’s in memory doesn’t mean squat. It’s the same story on every architecture. Anyone who knows PPC assembly can easily disassemble the code on the disk, figure out where the entry points are, and insert their own code ahead, behind, or right in the middle of it, proprietary executable format or not. I’m not trying to show off by stating this. I’m just telling you why you’re wrong. Believe me or don’t (and if you don’t, ponder the apparent paradox of 3rd party compilers creating Mac applications without going through the code fragment manager).
Writing software can be described as “very difficult”, too. What you’re describing is decidedly less difficult than, for example, stack overflow exploits which allow people to break into unix systems through buggy system daemons. Yet amazingly, people still write tools to do that. “My system is secure because assembly programming is hard” does not cut it.
How about a list?
[ul]
[li]“The Macintosh execution model is better than Windows, because code can only manifest itself and be executed if identified as such (via specific resource namining conventions).”[/li][li]“First [executable code segments] have to be of a particular resource type. Second they have to have the right resource ID, which means they have to replace another code resource without causing the application to halt abnormally.”[/li][li]“There are many ways to load whatever you want into RAM on a Mac, there’s only one mechanism to execute code. The Mac OS won’t just jump to any old block of RAM and start executing.”[/li][li]“The executable code in the MacOS is not saved as a simple byte stream that you can append to. The only way to do what you suggest is to go through the MacOS commands for managing resources.”[/li][li]“The Photoshop example is not executing the code in with the Mac OS execution model.” (Perhaps you better define “execution model”, because in my definition, everything running under the MacOS is in it’s execution model.)[/li][/ul]
I’d elaborate on why these are wild claims, but a) I think it’s already been covered and b) you’ll accuse me of being a bully for demanding honest arguments.
No, the fact that the things you say are wrong is what invalidates your point. If you base your arguments on false statements, you have two choices:
[ul]
[li] come up with new facts to support your arguments, and give up on the falsehoods[/li][li] admit your arguments are baseless[/li][/ul]
Oh, come on. You can’t spout as much bogus information as you have and not expect to be called on it. When someone calls you on it, and bothers to give hard technical facts to support their argument, it’s not always about “demonstrating dominance”. I would have gladly left out the technical details, but then I would simply be arguing like you, saying “nuh-uh, that’s not true” without backing it up. Heaven forbid someone bring facts to the table.
If I seem extra harsh on you, it’s because it really annoys me when people act authoritative on a subject when it’s obvious they don’t know what they’re talking about. Especially in a situation where most of the people they’re talking to can’t tell the difference. When you say “The Macintosh execution model is better than Windows, because code can only manifest itself and be executed if identified as such”, that is wrong. Maybe there’s some other reason the Mac execution model is good, but that sure ain’t it, so your argument is trash. Yet most of the people you’re talking to don’t know that. That’s called spreading ignorance, not fighting it.
If I started making up authoritative-sounding statements about neurosurgery (of which I have no knowledge) in general company, you can bet any neurosurgeons present would get good and pissed off if I persisted despite their corrections, especially if the other participants were not in a position to discern whether I was telling the truth.