Hi,

I am a windows programmer but I have some little experience in programing c++ on Linux. I have a question that is coming from my windows background: I am looking for windows technology equivalents in Linux.

The 2 top ones for me at the moment are COM and DB providers.

Practically every MS application has a COM interface that is accessible to any other application. Even multi-platform open source software (like Firefox) build on top COM and do expose some of their functionalities via COM. Because of this it is very simple to write a vb script to manipulate a word doc for example. So what is the equivalent in Linux? If I want to write a script that manipulates some openoffice stuff, or want to embed a web browser into an application that I implement, what is the technology that I should watch out for? Similarly, if I want an app to use like java + C++, what is the boundary between the 2 technologies? In MS I implement a COM dll in C++ I can use that from C# and vice versa.

DB provider is similar. If I have Oracle, MS SQL and mysql installed on one box, I know there are mechanisms like ado, ado.net, odbc to manipulate the databases. Since all ado, odbc etc. declare an interface, programming against all these 3 databases is not extremely difficult. Obviously there are differences in the syntax etc. but I do not need to link against 3 sets of libraries. You can configure db providers in the control panel and you can query which databases a given PC has installed. Is there a similar interface in Linux?

Thank you for all answers! I hope my question makes sense.

Jozsef

I can't really speak to an equivalent to the first part of your question other than to suggest that it is fairly common to be able to access library functions from different languages; e.g., you can access C functions from FORTRAN (and vice-versa) and the like.

Data bases, however, are accessible via ODBC; e.g., OpenOffice.org/LibreOffice.org Base, as well as JavaScript, Perl, PHP and the like. Also, all the RDBMS I know of have an API interface built in (C, C++ and perhaps other) -- that typically won't be cross-RDBMS (you generally can't access MySQL from Oracle -- or maybe you can, I've just never heard of anybody actually doing that, it's more-or-less unload from one, load into the other).

Hope this helps some.

1 members found this post helpful.

In Microsoft's environments, Microsoft owns every piece of the pie ... including (if they can talk you into it) the database server. They own all the plumbing, as well as the programming languages that are commonly used. As Einstein Bagels puts it, "the whole schmeer."

Linux and Unix are not so restrictive. They have implemented open-standard interfaces such as ODBC, but not proprietary ones. Furthermore, in their implementations, they cannot and do not embrace what Microsoft endlessly preaches ... "there is no world but Microsoft's ..." There are many dozens of programming languages available for use, and no one "owns" any of them. Linux and Unix are cross-platform, running on everything from cellular phones to the biggest mainframes.

These characteristics are visible throughout the system.

I have not heard about a popular and widely used COM alternative on Linux. It is possible that technology exists but I do not know about it. AFAIK, there may be several projects on source forge (such as xcom which appears to be dead and isn't normally included in distributions). Afaik WINE implemented COM as part of their compatibility layer, but it works for applications used by WINE (or linked with winelib) only. So my guess is that you'll have to stick with shared libraries (yes, I know it is not the same thing).

1 members found this post helpful.

tronayne,
Thank you for your answer. I guess the starting point to search for such interfaces is to google productname + sdk. The learning curve seems fairly steep. Like with firefox I do not even know where I'd start.

I have also figured (should have figured it already) that one can start at the /usr/src/include directory to see if there is something useful there. Is this really a good way?

sundialsvcs,
Please do not get me wrong I did not want to compare the "goodness" of technologies and surely did not want to start a political argument. What I am looking for is learning how Linux guys can do what I can do in windows. I feel lost in the above written scenarios even though I have linux at home for 5 years now and I have implemented a few applications in C++ on Linux with automake & QT.

(I hate M$ for political reasons but that does not mean I would not admit that there are good things within e.g. COM or .net. I do not like things in .net e.g. C# as a language sucks in my opinion but the framework itself is not that bad. Just like: if I hate some countries it does not mean that I cannot appreciate some of their products. Obviously it is a valid decision not to buy anything from them, but if I did not admit that something good might come from them I'd lie to myself.)

SigTerm,
Thank you for your answer.

"you'll have to stick with shared libraries"
I guess this means I need to see what's in /usr/src/include. If not please correct me!

What are the usual ways a running application offers an interface so that you can connect to it and manipulate it form another process? Is this hidden because the library they provide encapsulates it? Or is there a technology like raw socket programming or a messaging system that applications let you communicate with them? (In windows the running object table is one such possibility that all MS products use)

Also, is it possible to trigger things on the GUI of another application? Similarly to the SendMessage thing in Windows.

Regarding shared libraries - start, from, say http://tldp.org/HOWTO/Program-Librar...libraries.html .

A much more fundamental work is this: http://www.akkadia.org/drepper/dsohowto.pdf .

In general, standard Linux (not Android) is "accessed" through 'glibc' which strives to be POSIX-compliant.

AFAIK there is no single mechanism to send specific messages to GUI applications, but there is IPC in general (signals, sockets, shared memory), so you can choose whatever you want. AFAIK, modern Linux desktops tend to use 'dbus': http://www.freedesktop.org/wiki/Software/dbus . Which most likely implies that you should also refer to the root URL: http://www.freedesktop.org .

1 members found this post helpful.

Thank you Sergei

Both OpenOffice and FireFox seem to use d-bus for this or that reason. This is a very good starting point and your answer was very helpful. Looks like OO communicates with Evolution via d-bus, and latest versions of firefox would not even build without d-bus being installed. I am going to check this out more to see what they actually offer over d-bus.

"but there is IPC in general"
Yep I know that these low level technologies are there in Linux, but this is not a standard high level communication technique. d-bus seems to be one.

My personal truth is that I'm using shared memory for IPC, and I have read about 'dbus', but don't use it myself. My case is audio, I wanted to implement my IPC in the simplest (and easily debuggable) way, that's why I'm using shared memory which is also mapped onto files ('man 3 shm_open', 'man 2 mmap').

I have played a little bit with dbus on kubuntu, looks like kde has a lot to offer over dbus, possibly they do their automated tests via this interface? I do not know but it seems they do register every (or at least many) gui elements and actions. This is something that is very useful to know about.

Openoffice also registers an interface but it does not do anything what the kde apps do, it simply times out at the start. Possibly it is broken, or it is broken in the kubuntu hat I have (10.4 I think). I did not find a firefox interface unfortunately.

The good side is that triggering actions in running apps is possible via dbus:
https://sites.google.com/site/jozsef...kcontents/dbus

Well if the app support it. Also this seems thousand times nicer and simpler than M$ COM so I love it :-)

> My case is audio, I wanted to implement my IPC in the simplest (and easily debuggable) way, that's why I'm using shared memory which is also mapped onto files ('man 3 shm_open', 'man 2 mmap').
In my opinion if you offer an interface to the crowd then either you re-implement what COM/dbus gives you: offering functions with typed parameters, return values, also possibly interfaces, or your interface is fairly difficult to use. If you reimplement, the receiving side also has to reimplement the receiver code. Or you offer a lib in which case you reimplement both sides.

On the other hand if you need an internal communication between 2 of your own components (you are the provider and the consumer) then shared memory can be perfect - you got rid of a dependency :-)

The statement in bold is exactly the case. I.e. the IPC is between my own components and is not meant "for the public".

I'll just leave this here before I fade back into the blackness.

- Joel

1 members found this post helpful.

Do you have any specific requirements in mind or just general questions?

The general philosophy of unix systems is very much different from MS.
We don't tend to plumb huge monolithic systems like office apps with stuff.
The general idea is to have small fast efficient tools that do a simple job
which is why a *nix server is so fast.

In fact I'd say office apps are very low down in the pecking order.
For instance, I've just set up a subversion repository for a lot of windows client
programmers. I integrated apache with subversion and a web front end for browsing
and they can submit changes with tortoise easily on their windows boxes.
It was pretty easily done.
It all works beatifully and is very rapid. Now could you easily do that on
a windows machine? (don't talk visual source safe)

I'm not starting an argument just pointing out that the emphasis in the unix world is
more back-end, server oriented, not front-end office oriented.


http://www.faqs.org/docs/artu/

I don't think that I am "starting a flame-war," nor "starting a goodness-war" by saying that the two platforms are different, and that you can encounter these differences in all sorts of ways ... especially when you make inquiries like this one.

Windows is like a big Italian family: when you marry one piece of it, you marry the whole shebang. Which is great if you love good red wine and pasta and for it to be served The Italian Way. (Q: "Is there any other way?" A: "No.")

When you step outside of that velvet box, you might be startled to discover that some things which you took for granted "on the inside" are not easy to do; and that others are not possible at all.

What I have said ... I have said simply as a statement of fact. Not in any way as a judgment of that fact. Windows is a vertically integrated system. Everything-else is not.

I couldn't agree more
windows is designed to be a tightly (heck, even the GUI runs in kernel space if i'm not mistaken which is a big no-no imho).

with Linux on the other hand, almost everything runs in user space and is developed separately by entirely different entities, not to say that there aren't standards that Linux adheres to, however a common interface is less likely to appear, but if i'm not mistaken there are shared libraries, stream pipes, and other interfaces, just not as neatly standardized as windows.

Yes it is a bit more confusing perhaps from a development standpoint, but this modularity is what makes Linux such a powerful and flexible operating system.