To answer the inherent questions:
1) It'll be gradually rolled into one program. Since everything is essentially interconnected anyway, it makes more sense to have everything in one place. That way a change in one area can be "seen" to affect others.
2) Because this is going to involve a great deal of string handling and dynamic allocation, but not require much in the way of efficiency, I'm going to be using the Last fully stable Version of an older (somewhat obsolete) language I can get the most out of using the least progging time.
It's gone through a number of naming incarnations, but you can find the product here:
www.emediat.com if you're curious. With all of it's excentricities, it's the best language I've ever encountered for string handling.
It's going to work, and work bloody well, but it's going to look dated and nowhere near as slick as something you might get out of .net SDKs.
3) Exan, you might look to see if your Version of C# or C++ supports the strtok function in the string.h header package. It dates to ANSI C, so it should be there. That's probably the most effective way to parse a line for text, but the extrenious spaces in the text might make it more difficult to use.
As for dealing with spaces, you can first locate the :=. Every non-leading/terminating space character before it is your variable. Every non-leading/terminating space character after it is your data.
Substring type functions can make this convenient to code, but it's not necessarily going to be particularly optimal code.
Still, that isn't going to matter in this type of application. You only need to worry about it if you were writing something real-time in tighter processing conditions.
I may have some time to code this weekend, if there are no additional surprises.