C# has a special class to deal with unmanaged COM objects. Something like this could be done for BlitzMax, to make interfering with other languages easier. Apart from this I would never go back to an unmanaged language I just would like Max to handle circular references.
To the debuger issues, I *think* the internal Max debuger is not flushing the pipes properly at some point, when the data alocated to the debuger is too big it, at some point, raises the 4096 bytes limit, waiting for the host application to get all the text while the host application is waiting for the debuger to send a complete package. I think the flush operation should be done in a per-item iteration istead of being done per block, but this would slow down a lot regular debuging. Not sure what else can be done here apart from integrating the debuger front-end in the debuged application as B3D has been always doing. There are other options such as sharing directly data between the running application and the host, without using pipes, but this could become a nightmare becouse of the very different APIs Windows, MacOsX and Linux have in this particular area.
To the debuger issues, I *think* the internal Max debuger is not flushing the pipes properly at some point, when the data alocated to the debuger is too big it, at some point, raises the 4096 bytes limit, waiting for the host application to get all the text while the host application is waiting for the debuger to send a complete package. I think the flush operation should be done in a per-item iteration istead of being done per block, but this would slow down a lot regular debuging. Not sure what else can be done here apart from integrating the debuger front-end in the debuged application as B3D has been always doing. There are other options such as sharing directly data between the running application and the host, without using pipes, but this could become a nightmare becouse of the very different APIs Windows, MacOsX and Linux have in this particular area.