| 1. User interface |
| - use GNU's long_getopt |
| - allow to pass input and output files via command line |
| - add options for various not-yet-implemented features (Unicode, Win32 |
| format, non-native/native alignment and endianness, compact output |
| format) |
| |
| 2. Input format |
| - improve input file processing |
| Currently, certain pre- and postprocessing is required. winerc |
| should accept an arbitrary resource script and generate the C file |
| with as little intermediate files as possible. I'm not sure how to |
| handle the symbols from windows.h. There are certain options: |
| * winerc predefines the symbols via the cpp command line |
| * windows.h is #include'd, and the resulting C code is dropped |
| (Should winerc do C parsing here?) |
| * a stripped-down version of windows.h is included, |
| generated by "grep '^#' windows.h" |
| * windows.h #ifdef's every C code with _RC_INVOKED |
| (commercial solution) |
| - complete input syntax |
| The goal here is to support every existing resource file which is |
| accepted by another resource compiler, not to put as much fancy |
| features into the compiler as possible. Every correct resource file |
| which generates a parse error can be reported as a bug, a problem |
| analysis and a fix would be appreciated. |
| |
| 3. Output file format |
| - add missing resources (fonts, versioninfo, stringtables,rcdata) |
| - check style handling |
| The semantics of control and dialog styles is somewhat poorly |
| documented. For example, I couldn't find a reference that every |
| control has the WS_VISIBLE and WS_CHILD style, even if they are |
| not specified. What other styles are considered default? |
| The existance of default styles implies support for disabling these, |
| unlike any other proper programming language, |
| NOT WS_VISIBLE | WS_GROUP |
| does *not* mean ~WS_VISIBLE, but WS_CHILD|WS_GROUP (in C semantics). |
| What other strange semantics are there? |
| - check cursor and icon handling |
| At the moment, the .CUR and .ICO files are copied byte-by-byte into |
| the C array. This is probably wrong, as there are things like cursor |
| and icon groups. In which way should they be present in a Wine image? |
| Should we have arrays for every cursor, as well as the cursor group? |
| Is one cursor per group enough, in the context of X? If so, do we |
| still need the group? |
| - create a more compact output file |
| The current format is well-suited for debugging, as one can easily |
| match it with a resource' hex dump. A more compact format would use |
| strings instead of integer lists. A clever algorithm for embedding |
| values <32 and >127 is required. |
| - platform independence |
| Currently, the lay-out of the resources is just as it is in Win3.1 - |
| packed structures, little endian. Although this format can be used |
| on any architecture, aligned data and native endianness would speed-up |
| the resource manipulation and simplify the code. OTOH, this would |
| break applications that rely on the lay-out. All this is of interest |
| for the library version only. |
| - Win32 support |
| |
| 4. Programming Style |
| - memory management |
| No memory is freed in the current implementation. |