git.oblomov.eu Git - wine/blob - rc/TODO

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