It might not have been too bad to go through and make sure it was just passing everything it used, but it was a lot of code and it kind of all needed to be changed at the same time.
I say this as someone who is generally sold on TDD being the best approach. At first it seem tedious never being able to write more than an handful of code line before having to stop and write a test, but the ultimate freedom it gives you to fearlessly refactor is worth it.
On the other hand I would never (have learned the lessons of trying) attempt to go back and create tests for a software project like the one you describe; and as a general rule anything substantial which does not have them.
It sounds like you are doing lots of shotgun surgery to nurse some spaghetti code along. One of the things TDD does for you is make you keenly aware of all the cross-cutting, coupling, and cohesion in your code. If you have organized something badly you discover its difficult to author a test for, that's clue something is wrong.
Trying to go back and write tests for code that isn't well organized is FAIL you won't write good tests because you can't and if you don't have good test coverage "passing everything" does not really tell you things are alright. Its painful pointless wheel spin.
Just live with it. Address the compiler warnings, try and diagram us much process flow an interactions across those globals as you can so you have a good picture to look at why you plan groups of changes, do your best and hope the QA test guys catch anything you break prior to release.