Re: Porting windows app to OS X and it's extremely huge as a result
Re: Porting windows app to OS X and it's extremely huge as a result
- Subject: Re: Porting windows app to OS X and it's extremely huge as a result
- From: Greg Guerin <email@hidden>
- Date: Sat, 24 May 2008 15:31:06 -0700
Platon Fomichev wrote:
As for caching and compressing, you're absolutely right and indeed
this technologies might be useful unless you're working with a
sandbox environment (like unsigned Java applet) f.ex. where any
file operations are prohibited and there is no storage to save file.
If you're running a sandboxed Java applet, then I don't see how you
could download and execute ANY native code at all. Java's sandbox is
expressly designed to prevent this.
At the very least, you need file-system access of SOME kind in order
to write an executable file, i.e. the code compiled by gcc that you
said is too big. You can't load anything directly into memory and
execute it. The Java applet would then need to be signed in order to
perform a Runtime.exec() call. That should be an unavoidable
prerequisite, and if it's not, then you have a security flaw.
This is such a vast gap, an unsigned Java applet vs. native code
compiled by gcc, that I suspect there's something fundamental you're
not telling us. As you've described things so far, it just doesn't
make sense. Or to be more precise, the only way it makes sense is if
you are exploiting a security hole.
And for completeness, Java has gzip stream decompression that
requires no special security, i.e. is available to unsigned applets.
See the classes in java.util.zip whose names start with GZIP.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden