This article covers Win32 API mapping, particularly process, thread, and shared memory services to Linux on POWER. The article can help you decide which of the mapping services best fits your needs. The author takes you through the APIs mapping he faced while porting a Win32 C/C++ application.
Migrating Win32 C/C++ apps to Linux on POWER
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Although there is no inherent value proposition in most of the POWER architecture, the article is also a good tutorial on the general move from Windows to Linux. Thank you, IBM, for your investments in Linux.
some good articles there at IBM.
This is a great Case Study in why Linux will ALWAYS be playing catchup to Windows.
Lets see here :- To get the modern Win32 APIs to run on a 30 plus year old OS is to add another ‘layer’ of operations due to the nature of the crude code structure of the antique *NIX.
I guess IBM has started a comedy club for geeks.
Have a great 4th of July everybody.
Well, it’s not too difficult to come up with bad points about Win32 either:
The way of creating threads and processes is absurdly complex on Win32. I have tried to open a bidirectional pipe from my webserver application to PHP, and even with the MS-SDK Help I have not succeeded in that.
Also, it seems that you can’t do asynchronous IO with pipes on Win32, as the select() call only works on sockets, and pipes can’t be put into async mode like you can do with files.
There are still too many API’s on Linux indeed. For example, now that you have the C library functions fopen, fread, fwrite etc., that work on files, pipes and sockets, why still leave the old, worse performing read() and write(), that only work with files, available to the developer?
To get the modern Win32 APIs to run on a 30 plus year old OS is to add another ‘layer’ of operations due to the nature of the crude code structure of the antique *NIX.
No, if you are porting an application working on one API (e.g. an OS) to working with multiple APIs (e.g. two OSs) then you add a portability layer to keep the differences out of the main application code. It would be the same if porting a Linux application to also work on Win32. Idiot.
I suppose you know that fopen, fread, etc. are standardized C and C++ functions, while open, read, … are POSIX conformant. You do not just throw away standards compatibility. Also, write, read, … are not inherently slow. They are probably unbuffered, but that does not mean they are slow. As far as I know, there exists still an implementation of the C library functions in glibc which uses underlying POSIX functions.
Also, you can write for example to a socket with write(). You will gain more control if you use send/recv for sockets, but not with fwrite/fread.
Actually, I would think that system calls that can be “very inefficient”[1] are not the ones you choose for a well-performing application, right?
Also, I understand that read, open etc. are for POSIX compatibility. But if the same thing is served equally well or even better with standardized C functions that are also available on non-POSIX platforms, why not hide the POSIX functions unless you use “cc -DPOSIX” or something like that?
Or are there any real advantages of using the POSIX functions, except for special UNIX functions like fstat?
[1] Beginning Linux Programming
Are POSIX open/read/write really slow? I do not know a technical reason why they should be. And I know that some libraries use the POSIX primitives. The manual of glibc, version 2.3.3x contains this quote:
“The `read’ function is the underlying primitive for all of the functions that read from streams, such as `fgetc’.”
But I could still be wrong, and the POSIX functions are slow, in this case, I would appreciate some more information (I do not have access to the book you mentioned currently).
But certainly the POSIX functions have advantages for *some* applications. One main one is that fcntl and ioctl are working on file descriptors (Tho you can extract a file descriptor from a C FILE* on some systems).
The glibc manual gives some more reasons for using them.
Of course, if there are no specific reasons for using them, the C and C++ library functions are to be preferred, I agree fully on that.
The C standardized stream functions (fopen,fread,…) call the system primatives open,read,etc. The POSIX functions define the API for an operating system; the C functions define the API for a language. As such, the C functions are only available for the C.
The posix functions are not slow. If one properly uses them (i.e. read a block of chars, buffer what is not consumed; write page-aligned, block-length buffers), the speed is greater than what can be achieved with the C stream interfaces.
fstat is not a specialized unix function. The function is necessary to conform to SVr4, SVID, POSIX, X/OPEN, BSD 4.3. How can one easily determine the size of a file without it?
Furthermore, you cannot do everything necessary with the C stream interface. I does not provide a means to open sockets and other types of IPC.
The POSIX read()/write() work on files, sockets, shared memory areas, wallabies, and anything else that exposes a file-like API. The difference between the two is that read()/write() are low-level APIs optimized for block-level access, while fread()/fwrite() are high-level APIs optimized for character-level access. Also, read()/write() are OS-level primitives upon which library-level primitives like fread()/fwrite() are implemented. fread()/fwrite() are just the calls for the C library. The C++ library has it’s iostreams, while other languages have their own APIs built upon read()/write().
The UNIX API is 30 years old because it works and doesn’t suck. Meanwhile, even though Win32 is newer, Microsoft has already had to replace it (see .NET, one of the rare MS APIs that doesn’t suck all that bad). Even though it’s a simple library of a few hundred calls, POSIX is every bit as powerful Win32. It’s powerful, orthogonal primitives are much more elegant than Win32’s weak, case-specific primitives.
For example, just see how you’d map a file into memory in Win32:
CreateFile(…);
CreateFileMapping(…);
MapViewOfFile(…);
CloseHandle(…)
Now, in POSIX you’d do:
open(…)
mmap(…)
close(…)
The first way has 4 functions with a total of 20 parameters. The second way has 3 functions with 10 parameters. And mmap() is one of the most complex system calls in POSIX, while MapViewOfFile() is pretty average in Win32! To really get a feel for how badly Win32 sucks, compare CreateProcess(), which has 10 parameters, one of which is a structure with still more parameters, to fork()/execv(), which has a combined total of 2 parameters.
This article: http://www.chami.com/tips/delphi/122096D.html&e=912“ rel=”nofollow”>http://www.google.com/url?sa=U&start=2&q=