Creating a debug development environment for a proprietary language
I'm using a rather obsessive, proprietary langauge called WIL / Winbatch which had a terrible IDE (studio winbatch).
I would like to develop an alternative environment; however, without the ability to set breakpoints, steps, and view variables, there really is no point. How do you even start researching how to implement a debugger for a proprietary language? Is it even legal? I'm guessing I'm kind of locked in my mind that part of the debugger should be able to inspect the assertions that are provided to it in the WIL when they're executed, right? So for some reason I have to catch the interpreter output? Or is it just a matter of reading places in memory in any language? Thanks in advance.
source to share
Why are you so closely associated with this language? If it is not supported, there are many others you can use. Anyway, to actually answer your question, the complexity depends on whether it is a compiled or interpreted language, and whether you have access to any source code (which of course seems like you don't). However, this is going to be a very difficult project, as you will have to redesign the compiled code to make any difference. Your time would be better spent learning another (better) language.
Perhaps if you can give us an idea of why you want to use this language, we could help you?
source to share
While there and successfully completing the task, here are some things to keep in mind:
- Build it as a plugin / extension for the IDE that your team is already familiar with and loves. They will thank you for providing an interface that is consistent with what they really know how to use, plus you can focus entirely on the features that make your language stand out from the crowd.
- You will need to learn the debug protocol for your language. In our case, we had initial access to the runtime for an interpreted language. In other cases, you might find documentation for the local or remote GDB debugging interface, a library you can link to, for the language debugging protocols, or perhaps even figure out what the call stacks look like, and wrap the Windows Debug API to parse it behind scenes ...
- Don't build beyond what the language provides. Adding debug functions is time consuming and they have a rather annoying habit that needs to be substantially changed or completely rewritten as versions of the target language are updated.
source to share