Re: Modifying system files
Re: Modifying system files
- Subject: Re: Modifying system files
- From: John Stiles <email@hidden>
- Date: Sat, 09 Jun 2007 10:38:38 -0700
You can drag and drop files via the Finder. It will ask you to
authenticate, but your app will need to do that too.
Just make an alias on the desktop to the folder with the sounds in it.
Voila, easy access.
Aaron Wallis wrote:
Hi all and thanks for the many words of warning :P
The app I'm building is simply a utility to allow people to change the
audio files in the core audio component in a considerably less
intrusive manner than via the terminal etc.
I found my computer illiterate partner hacking away at my laptop to
change a sound... a drag and drop interface is WWWHHHAAAAYYYY better
than a n00b learning how to use the terminal in /System/Library )
It is known now, and always will be known as a "use at your own risk"
stye application (not to mention possibly become redundant in 5 days
time :P)
Thanks again for your help and warnings.
- Az
On 10/06/2007, at 12:46 AM, Ricky Sharp wrote:
On Jun 9, 2007, at 9:26 AM, Shawn Erickson wrote:
To echo what Wain stated... DO NOT modify files under /System unless
it is required as part of an Apple approved / supported pathway (aka
install KEXTs, etc.). If you still feel you need to do this you must
fully understand the security and stability issues involved and you
must inform your customers of what you are doing. You must take
extra care in implementing you software so that it itself or by way
of what it modifies doesn't expose or become a vulnerability. This
means fully understanding how to utilize authorization services, how
to install your application securely, how to keep it secure, and
also how to ensure you keep proper file permission, etc. on the
files you modify.
Additionally you will be modify files that Apple is free to rename,
change the format of, etc. on a whim because they are not part of
the public API for Mac OS X. You expose your customers up to all
kinds of potential issues with every security update, patch release,
and major revision.. and open yourself up to a possibly bad support
situation.
Personally somethings just shouldn't be done even if you and your
customers think it would be a cool thing... I rate this type of
product as one of those.
I'll also add a couple things here (if Shawn and others have not
already convinced folks that this is a bad idea :)
(1) Tiger and Leopard work with resolution-independence. Thus, your
new artwork would need to be able to work flawlessly at various
scaling factors.
(2) More importantly, I believe there are many APIs in both Cocoa and
Carbon that return back sizes of controls. If your artwork is not
the exact same size as what Apple provides, you introduce a high risk
of those APIs returning incorrect info. For example, it may be the
case where sizes may be hard-coded as opposed to being dynamic based
upon actual image sizes.
___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden