Future ...
RosAsm development is open to volunteers and new implementations are generally welcome. The better place to start with, for new proposals or suggestions, is the RosAsm Board. At least some simple rules should be stated:
- Do not start something unless you are sure to see it through to its completion .
- When you leave (there's no shame in leaving), just say that you're leaving.
- Avoid implementing Macros of your own, and try to keep as close as possible to the RosAsm Source style, even if you don't like it (having a unified style is both desirable and important).
-Submit a small outline of how you think your project should be organized in order to define task lists, validity tests, time evaluations and expertise evaluations.
-We should be able to accommodate you in your effort as we are flexible.
In The coming months developments will focus upon the Disassembler, and this will go on, until then Disassembles may be recompiled without (or with very little) hand work, this is to say that it will no more be a Disassembler , but, better said a Decompiler. The perfect state, in which we could guarantee disassembling / Interpreting / Re-Compiling, without any hand work at all, will never be completely achieved, because the interpretation of all the data and what that Data means, inside a PE is not always 100% possible.
Most interpretations are based upon probabilities. Nothing more. But, applied on simple Files, or upon Files produced by the user himself, in another language, the outputted results should be worthy of the actual effort, as this implementation will turn RosAsm into a unique package without any competition, in that area.
Pre-Parsers will possibly be added. Actually, the Equal_Parser is implemented. The OOA Pre-Parser development is delayed, but the overall plans of its organization and syntax are now well defined (as far as possible). I am thinking of using that OOA Plan for a first experiment of structured collective Development, as indicated in the above Introduction. Other Pre-Parsers, for example, HLLs ones, like the Equal one, may be added if some volunteers want to. I have opened a new TITLE, whose name is 'NewParser', given as a start point, for volunteers implementations. It includes comments that, I hope, should help to start working under good conditions.
Wizards (components visual designers) will be implemented, the same way the actual Form Wizard is, either at the end of RosAsm development, if I have to write them by myself, or, at any other time, if volunteers want to move their fingers on their KeyBoards. The Wizards may physically come under the form of a side DLL, or of an independent EXE, grouping all of the various specific Wizards (for ToolBars, for Images Viewers, and so on), probably around the actual Form Wizard.
The Win32 free documentation project is yet up and running. Its purpose is to have a kind of Data Base for all Win32 Data, immediately available from inside RosAsm, either by a Dialog for viewing Api calls, Equates and Structures, or as directly available informations for the Disassembler HLL interpretations. The huge work for Equates has already been achieved, thanks to Guga.
A Code-Ripper is to be implemented. Its purpose will be to select (after Double-Click upon a Code Label, and user selection of an added [Code Ripper] Option), all of the downward tree of the Routines called from this Label Procedure, with all concerned Data. Useful from disassemblies or for Code Reuse.
A Code symbolic Profiler is also to be implemented. Its purpose will be of outputting something a bit like the Tree-View Dialog, but with an added Bar, at each Label, representing the proportional time each Routine will have been consuming in a given Run. Useful for Strategy Optimizations (the only serious one).
A Code Level Profiler may be implemented, as well. The overall idea is to add an Item in the Floating Menu coming with Right-Click on selected Blocks: If the selected Block contains only simple Instructions, add a [Profile Code] Option, which activation should return the Ticks number. The implementation should not be that hard, as an example of how to compile independent Instruction is already available in the [Tools] // [Encoding Box] feature. Problems: ecx loops must be under Control. Memory accesses must be under control. Api calls cannot be included. Jumps and Calls must be under control. Equates must be emulated. Macros must be refused. This feature is not for timing the running Application, but for timing the simple execution of one or several Opcodes, for users interested with Code Level Optimization.
~~~~~~~