Another milestone achieved for the zero others following the progress on this one
A cutdown version of windres has been ported to Windows CE 2.11 ARM. Running on the Jornada 820 it was able to take a simple resource script and successfully output a COFF object. The cool part is the windres program needs a compiler to do preprocessor functionality of the script in order to resolve macros, ignore comments, and so forth. This was linked to TCC instead of the GCC it uses by default. Meaning this was able to also successfully use the TCC that had been ported previously!
What are those and why does this matter? Using TCC
(a preprocessor, compiler, and linker
) alone would relegate the developer to command line style applications and extra coding burden for Windows GUI apps. The porting of existing Windows GUI apps would also bear this burden, because most of them use what's called a resource script. Without a resource compiler, like windres, all the resource script elements would need to be written in code instead and then use the Windows APIs to do the runtime functionality of what the resources do for you.
A resource script basically allows the developer to include strings, controls, accelerators
(hotkeys
), dialogs, menus, cursors, icons, and graphics in their program executable itself rather than leaving loose files all over the file system and loading them at runtime. It's highly convenient therefore widely used.
Therefore to have a convenient or I'd go so far as to say valid development environment you need the functions of TCC as well as a resource compiler. Even the MS sample apps make use of resource scripts. This is now partially achieved!
Next steps:
1. code cleanup. you can imagine the mess created by chopping out functionality and writing debugging helpful info into code.
2. adding a current working directory policy. Windows CE doesn't have such in their design. Had to implement in TCC in order to allow it to live outside the root folder. Root folder is \. So if you want to use \tcc as your root then this step is needed.
3. Link the windres generated resource object with a project using tcc running from the Jornada to ensure it is a valid object. Troubleshoot if not. This has some complexity because windres is generating a i386 COFF and am unsure if tcc cares about that when linking it together to produce an ARM executable.
4. Grab a bunch of code samples, such as from the MS samples, my own code bases, and some other online sources, and run them through TCC and windres and ensure they produce an exe and the exe runs well.
5. Figure out what to do about API documentation. A lot of a developer's time is spent wondering how many parameters a function takes, what they mean, what are valid values for these parameters, and what is the return value and meanings.
You said chopping down windres, so what was chopped? Windres can operate on an rc file
(resource script
), a res file
(an intermediate stage
), and an object file
(the COFF term from above
). It can take any of these as inputs and then process them to generate any of those outputs. Well, to keep the binary executable size smaller and also, selfishly, to keep the scope of porting work smaller... it was cut down to ONLY process an rc as input and ONLY output a COFF. And that's all that would be needed to create or port apps.
What does this run on? Windows CE ARM-based machines. Tested from Jornada 820 Windows CE2.11 and the Sylvania SYNET Windows CE6.0. TCC was tested on others between and beyond and ran fine. Expect this will also. MS is very good about compatibility.
Any notable limitation? Well, an IDE usually has its compilers living in a fixed location and then can aim the process at the projects files. Since Windows CE doesn't have a working directory concept, the tcc and windres will need to live in each project folder. To save space it does not need to live there always. Just copy them to your active project's folder
(via batch file to make it easier on yourself
) when you start working and then remove them if you need when you're done working. Complex projects spanning multiple folders and libraries may be a pain in the rear to setup, but that's a one time rear affliction.
Another limitation is that TCC is a C compiler. It won't do C++. Therefore MFC apps will be excluded.
Another limitation is debugging. There are no breakpoints, stepping, etc. Limited to printf and such. Depending how far forward I can bring the project environment, what APIs exist to allow for self-hosted debugging, and so much more research about what is possible. Maybe the debugging will get enabled, if possible.