Hi all,

I'm currently working on the RadASM documentation for HLA.
I've got a couple of suggestions, questions, and other issues that I've come
across while figuring RadASM out. Here they are:


1. Comment/uncomment works fine for every assembler *but* HLA.
HLA uses semicolons to end statements, not create comments.
HLA supports C/C++ style comments ( either /* ... */ or //....)
probably the easiest adjustment would be to use the "//" form.

2. Under the "make" menu, it would be really nice to have a
"rebuild" or "build clean" option that one could use to delete
any existing object files, etc., prior to doing a build.

3. Another suggestion for the "make" menu is to add "debug"
that one could use to run an external debugger (like Ollydbg).

4. One feature I use considerably in CodeWright is the ability
to do columnar cuts and pastes. In Codewright, if you hold
down the right mouse button while you drag the mouse to
select text, you select a rectangular (columnar) region rather
than a sequence of lines. When you paste the text, it also
inserts in a columnar fashion. This is an *incredibly* useful
feature that I use all the time. Some facility like this would
be especially welcome in RadASM.

5. It would be nice if the rules for determining what gets listed under
.code, .data, .const, macro, struct, messages could be made
external to the code (either in an .INI file or via some DLL)
so that they could be easily modified. Currently, the support
for HLA is very weak; although I could envision such support
being added to HLA, one problem with this approach is that
HLA supports an extensible syntax (via the compile-time language)
and it's quite possible for an HLA end-user to create their own
types of data sections, const sections, etc, that would foul any
scheme that's hard-coded into RadASM. It would be really nice
if the end-user could define regular expressions (or grammars)
to define these types of symbols within the source code.

6. May as well repeat a suggestion I made a while back -
API tooltip processing should be made external as well so
someone could supply "fill in the blanks" processing for
custom libraries and such things.


A. Under the and related sections, there is
the following:

'*' Is used to build modules

What exactly does this do? What does it expand to?

B. (related to A, no doubt). I've create a fairly generic make
file to process HLA projects (hopefully to replace the HLABUILD.BAT
file that RadASM currently uses). I need a list of all the
.hla, .res, library, and other files associated with a project.
How do I obtain all these file names so I can pass them on to
make? Currently, my generic makefile requires command lines
like the following:

make executable=t.exe files="a.hla b.hla c.res" libraries="somelib.lib" build

make executable=a.exe files="a.hla b.hla"

Let's presume that a.hla is my "main" program and all the other files are
HLA units (modules). How do I construct a project and how do I build the
command line to execute these commands?

C. When RadASM begins execution, the default project directory is MASM32.
Is there some spot in the .INI file where I can change this?

D. What is the difference between adding an ASM file and adding a module?

Randy Hyde
Posted on 2003-05-02 14:38:13 by rhyde
Hi Randy

1. Implemented a while ago. Works well as far as I know.
2. This exist as an option in the path explore ++ addin.
3. This is easily done in the tools menu.
4. Lots of work. I will see if I can find the time.
5. I guess this can be done in an addin dll.
6. This can be done by editing the .api files.

A. '*' enters a loop where every file that is added to the project as a module is assembled / compiled to an obj file.
B. I need a little time to try this out.
C. In RadASM.ini you find this section:


In your case you probably want to make hla the default. Change it to:


Then in hla.ini you find this section:


D. A module can be assembled to an obj file seperatly (see A.).

Posted on 2003-05-03 12:40:48 by KetilO