Abstracting the operating system is certainly possible.
With your renderer you used a run-time polymorphic base class IRenderBase and the implementation was plugged in at run-time. However with an operating system using a run-time polymorphic base class is unnecesary overhead, you cannot change OS at run-time and just plug-in a different IOperatingSystem, in-fact chances are your entire program will need re-compiling for the new platform. For this reason its probably better to use compile-time polymorphism.
There are a few ways to do this, but a good way to do this is something like:

#if defined(WINDOWS_PLATFORM)  typedef CWindowsPlatform OSPlatform;#elif defined(OSX_PLATFORM)  typedef COSXPlatform OSPlatform;#elif defined(LINUX_PLATFORM)  typedef CLinuxPlatform OSPlatform;#else# error Operating system could not be identified.#endif// Instantiate the platformOSPlatform system_platform;

Then just use system_platform everywhere
e.g.
system_platform.outputDebugMessage(DEBUG_CONSOLE_NOTIFY, "Blood sucking monster created.");
system_platform.outputDebugMessage(DEBUG_FATAL_ERROR, "@ CD3D9_Renderer::createRenderTarget");

I'd build an engine on top of ClanLib, if you can. Much like SDL, but it's a bit higher level and a little more of a full featured SDK (has built in threads, networking, graphics, GUI, and more).

You can:
1) use cross platform libraries such as SDL
2) Abstract parts of your game engine that are OS specific.
3) Use a modular structure for your game engine.
e.g. my renderer is OpenGL, but its abstracted. Its a class whose methods receive meshes to be rendered. As such, if OpenGL support drops for a particular platform I could write a renderer for whatever graphics library works on that platform.
My input system works likewise.

This also has other benefits. My current knowledge of rendering is primitive. If I learn something new, I already have a game engine which I can test it on.

Quote:Original post by Ravuya
dmatter is right; this is pretty much how I do things (not so much for the virtual call overhead, but because there's no reason to switch them out at runtime).

Assuming you are not using cross platform libraries, and are rolling your own cross platform engine.

I would extend this one step further. For small code chunks a couple of lines or so in some 'mostly' platform independent function, it makes perfect sense to use #defines. In the case where the API is mostly platform dependant you would make an awful mess and create very large source files by scattering #defines right through the source file. For the small cost of some initial workspace set up you can create platform specific source files. Ideal candidates for these are Rendering, Input, Threading, Sound and FileIO

Rendering example.

rendering.h - Contains the API declarations
rendering_multi.cpp - multi platform implementation (empty stubs) will compile on any platform but when called return doing nothing
rendering_pc.cpp - PC specific implementation of the API
rendering_mac.cpp - Macintosh specific implementation of the API
rendering_linux.cpp - Nix specific implementation of the API

It is most likely that you have a specific workspace set up for each platform, as each platforms build will need to be compiled separate from each other. Simply add the correct platform source file to your workspace for that platform. Ignore or exclude all the others. One of the extreme bonuses with this cross platform structure is that you can add a new platform quickly and have it compiling with very little work by linking to the _multi.cpp files for new platforms. It is then only a matter of filling in the stubs and renaming to the new platform.