discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: question about low availability of Mac OS X applications that has Gn


From: David Chisnall
Subject: Re: question about low availability of Mac OS X applications that has GnuStep edition
Date: Tue, 25 Jan 2011 17:21:54 +0000

On 25 Jan 2011, at 01:58, Zhang Weiwu, Beijing wrote:

> Consider application authors delver binary due to the fact the source
> code is thus not available, is a byte-code approach possible solution to
> this BUSINESS PROBLEM? Application vendors deliver half-compiled code,
> and standardized installer (an GNU-STEP component) compile it on the
> target machine to target machine binary. Users don't have to know this,
> they see a progress bar anyway, only slower.


I've looked at this in the past, but it's basically impossible.  Even ignoring 
GNUstep and Objective-C, standard C headers are full of macro definitions that 
expand to different things.  Even really trivial stuff like the things in 
ctype.h are very different between glibc and FreeBSD libc.  Consider this 
trivial C file:

#include <ctype.h>

int countLetters(const char *c)
{
        int count = 0;
        while (*c)
        {
                if (isalpha(*(c++)) count++;
        }
        return count;
}

Run this through the C preprocessor on FreeBSD and on GNU/Linux, and you get 
massively different outputs.  Compile to bytecode, and you'd need a VM that 
internally contains an abstraction layer for every standard C and UNIX API, and 
you'd need to recompile every single  shared library that you wanted to use for 
it.  

Any bytecode for Objective-C that was truly portable would have to contain 
almost all of the information in the (unpreprocessed) source.  

We looked at using LLVM IR for this kind of thing, but it's not practical 
without massive changes to the compiler and significant changes to the C 
language.  For an even simpler example, consider the definition of NSInteger - 
it's 32-bit on some platforms, 64-bit on others.  This decision is made by a 
combination of the configure script and the C preprocessor.  Any bytecode 
representation would need to encode the preprocessor #if statements that were 
used to make that decision.  

The closest that's feasible is to distribute obfuscated source code.  There are 
(free and commercial) tools available for obfuscated code, and they end up 
producing output that is less readable than running a compiled binary through a 
decompiler.

For Étoilé, we actually do support distributing .app bundles containing 
Smalltalk code entirely in source form, and transparently compiling these to 
native code in the background (JIT-compile on the first run).  I plan on 
extending this to support Objective-C code soon.

David

-- Sent from my PDP-11


reply via email to

[Prev in Thread] Current Thread [Next in Thread]