I echo Speedo's points.

I'd like to add this to the perspective.

When decided what classes to fashion, it's instrumental to keep in mind that they model or represent concepts as metaphors. The more 'real' we can make that metaphorical representation of concepts, the more like a machine our software becomes - the properties of components fitting together to create a larger machine.

Global variables violate this notion of encapsulation. If they're genuinely appropriate as global variables, it would be because these variables represent global concepts - that for which there can be only one for the entire application.

If the concepts these variables might not always be global, as speed points out, then at best they should be members of an object which we instantiate once. This encapsulation makes them portable as a group into other environments which aren't always global in concept. That is, they may be global in a simple application, but not always global in future developments.