Rolf wrote:
> 'Dos Box' or more techically a CMD shell.

Exactly.  A command shell in windows is not DOS.  It looks a bit like the
DOS command shell and can run some DOS programs, but it is definitely not
DOS.  All my programs are full 32 bit executables.

> Seriously, Olin, I can see the genius in the environment, but it would
> be a nightmare for an outsider to try hack out parts of it and keep it
> sensible... really, it is a take it all, leave it all, or dedicate a lot
> of time and effort trying to understand the magic so that you can
> hack/enhance/clone it (or parts of it).

I haven't actually tried, but I think DBANKIF and related macros are
probably pretty easy to extract.  I could be wrong though.  Making things
seperable is not a consideration.

> Perhaps not DOS, but, what's the right idea?

Comand line executable.

> If you want to tell me
> there is a GUI for it that I missed when I evaluated your tools, then go
> ahead and correct me too.

There is no GUI.  That would be silly.  You can't automate GUIs, at least
not easily.  Clickety-click interfaces may be a little easier to get started
with, but can't be automated, extended, wrapped in higher level tools, and
are a lot slower to use than typing.

I don't use the MPLAB GUI code editing and building because I don't want to.
However, isn't there a way to specify a command to run for each step or can
you only adjust the command line options for the tool that it decides?  If
you can specify the arbitrary command, then causing MPLAB to run the
preprocessor and then assemble the result shouldn't be that hard.  Again, I
haven't tried since I wouldn't use it that way anyway, but I had assumed it
was possible.

> I found no integration with MPLab, the Simulator, and the
> debugger too.

I don't "integrate" into MPLAB, but of course I use MPLAB for debugging.
It's easy to set up a MPLAB project by just importing the COD file result of
building externally.  Once that is set up, you can even run MPLAB and pass
it the project name on the command line, and it comes up with that project.
I have two ways to get into MPLAB.  I have CTRL+ALT+M set up as a hot key
for it, and I also have a script that builds the current project and them
runs MPLAB automatically on the result.  This is what I use most often for
debugging.

It's really not all that different from building in MPLAB.  Either way you
start a build and the end result is MPLAB set up with the result of the
build ready to debug your project without you doing anything in between.

> As for taking the dbankif code out of your environment, your legal
> notices practically exclude that option anyway.

No it doesn't.  All it says is that you have to copy the copyright notice at
the top of the file.  Once you do that, you are free to use it any way you
want, including selling derived copies for profit.  So yes, my copyright
notice at the start of your macros include file is the price for using
DBANKIF.  If that bothers you or it conflicts with a similar license from
someone else (both can't be at the beginning of the file), then you can put
everything you copied from me in a separate include file.  If you don't like
that the you don't get to use my code.

> 'Hacking' the dbankif code would require that any code it is used in
> have the copyright assigned to embed inc.

No, only the file anything you copied from me is in.  After all, you can
copy STD.INS.ASPIC in its entirety and that doesn't give me a copyright over
the rest of your project.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist