> What Macromedia have done
> with 8.5 is to completely and totally change the structure of byte code,
> though the input syntax is pretty much the same as AS2.0. Reverse
> engineering the bytecode is difficult without a description either of
> the VM architecture, or of the file format. There are many blocks of
> data inside the bytecode that just cannot be interpreted without reverse
> compiling the VM or the Flex Builder application, both of which may
> leave the implementor and users open to litigation.

I wouldn't say that. Of course it's not easy, but it's not impossible,
either. And as the Irrelevant Elephant said, it's kinda fun :)

Sure, at least knowing something about the architecture would help a
lot. But figuring out single bytecodes it totally possible by doing
little changes (say, a plus instead of a minus). The more gets figured
out that way, the easier the rest becomes. It's a bit like a puzzle,
the more pieces you have in place the easier it gets.

mark


On 10/25/05, Alex Bradley <[EMAIL PROTECTED]> wrote:
> Having had a quick look at AS3.0 I have to say that this is a completely
> different beast from ActionScript 2.0. AS 2.0 compiles to Action Script
> 1.0 and this has been around in same form since the beginning of the
> Flash plugin - the changes in each version have been incremental and
> have not changed fundamentally since Flash 5. What Macromedia have done
> with 8.5 is to completely and totally change the structure of byte code,
> though the input syntax is pretty much the same as AS2.0. Reverse
> engineering the bytecode is difficult without a description either of
> the VM architecture, or of the file format. There are many blocks of
> data inside the bytecode that just cannot be interpreted without reverse
> compiling the VM or the Flex Builder application, both of which may
> leave the implementor and users open to litigation. If Adobe/Macromedia
> are serious in their support for Open Source, now might be a good time
> for them to indicate whether they will be making their VM or file specs
> open-source in an patent-unencumbered way and when this will happen.
> Given the the Flash 8 format has not yet been released, I wouldn't hold
> my breath. I'd love to be proven wrong... Mike??
>
> Still, I would work on the assumption that the format will be published
> in some form within the next 12 months. If this assumption is correct,
> there is still a huge amount of work that can be done between now and
> then. As maybe the only other person on the list that has written a full
> ActionScript 2.0 compiler (unless some Macromedians are lurking
> somewhere) I respect what Nicolas has to say about OCAML (I've
> programmed in Prolog for three years). Indeed,  the speed with which
> MTASC was written is a testimony to this. However this has its own pros
> and cons. If more than one person was working on MTASC I believe it
> would have many more features than it currently does, and there would be
> a much greater dialog between the authors and the community. The choice
> of OCAML retricted this (though so did Nicolas' choice not to open up
> the development tree). Other than Ralf's work with HamTASC, there have
> been no other user contributions to MTASC (this may also be so that
> MTASC can be dual-licensed?).
>
> I also don't believe compilers should be just seen as standalone
> programs anymore. I went from coding in 'vi', to JBuilder, to Eclipse,
> each representing a much greater degree of integration between the
> process of coding and the process of software development and each
> increased mmy productivity many-fold. Having a extensible stateful
> compiler that directly embeds into your application is a natural
> progression and I see many benefits of this approach that more than
> compensate for having to develop in a more general-purpose language
> including things such as incremental compilation or caching
> (KineticFusion can recompile most SWFs in less than a second even after
> modifying classes - the key word here is 'recompile'). The Flex compiler
> for example, including the ActionScript bits,  is written in Java and my
> understanding is that it performs very well.
>
> Have as ASDT folks not already written an AS2.0 lexer/parser for their
> Eclipse plugin? My recommendation would be to concentrate on the
> lexer/parser/semantic analyser for as long as possible. Ensure that as
> much semantic information as possible is extracted and represented as
> object references are used in a much more complex way in AS3.0. The code
> generation bit should probably be the last piece of the puzzle and could
> be completed in a week by a couple of skilled coders if the
> documentation is available. I'm not sure the alternative approach of
> working backwards from the bytecode is a good use of resources for the
> GENERAL community (I think it's good for individuals to look at so they
> can still give semantic requirements feedback to the semantic module
> people). And remember, we're still talking about 12 months before there
> is going to be any kind of Flash 8.5 presence out there.
>
> Just my 2 cents (I'll go back to lurking now!)
>
> Alex

--
http://snafoo.org/
jabber: [EMAIL PROTECTED]

_______________________________________________
osflash mailing list
[email protected]
http://osflash.org/mailman/listinfo/osflash_osflash.org

Reply via email to