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.