If you're making a game, don't worry about it yet, at some point you will get it out to testers and there will be platform and GPU and to a lesser extent even CPU related issues that crop up and would be very difficult to see in advance as a single programmer with limited resources and available test machines.
These are bugs, to be solved later, don't let them slow you down now. Typically unless you are doing something really really wrong you will find it faster by just continuing to forge ahead, and by the time you do have to solve these bugs you will know your code inside and out and be a better programmer more apt to deal with these types of issues.

BTW the original question is still open. How can I ensure that it runs properly(or as much properly as it possible) on every PC?

The simple answer is this: you can't.

"Every PC" covers an enormous range of hardware and software configurations, from the most basic and primitive to turbo-charged gaming PCs and workstations, and all points in between. It is just not possible to write a program that is guaranteed to run on all of them.

OpenGL is not software. If you want to run fast and run well you are entirely at the mercy of the hardware installed on a PC; if that hardware is horrible then you just won't run fast or run well; you're lucky if you run at all.

As you've just discovered, OpenGL can be capable of emulating certain features in software, depending on the driver, but - as you've also just discovered - this is often not a desirable state of affairs.

OpenGL may have a reputation for being easy, but that doesn't mean that you get to skip reading documentation. So you need to grab an OpenGL spec (available on http://www.opengl.org), read it, understand it, know what you can do and what you cannot do, know what causes errors and what doesn't.

What your objective should be is to pick a reasonable baseline, declare that you're not even remotely interested in supporting anything below that baseline, then make that your target hardware requirement. There's no point in picking a fight that you can't win, and "run on every PC" is such a fight; choose reasonable and achievable objectives instead.

I find that discussion very interesting. I use an old computer for my development. That way I make sure my game will run smoothly on most computers, and perform awesomely on newest ones. My game runs at 100 frames a second or so on my PC. Was I ever pleased when I tested my game on my girlfriends PC. I had a whooping 2200 frames a seconds! And her PC is 3 years old, running Windows 7. Mine btw is 7-8 years old running XP. I think it just makes sense to use a slower machine to develop (and test the game periodically on other machines). Not only for speed but for video card features as well. I'm aware I'm not helping you with your immediate issue here, but wish you best of luck and patience in having your game runs smoothly on older machines. Cheers!

There is a way to make sure you code runs on majority of pc's: use an engine. With a well written engine, most of the pc to game interaction is abstracted so that in order to make sure your game runs on a lot of pc's simply test an engine by itself to see how it handles different fallbacks in cases where a function is not supported etc. You can try to write such an engine yourself but to ensure system wide compatibility you would have to be very knowledgeable in multiple API's and be sufficiently knowledgeable of the particular OS that you're working on (even if the os is a part of windows family). So it's highly suggested to forgo building such an engine and use an already available one. I'm currently starting to learn Unity and so far loving every bit. Not only will your code most likely work on 95% of machines that support Unity (and it's been tested on millions and millions of machines by now) but you can also add a grantee* that it will work on Mac, Android, iPhone, Flash Player, and Linux starting in Unity 4. Not sure if it's the answer you're looking for since you probably want to stick with dealing with a raw API and doing everything in c++ but I'm simply saying that yes it's possible to a certain degree using certain tools.