2003-02-16 15:18:36 +00:00
|
|
|
<HTML>
|
|
|
|
|
<HEAD>
|
|
|
|
|
<TITLE>Planned features</TITLE>
|
|
|
|
|
</HEAD>
|
|
|
|
|
<BODY BGCOLOR="#FFFFFF">
|
|
|
|
|
|
|
|
|
|
<H1>Planned features</H1>
|
|
|
|
|
|
|
|
|
|
<UL>
|
|
|
|
|
|
|
|
|
|
<LI><P>Simple integer expressions + - * / | & ~ ()</P></LI>
|
|
|
|
|
|
|
|
|
|
<LI><P>Make user-defined types more powerful. Some ideas: bitmask fields (for
|
2003-04-06 12:10:42 +00:00
|
|
|
app_flags), choice fields (for app_version), conditional constructs.</P></LI>
|
2003-02-16 15:18:36 +00:00
|
|
|
|
|
|
|
|
<LI><P>Attributes, so you can also use rdef scripts to add attributes to your
|
|
|
|
|
files instead of (or in addition to) resources.</P></LI>
|
|
|
|
|
|
|
|
|
|
<LI><P>In "auto names" mode, the decompiler currently does not use the enum
|
|
|
|
|
symbol table. So if two resources have the same name and that name is a valid
|
|
|
|
|
C/C++ identifier, the decompiler will add two conflicting symbols to the enum
|
|
|
|
|
statement. This can also happen when multiple input files have conflicting
|
|
|
|
|
resource IDs.</P></LI>
|
|
|
|
|
|
|
|
|
|
<LI><P>Support for the built-in types point, rect, and rgb_color is hardcoded
|
2003-04-06 12:10:42 +00:00
|
|
|
into the decompiler. The other built-in types--app_flags, mini_icon, etc--are
|
|
|
|
|
not supported at all. It would be better to use the type symbol table for this
|
|
|
|
|
as well. Then the decompiler can also support user-defined types (although these
|
|
|
|
|
type definitions must be provided to the decompiler somehow.)</P></LI>
|
2003-02-16 15:18:36 +00:00
|
|
|
|
|
|
|
|
<LI><P>Right now, archives are treated as messages. Maybe we should give them
|
|
|
|
|
their own type, B_ARCHIVED_OBJECT (type code 'ARCV').</P></LI>
|
|
|
|
|
|
|
|
|
|
</UL>
|
|
|
|
|
|
|
|
|
|
</BODY>
|
|
|
|
|
</HTML>
|
