IB> The bad news is that the assembler uses a custom syntax, and the object
IB> format is also proprietary. 

Hmmm, that's tough.

IB> This enables the compiler to produce very fast compact code but...

Surely it doesn't optimise the assembler code?

IB> I have written a program ASMTOAS which does most of the hard work in
IB> converting .ASM to .as. I can download a copy to your BBS if you like.
IB> I have put your code through this and included it below.

Thanks, I found that.  For anyone watching, it is NOT available for
FREQ (or download).  I tried it on the dosasm.asm file that I posted,
and indeed it worked on that.  However, that was the one most likely
to succeed.  There was also vio.asm and spawn.asm (that come with
MSGED/SQ), and it didn't stand a chance.

What this basically means is that as it stands, I can't use pacific c.
Unless...

IB> PS I haven't looked at what this code does, but I would have used
IB> intdos() etc as it is much more portable.

I am not very familiar with DOS programming, but looked up that in
one of my compiler's manuals, and indeed, it would seem that doing
something like that, and just providing assembler for intdos(), if
the compiler didn't support it, would be better.

In fact, spawn.asm can be taken out completely, and if I could
likely write most of the vio routines in C too, possibly even 
without performance penalty.  That would bring me closer to being
able to use Pacific C.  I'll have to look into it.

Your messages here on Pacific C have been the most interesting I have
read here for years.  I hope you stick around.  BFN.  Paul.

P.S. If you become a point, you will get your mail using the proper
fidonet technology.  It is MUCH cleaner, it's what it was designed
to do.  Then you would know what MSGED/SQ is.
@EOT:

---