Sounds good. I'm also planning on writing a GBA IDE using ATL and WTL. I
recently start doing ATL programming at work so I think this is a good
project for me to get more familiar with template based programming. Of
course a good interface is needed to communicate between the emulator and
the IDE, thats why I mentioned that GDB uses TCP in my original response. I
wasn't trying to argue, I mean, you completely agreed with me. GCC is a
console mode program and thats appropiate to call that externally. I mean, I
know I cant write an emulator, and there's certainly no way to compile GCC
under Visual C++ (which is stupid, imho, you can compile SDL under Visual
C++ and thats cross-platform). But in my opinion the less console mode apps
we use the better. There's no real reason for example to ues GDB, when you
can just like you said have the IDE communicate to the emulator directly.
Granted an emulator can be designed to work with GDB only and everything
else like an IDE marshall through calling GDB, but I know another emulator
(falch.net) that does that and its very slow when stepping through code,
because it has to keep on using GDB as the middle man.

As far as the emulator, its probably better to make it an ActiveX control.
DLL's share process space inside memory. Its probably better to isolate the
ActiveX control into out of process so a bug in the emulator wont crash the
IDE. Only problem with this is intercommunication is slightly slower since
you have to use proxy/stub DLL's. But since your probably just sending a
list of breakpoints or other type commands, that kind of speed isn't really
necessary.

Matt Johnson

> When I wrote CGBide, I got console stuff working nicely. What you need is
a decent debugging interface to the emulator (shared memory, COM object, or
more simply as a DLL) and then the ide writer can adapt to that interface.
> And anyway, I know of a particular emulator author planning on using it.