Platform Abstraction

[DeXecipher]

Is there a standard way??? If so, then what is the standard way, in your experience that softwares abstract the platform (os/compiler) away from the software system?

So far I've been defining my own macros and s*** in my headers, which I alter the value of at compile time. I'm wondering if this practice is suitable for a small to medium scale project.

Lets assume I want to eventually extend some of my features out to another platform, would all I have to do is continually modify the library who's sole purpose is listing what I'll need for each OS, for example?

Right now my library can detect whether or not the user is debugging, wants to debug, or is in release mode. It can also detect MSC and GNUC compilers as well as if the user wants to use doubles or floats as a real type number, that will be standardly use in the package. For example:

//somefile.h
#USE_DOUBLE_PRECISION 0

//...later on as needed, but in the same package
#if USE_DOUBLE_PRECISION == 1
typedef double real;
#else
typedef float real;
#endif

//later on use real in some library that needs it, only dependant on the 
//engine layer which defined real, or the user.

//OS definitions
#define OS_UNDEFINED -1
#define OS_WINDOWS 0
#define OS_LINUX   1
#define GLOBAL_OS OS_UNDEFINED

//detect compilers/defines
#if defined( __linux__ )

#ifndef LINUX
#define LINUX
#endif

#endif

//...later on

#if defined( LINUX )

//include some header, or files needed in the using package
//do some system specific api calls 
#undef GLOBAL_OS
#define GLOBAL_OS OS_LINUX

#endif

Heres my simple pseudo-graph

[platform handling lib]->[implemented lib using platform handling libs]->[specific subystem (OS) or target of abstract library]

[interface user]->[implemented (abstract) lib using platform handling lib]

Is my way feasably acceptable way to build at least a medium scaled project as long as I keep this layer separated from the software projects that will depend upon system calls or system specific objects/datatypes?

For example in Windows, they define HWND has typedef void* HWND as well as a lot of other duplicate crap such as HINSTANCE and HANDLE (another void*). But in WINAPI the do it more loosely, hence why WINAPI is not as elegant as Opengl.
For example I've seen INT and int used in the definition of a function and LONG_PTR and UINT_PTR interchanged as well as _int64 __int64 _stdcall __stdcall__ and __stdcall. In other words, a bunch of redundant stuff, which I want to keep my library from doing. What do you guys suggest?

Thanks.

Edit: its kind of a bottom up strategy.

[DeXecipher]

nobody??

[tition]

I started on Windows, switched to Linux. For a period I maintained both systems, now I maintain Linux only (I haven't booted to Windows the last 3-4 months or so).

a bunch of redundant stuff, which I want to keep my library from doing. What do you guys suggest?

You have to tell us more about your project. What does it do? Aims/Goals?

***
To handle input/output in my program I use pointers to functions. For example, I have a data structure with a pointer to "display-text function" which takes arguments strings. I hook up a display function run-time. In this way, all system-dependent code is located in a single file, which provides pointers to all input and output functions to my system. All my system-dependent functions can be initialized with 0, signifying "do not call anything".

To handle mutexes and other system-depend structures which do affect program flow, I still use pointers to functions. I create my own mutex class with a static pointer to a "create-mutex" function. At run time, the system changes the pointer to create-mutex-function. This way all system dependent code is kept outside of my main code.

The result: except for one file, containing main(int), my system compiles using only std:: includes on all systems, yet takes advantage of mutexes, i/o, system tyme, etc., by changing a few function pointers at run time (usually, in the main(int) function).
***
With that said, here is my take on GUI
1) GUI
I started using
first) pure WINAPI
second) FOX toolkit
third) wxWidgets.

only to finally switch to
Apache web server + std::cout output in html.

My conclusion is that WINAPI, and any related programming is total and utter crap. Whoever designed it was learning how to program at best. That is not such a negative statement: back in the 1980's many programming techniques didn't exist. in the 1980's, everyone was learning how to program (and in a way still does). However, it appears some people were talented at it and others (many working at Microsoft) weren't.

2)As far as mutexes and similar go:
Back in 2010 I was using a *completely legal*!!!!! version of Windows XP. Yet, certain standard mutexing structures documented on MSN didn't work. I would have had to change my program flow from using mutexes to some other microcrap structure. I decided instead to drop Windows support. My code still works on windows, but I substituted proper mutexing with a non-guaranteed-to-work infinite loop emulation.
Moral of the story: use Linux.

[DeXecipher]

@tition
Yes, I've reached the conclusion that WINAPI is pretty garbage. I'm working on some sort of engine, definitely one that will allow the creation of games, but not necessarily limited to games. I been coding it on and off for over a full year and the pieces are falling in place. A bit surprisingly since I don't use all of the formal techniques taught on how to develop a library. My engine suffers from lack of documentation at the moment.

Right now I'm in my late-beginnng stages, building of the foundations to make my library cross-platform and somewhat universal. So far it does what many libraries do, it detects the system, the compiler, and other things. My goal is to make it as extendable as possible by people who can understand the basics of how it is designed. I do so by making universal things optional before any subsequent dependant modules draw upon any independant modules. My goal is for it to compile in both c and c++ whenever possible.

What I am working on right now is the implementation of simple file wrapper, file system, and memory managing objects, wrapping both the standard c, and standard c++ library, I intend that the main parts can be compiled in both c and c++. Realistically it is a lot of work, but I already have much parts coded, over time, the most time I am spending is spent refactoring code that I've already written, to integrate working subsystems. And since it is based on the standard C and C++ libraries, people will be more likely to use it.

My file system works on a basic level as does my memory-management library. My math library is almost complete enough. My project is a combination of everything I've taught myself, currently teaching myself, and read from the internet.

Originally and naively I thought It was feasable that I could implement every minute detail of every sub-system myself. Faced with a vision and more r ealistic understanding AND education, I am leaving certain tasks for developed "plugin" libraries that I could include. Most certainly though, I will develop a 2d image library myself, then I will test my engine to the fullest by making a 2d game, perhaps with help, maybe paid. If it succeeds then I'll probrably make it open source.

Edit:
@tition

In this way, all system-dependent code is located in a single file, which provides pointers to all input and output functions to my system. All my system-dependent functions can be initialized with 0, signifying "do not call anything".

I'm doing it sort of like this, except I also put my system dependant code in a namespace.
And I place all my system dependant interfaces in one .h file and my wrapper (abstract) interfaces in another, with the implementation of the abstract drawing from the system dependant interfaces, at a given case. Do you understand what I mean...:| ?

[Abramus]

some sort of engine, definitely one that will allow the creation of games, but not necessarily limited to games

building of the foundations to make my library cross-platform and somewhat universal

my goal is to make it as extendable as possible

my goal is for it to compile in both c and c++ whenever possible

I'm not trying to discourage you, but be aware that with such attitude it's possible that you'll never make anything even remotely usable/complete. Trust me, I've been there, done that.

Food for thought: http://scientificninja.com/blog/write-games-not-engines

[DeXecipher]

@Abramus

I'm not trying to discourage you, but be aware that with such attitude it's possible that you'll never make anything even remotely usable/complete. Trust me, I've been there, done that.

Food for thought: http://scientificninja.com/blog/write-games-not-engines

nah man, I'm set on those goals. Its useable right now, just not complete, and no library ever really is complete, otherwise software would never get updated. Im not going to abandon this project EVER, because I have a vision for where it is going. Its a project that I will work on until I graduate, and it will be a major accomplishment when I make my first application with it. Which can be any application, I have a design already, I'm just piecing it in over time.

edit:

I've also read that article once before, and I'm aware of exactly the dangers of falling into a trap. If I wanted to make a game I'd use sfml, unity, udk, or something else right now. My goal is to be able to successfully design and engineer a software library. Then once the design and implementation is good enough I'll make an application with it.

[3qX21hU5]

Just make sure you know what should be in there, and what will be reusable in a multitude of projects and what won't be.

I'm not say you are doing this, but many people when they first set out to create a library or engine base it either around a specific game/program they want to create or make one that is so general that it has no use at all.

It's a very fine line between having it specific enough to a certain genre of projects and have it broad enough that it can be useful to more then one project. Like game engines for example, a lot of people set out to make one that will be able to make any type of game (FPS, RTS, RPG, ect.) and they end up with a engine that can make mediocre games but not a great game because the engine isn't specialized and optimized towards a certain genre (Or a few that are similar). So make sure you are not trying to make it do to many things.

But as long as you realize this and react accordingly you should be fine and if anything it will be a great learning experience. Wish you the best of luck with it.

[DeXecipher]

@Zereo
I appreciate the words of encouragement, thanks. I was coding moments ago from when I am typing this. I finished the timer class :). Now I can limit the fps of apps in the loop.