Universal Disassemblers vs. Universal MIILs

[Eric S. Raymond]

In <10191 at cup.portal.com>, bcase at cup.portal.com (Brian bcase Case) writes:
> In article <7226 at ihlpl.att.com>, knudsen at ihlpl.ATT.COM (Knudsen) writes:
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >And distributing a uMIIL isn't going to make automatic disassembly *easier*?

Eh? I wrote what he's quoting, and I am *not* "knudsen at ihlpl.ATT.COM".

> You have described "MacNosey" for the Mac by Jasik Designs!  Check it out.

Interesting...does anybody know of a similar product for Intel-family machines?

> Yes, this is the problem.  But the point of a MIIL is to prevent obsolete
> software, not prevent reverse engineering. 

My article was in reply to a claim that a uMIIL would somehow offer better
security against what we politely call "reverse engineering" than current
machine code.

>                                            However, the prevention of
> reverse engineering will probably be required to gain the kind of acceptance
> it needs to make an appreciable impact.

True. And this raises an insuperable problem for uMIIL proponents, because
"preventing reverse engineering" and "easy portability" are diametrically
opposing goals. The uMIIL concept seems to me to be a particularly
ill-thought-ought stab at serving both masters -- but machine-coded proprietary
software already well meets the requirements of the former and HLL source 
is pretty good for the latter (modulo OS-standardization problems that any
uMIIL will *also* have).

In case it isn't obvious, I think this is yet another reason to class the
whole notion of uMIIL as a distracting red herring and forget it.
-- 
      Eric S. Raymond                     (the mad mastermind of TMN-Netnews)
      UUCP: ...!{uunet,att,rutgers}!snark!eric = eric at snark.UUCP
      Post: 22 S. Warren Avenue, Malvern, PA 19355      Phone: (215)-296-5718