Re: glibc stacking up to Windows

[Alexander Shopov <ash at contact dot bg>]

> "The GNU C library is primarily designed to be a portable and high performance C library."
> 
> Sounds good to me.
Nope, you missed this:
"C library" does not simply mean a library of functions usable from C.
A "C library" has a meaning of bunch of specific (and standard)
functions.
Now if you have several, completely different environments, each of
which implements the same library - you get your program to compile and
run everywhere (at least theoretically).
Different environments can be really wildly different - Windows,
GNU/Linux, embedded devices, IBM's exotic mainframes, etc. etc.
If your implementation of the "C library" has those functions you
request and an application programmer uses them - his/hers program stops
being portable.
You stick with the flock.
http://en.wikipedia.org/wiki/POSIX

> You seem to desire to start religious OS battles, not answer my question.

Nope, he does not. What you are asking is simply _never_ going to
happen. At least - not unless you get the committers to the source
repository of GNU libc bribed (if money does not get them to do it - you
can try exotic sexual favors - this works sometimes).
But then - as the software is free software - you will most probably get
someone to make a fork of this mutated libc and things will get back to
normal.

>  On Windows, Win32 and the Windows API's are the "core" API's available to programs written in C.
Good for Windows then.

>  On Linux it would appear to 
> me that glibc is the equivalent library of functions available to C. Is this not what glibc is to Linux?
In a way - you are entirely correct.
Still - that will not do you any good, I am afraid.

And for one thing - GNU libc runs fine on Windows too - take a look at
this project:
http://www.cygwin.com/

> My program needs to simply COPY A FILE! Also, figure out what file has been specified, and arrive at the fully qualified filespec based on what it was provided. I asked how Linux C developers do those 
> sorts of things since it would appear glibc does not offer API's to do so. What, no one copies files on Linux?!
You can take a look at the sources of cp here and see how this is implemented:
http://cvs.savannah.gnu.org/viewcvs/coreutils/src/cp.c?rev=1.220&root=coreutils&view=auto
(Nope, it is not that trivial).
(Nope, you do not get a singe API call for every wish.)

> Enough of the attitudes and let's talk results... like getting a bloody file copied. >:-|
Another way was shown by Ulrich.

>  The answer is not "well glibc has always been that way".
You have one more guess.

>  Do you Linux folks want to win the battle or the 
>  entire war... make your decision.
Well, not intending to be an arrogant boaster, but yeah - we are winning
the war and battles. One of the reasons is keeping some standards.

>  You can win the battle of why not to implement CopyFile() in the C API... but HOW does that help you win the real war?
OK, enough of this overly cliched "war" analogy (make love please).
You have several choices:

A. Learn the "C library" API. Reimplement what you lack.
  (Do not copy-paste from the coreutils source as it is copyrighted,
unless you understand the proper way to do it).

B. Use some other convenience library.
You will have to find the one to your taste. If not - write such one.

C. Script the bloody thing.
C sucks. Compilation sucks. Linking sucks. ;-)

D. Use winelib which reimplements Win32 API on GNU/Linux (and other
systems as well). Leverage that knowledge you have on the Windows C API.
http://www.winehq.com/site/winelib

Which way you chose is entirely up to you. You gain things and you lose
things. You will decide.

Things are somewhat different here. Still - welcome to the real world,
Neo.

Kind regards and pardon the silly remarks on my part, but take things
more lightly - at least initially.
You may still not like them, but at least you will not be that
frustrated.

al_shopov