This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: glibc stacking up to Windows


I don't understand what battle is there to be won?

I write C++ programs for Windows, and for Linux, and have written
them for various UNIXen in the past. I like the services I get 
from libc. I like them a lot. I like the idea that we have an
API which works whether I write code for a server application,
desktop application, or for something else. If I write a GUI
app for X windows, I have to include the xlib and some other
library to get access to the graphics stuff; if I write a server
app, I don't have to care about graphics. I need different 
error handling based on the kind of application I write, and
my priorities change too, based on the environment I am targeting.

I have written code to copy a file, I don't know how many times,
as I have written code for many other features which are already
implemented in some library. And I like things that way. It 
gives me flexibility to handle each case as I wish.

The windows APIs, on the other hand, have different cutting points;
for one, the windows OS is built around having a graphical interface;
it's part and package of the OS. Unix takes a different approach.

When I studied Windows programming, I read books from Microsoft
Press (Charles Petzold et al). When I learned UNIX 
programming, I read books by Richard Stevens (UNIX Networking,
Advanced programming in the UNIX Environment etc.). 
I enjoyed both, and still do. I think it's great that both
environments have great tools and great books which guide
you in how to go about writing good programs.

I would suggest that you read a good book on UNIX and enjoy it.

P.S. the Apache project has a Linux/Windows library (apr.apache.org) which has 
     various file system related functions. I don't think there is "copy,"
     but it might still be worth a peak for you.

     www.boost.org might also be of interest; it's a site for portable C++
     library development. It might be more pertinent to discuss this issue there.




Troy Korjuslommi                Tksoft Inc.
tjk@tksoft.com





 



> 
> Alexander Shopov wrote:
> 
> > 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).
> 
> http://www.gnu.org/software/libc/manual/html_node/File-System-Interface.html
> 
> Delete files, rename files... just don't copy files. "Oh, but it is SUPPOSE to be that way..." Yea right!
> 
> Fine, the "science" behind copying a file is much more involved than deleting and renaming them. That is up to the people writing the library to take care of for me. When I see a 
> "File-System-Interface" I expect it to have an extensive list of filesystem related functions. Copy is pretty basic in that regard, thus glibc fails in my opinion.
> 
> > 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.
> 
> Yes, could fork it myself... but then how many boxes would I ever find with the custom glibc with the mission functions added in? No, either the API is in the library, or it does not exist.
> 
> > 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
> 
> Alas can't. The OSS/FS project this will be a contribution to is an IBM project they released under CPL which they love. CPL can not have any GPL "tainted" code in it.
> 
> > 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).
> 
> Basically stuck here due to the CPL vs GPL license compatibility.
> 
> > B. Use some other convenience library.
> > You will have to find the one to your taste. If not - write such one.
> 
> The project has restricted adding additional library dependencies... so would have to dig through what is already imported but I expect glibc is by far the cornerstone of the imports... doubt I will 
> find an import there that magically has a CopyFile() type API.
> 
> > C. Script the bloody thing.
> > C sucks. Compilation sucks. Linking sucks. ;-)
> 
> Yes well, I don't think "scripting" belongs inside an interpreted language... soon it would be a patchwork quilt, not an interpreted language! ;-)
> 
> > 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
> 
> Again, another add-on lib.
> 
> -- 
> Michael Lueck
> Lueck Data Systems
> http://www.lueckdatasystems.com/
> 
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]