1Work notes 2========== 3 4These are my notes on the evolution of rc. I used to keep these in separate files on my development 5machine, but it makes more sense to include them here. Warning: geeky stuff ahead. 6 7Unlike in most parsers, the unary minus operator is currently not part of the 'data' rules, but 8 of 'integer' and 'float'. When expression support is more complete, it may make more sense to put 9 this in 'data'. However, 'integer' is used in other places as well and these places allow 10 negative numbers too. Maybe we can replace the calls to 'integer' with 'data' and allow the data 11 to the integer only (by always trying to cast it, perhaps). Then you can do stuff like 12 `resource(10 + 1) 123;` But maybe that goes too far. 13 14When filling in boolean fields of user-defined types or messages, you can do either 15 `field = true` or `field = false`. I thought it would be nice if you could also do just 16 `field` and `!field`. However, that introduced a reduce/reduce conflict in the parser. You see, 17 the name of the field is an IDENT token, but we already have something like that in the 'type' 18 rule of 'data'. The parser doesn't know what the IDENT is supposed to be: the name of the boolean 19 field or the name of the type. Maybe there is a solution for this by shuffling around the parser 20 rules a bit. 21 22Support for the built-in types point, rect, and rgb_color is currently hardcoded into the 23 decompiler. The other built-in types -- app_flags, mini_icon, etc -- are not supported at all. 24 It would be better to use the type symbol table for this as well. Then the decompiler can also 25 support user-defined types (although these type definitions must be provided to the decompiler 26 somehow). This is advanced stuff that probably no one will ever use. 27 28The builtin types are added to the symbol table "by hand". You can see this near the bottom of 29 'parser.y'. This is a bit cumbersome, so I have devised an alternative. We put the builtin type 30 definitions in an rdef script and install this in a "standard include dir", for example: 31 ~/config/include/rc. Before it compiles the user's rdef files, the compiler first loads all 32 scripts from that standard folder. (This also allows us to use these rdef files for decompiling, 33 and users can simply install their own. See above.) 34 35In "auto names" mode, the decompiler currently does not use the enum symbol table. So if two 36 resources have the same name and that name is a valid C/C++ identifier, the decompiler will add 37 two conflicting symbols to the enum statement. This can also happen when multiple input file 38 have conflicting resource IDs. 39 40When you decompile certain apps (BeMail, Slayer) and then compile these rdef files again, the 41 archive and message fields in the new .rsrc file are larger than the original's. I think this is 42 because rc doesn't add the message fields as "fixedSize" (see the BMessage docs from the BeBook). 43 This doesn't really hurt, though, since the BMessage will be properly unflattened regardless. 44 45Right now, archives are treated as messages. Maybe we should give them their own type, 46 B_ARCHIVED_OBJECT (type code 'ARCV'). 47 48New options, stolen from other resource compilers (rez and beres): 49 50-D --define symbol[=value] 51 set the value of symbol to value (or 1 if no value supplied) 52 53--no-names 54 do not write any names in resource file 55 56-h 57 write resource as C struct in a header file 58 59-d 60 dump resource to stdout 61 62Attributes. I would be nice to have a tool that can take text-based descriptions of attributes and 63write out an attribute file. Of course, rc is the ideal candidate for this, since it already does 64the same for resources. However, resources and attributes are not the same. Attributes are 65name/data pairs. The name should be unique. They don't have IDs. They do have a type code, but it 66isn't used to identify the attribute. It is probably best to add a new kind of definition: 67attribute(). Should this statement allow only simple data, or must attributes be able to handle 68flattened messages, arrays, etc too? A source file should either contain resource() statements or 69attribute() statements, not both. 70 71User-defined symbolic constants. To keep things simple, adding a #define keyword would suffice, 72although this always creates global symbols so there is a chance of name collisions. In addition 73(or instead) we can extend user-defined types to have their own (local) defines too. If we use the 74#define keyword, we should infer the type of the constant from the data (100 is integer, 10.5 is a 75float, etc). This is necessary because we don't have a separate preprocessor step like C/C++ does -- 76that is why our symbolic constants are typed. 77