Author Topic: [Email suggestion No. 4] OS compatibility (layer) / libc2 || libc2core  (Read 1016 times)


  • Newbie
  • *
  • Posts: 10
    • View Profile
   C and C++ are known for requiring a lot of work when one wants their code to be compatible with more OSes, generally to support Linux, Mac OSX and Windows. That usually translates to a lot of macros, especially many #ifdef _WIN32 ones.
   C2 is the evolution of C which aims to evolve all "the" bad or aged aspects of C. My suggestion is to create a library, which I could gladly do, called something in lines of libc2 or libc2core (since libc2 already exists, frankly), which would abstract the portability problems between POSIX-ish systems and systems like Windows, which are only partially POSIX-compliant (and aren't especially at places where it hurts the most) and throw in a few more functions/types/symbols to refresh the old libc, which is also aged.
   A great example is zed_net by ZedZull, which handles the great incompatibility problems between using sockets in POSIX and Windows. The link is to my fork of zed_net, since the author frankly deleted the original repo for reasons unknown. In other words, the library itself could be like a libc extension and compatibility layer specifically made for C2. I would like to create it, if you like the idea, since I like making portable software.


  • Administrator
  • Newbie
  • *****
  • Posts: 11
    • View Profile
I'm currently working on intergrating a generic library system, and especially libc. What C2 cannot
currently solve is the entire libc incompatibility between different systems. This is just too much. One
future solution that would get rid of a lot of legacy is to rewrite a libc in C2 itself, but that is a separate
project. Anyone?

But what C2 could do is to make the dependency on a libc less inherent. So you can easily say I don't
want my program to depend on any system library. This is also usefull for cross-compiling etc.

One other funny conclusion I came to while working on a library system is that essentially, solving
cross-compilation (issues) is solving the library problem (or vice versa)
. Think about it. Much effort is put into making
sure your program uses a certain version of some library instead of the default (system) library/headers.
This part will certainly be solvable!

What you see in other, new/modern language like Rust/Go/Swift is that they don't rely on system-installed
libraries so much. If your program needs some libX, they just download it into a local build directory and use
that. C2 will allow more fine grained control of which library will be used (system, user, local, etc)