Sweden-Number/rc/TODO

64 lines
3.0 KiB
Plaintext

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.