Analog of Com Programming in Linux/Unix

Analog of COM programming in Linux/UNIX

Sun RPC was supposed to be that. Then there was CORBA. Then GNOME Bonobo and KDE DCOP. Now it looks like D-Bus is latest fashion.

Is there an equivalent to COM on *nix systems ? If not, what was the *nix approach to re-usability?

The Unix model is built around the idea of lightweight processes that communicate with each other, through sockets, pipes, signals, and command lines. Historically, Unix didn't have threads (the POSIX thread model is only about 10 years old IIRC), but processes on Unix have always been much cheaper than on Windows, so it was more performant to factor functionality into separate executables than to allow a single program to grow large and monolithic.

In COM, you define binary interfaces that allow shared-memory communication. COM is tied to an object-oriented paradigm. In the classic Unix model, you define stream-oriented interfaces that allow communication over pipes, without shared memory. Conceptually, this is much closer to a functional programming paradigm.

The Unix model encourages making small programs that can be easily coupled together by a lightweight "shell", while the COM model encourages making large programs that expose "components" that can be reused by other large programs. It's really an apples-and-oranges comparison, since both models provide benefits and drawbacks for different scenarios.

Of course, modern Unix systems can have COM-like facilities. Mozilla has XPCOM, a cross-platform framework built on the same principles as COM. GNOME for a long time used Bonobo, which is conceptually very similar to Microsoft OLE, which was the forerunner to COM. But recent versions of GNOME have been shifting away from Bonobo in favor of D-Bus, which is more of an event/messaging pattern.

What is the closest thing to Windows COM/DCOM in the Linux world?

Yes, there are lots of things, but there isn't one as "Standard" as COM/DCOM. At least, in Windows, COM / DCOM are used by "Windowsish" stuff, and other RPC mechanisms are used by un-"Windowsish" stuff.

Linux doesn't have anything like that, instead things which need higher level RPC protocols typically use whatever their language provides, or a specific library which best suits an app's needs. Examples of that would be RMI in Java, Python's "pyro" module, etc, which will provide (some) functional parity with DCOM.

Corba is a bit heavyweight but some people apparently do use it.

A lot of applications roll their own RPC libraries. Don't do that unless you have to, it's nasty.

What would be the equivalent of Win32 API in linux?

You need to understand what syscalls are. On Linux, they are the lowest possible user land API (in contrast Win32 API probably mixes real kernel syscalls with some libraries functions. libc also does such mix on Linux). fork(2), execve(2), open(2), pipe(2), mmap(2), read(2), poll(2), close(2), dup2(2), sigaction(2) are important syscalls (but there are about 300 of them, see syscalls(2) for a list, which depends upon your precise Linux kernel).

Don't expect each Windows functionality to be available on Linux (and vice versa).

Don't even think of such an equivalent.

Get a different mindset on Linux.

(In particular, processes are very different on Linux and on Windows).

Don't forget that Linux is free software, and you can dive into the source code of every function you are using on Linux. Read it, search it, improve it.....

Read the intro(2) man page first, and several other man pages (notably syscalls(2), intro(3) etc...). Read also e.g. Advanced Linux Programming and Advanced Unix Programming.

Some libraries try to factor out and provide a common abstraction for both Posix (e.g. Linux) and Windows. In particular Qt (and also Gtk or FLTK or POCO, and Wt for web applications, and sqlite for databases).

Some open source server software (e.g. lighttpd, exim, postgresql, etc...) can run on both Linux and Windows (of course, after recompilation)

If you are interested about graphical interface, understand the important role of X11 (notice that the X11 server is nearest to screen & keyboard; most graphical applications are X11 clients). In 2016 or 2020, X11 tend to be superseded by Wayland (but you won't notice that implementation "detail" - a really major one - if you code against Qt or GTK)

If you write an application using only Qt and/or POCO calls (those not documented as being specific to Linux or Windows) in addition of standard C++ functions, it should be source portable from Linux to Windows and vice versa.

unix linux shellscript programming printing input arguments containing multiple words

Enclose the variable in quotes, since arguments are separated with spaces:

echo "$MAILING_LIST"
mailing "Error in Job"  " There were some records that couldn't be loaded into DB" " " "$MAILING_LIST"

Just like you did with "Error in Job". If you had left those quotes out, there would have been eight arguments.

What should I use instead of windows.h in Linux?

The missing typedefs (HANDLE etc.) aren’t your problem. Your problem is that Linux and Windows have completely different APIs, you cannot simply hope to port one to the other by replacing a few type definitions.

The complete platform-dependent portion of your code has to be replaced. Your first step is therefore to learn the Linux API. The best way of doing this is getting a book on Linux programming.

Furthermore, Linux doesn’t provide a default API for window management as does Windows so if you are programming a graphical application then you need to choose a windowing library as well.

System libraries in Linux vs. Windows

In general, most programs link against libc, even if they are written in another language. It provides the C standard library interface (like MSVCRT), POSIX features (the equivalent of certain parts of the Win32 subsystem), and wrappers around system calls. For example, Rust uses libc because it provides a portable environment to link against.

However, on Linux, you don't have to link against libc. Go chooses to make system calls directly, which means it can ship static binaries that have no runtime dependencies. This is possible because Linux guarantees a stable kernel ABI, but not all operating systems do this (e.g., macOS). So unless you have significant resources (like an entire programming language team), this isn't generally a smart move unless you're only working with a handful of syscalls.

I should point out that even Windows is intrinsically wired into the C language: it uses C strings (granted, usually wide C strings) for its system calls, and much of the kernel is written in C. Even if you were starting a kernel from scratch, you'd still need a general C interface, because virtually every programming language has a way to interact with C.

Is there a Core Linux API analogous to Windows WINAPI, in particular for creating GUI applications?

I think you're looking for something that doesn't exactly exist. Unlike the Win32 API, there is no "Linux API" for doing GUI applications. The closest you can get is the X protocol itself, which is a pretty low level way of doing GUI (it's much more detailed and archaic than Win32 GDI, for example). This is why there exist wrappers such as GTK and Qt that hide the details of the X protocol.

The X protocol is available to C programs using XLib.

Is there a Linux equivalent of Windows' resource files?

It's actually quite simple on Linux and other ELF systems: http://www.linuxjournal.com/content/embedding-file-executable-aka-hello-world-version-5967

OS X has bundles, so you just build your library as a framework and put the file in the bundle.

---

Related Topics