64 lines
3.0 KiB
Plaintext
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.
|