Is there an equivalent to Linux DBus on OSX? I mean, is there a "message bus" available by default on OSX?
Disclaimer: OSX newbie here.
If you need to use DBus you can install it via Homebrew.
Homebrew is a package manager for OS X providing a lot of libraries which where mostly written with Linux as their primary target.
The DBus package can be found here
However, this is not installed by default and if you intend to write Cocoa applications the way to go would be to use the (distributed) notification center as mipadi explained in his post (which you also accepted).
If you need a robust middleware for communication you can also have a look at IceTouch from ZeroC which is a Cocoa library for using the services and functionality offered by their Ice framework.
The package contains IceStorm for example which is a publish/subscribe server or the IceGrid service which can be used to build large scale distributed systems
Probably the closest analog would be distributed notifications (or notifications for same-process communication). It's not a perfect analog, but it fits into roughly the same niche. You can read more about it in Apple's Notification Programming Topics, particularly the part about the distributed notification center.
There's Mach's ports, which will probably do what you need: http://en.wikipedia.org/wiki/Mach_(kernel) .
You could check DarwinPorts. It should include the dBus libraries.
Related
I'am going to communicate EtherCAT master(CX2020) with Linux OS PC(ubuntu) for storing value from PLC on server and writing also.
By EthearCAT network protcol, it should be availave to communicate with windows plc installed twincat.
But I couldn't find the way for Linux.
Is there any solution?
There are various ways for you to communicate with a CX2020 from Linux, it all depends on your requirements and what the usage is for.
Without knowing anything about those, one option is to use the Beckhoff ADS protocol. All Beckhoff PLCs have by default ADS installed on them and you can
(with the right credentials setup for ADS) communicate with the ADS-library. The good thing about ADS is that it is open-source, and thus it's possible to
get the code for Linux.
The ADS sourcecode is available at:
https://github.com/Beckhoff/ADS
You basically need to:
Compile/Install the library on your Linux machine
Create an ADS/AMS-route to your CX2020
Create a program that uses this route to communicate with the PLC
With ADS you can access the variables directly in the CX2020 memory (both read and write!).
There are many finished wrapper libraries available for all common programming languages that you can use directly in Linux. If you're up to Python, I would
recommend checking out PyADS (https://github.com/stlehmann/pyads), which has a good user base and many examples available all around the net.
Note: There is a similar question called 'installing nodejs on windows machine'.
And various answers explaining how by installing cygwin you can get it working there.
now, I don't want to install cygwin.
I just wish I could run nodejs on a windows box.
I want a "nodejs.exe" to kick off.
Can somebody explain to me
1) why nodejs has not been ported on windows - what are the technical reasons for not providing an exe ?
2) are there any plans to have nodejs on windows ?
I really would like to use it but I can't accept that I have to accept cygwin.
That's just not right.
Update:
For optimum node on windows development I recommend you use the Windows Azure powershell for node.js. It's a powershell optimised for using node, npm and the azure APIs. (the azure apis are optional. I would still use this powershell if I didn't use azure).
When : v0.6
Currently you can get a binary file that (kind of) works under windows. Go ask on the node.js IRC channel. They'll hook you up.
Basically if you read up on node.js road plans you will find that proper windows support is planned for 0.6, we are currently on v0.4.7 and the v0.5.x beta is in full storm.
I won't give an ETA but it's soon.
IRC can be found at the Community links
PDF showing v0.6 road plan
July 2011 update:
#nodejs v0.5.1 is the first to ship with an official Windows executable. We're hoping to get some good feedback.
Microsoft has officially gotten involved with joyent in making node.js run natively on windows.
Running Node under Windows presents several technical problems, mostly related to how Windows' internal design differs from that of Linux and the "change in mindset" required to port Unix applications to Windows.
Background
Linux was designed to be a replacement for Unix, a well-known multitasking operating system, so from day one it has been a multi-user/multi-process, server-oriented operating system. The idea of multiple processes sharing system resources is key to its internal design.
Windows was initially designed as a single-user/single-process desktop operating system and so did not support shared access to system resources. In 1993 Microsoft released a newly redesigned version of Windows--called Windows/NT--to better support the shared resource, multitasking model required by servers, but due to its existing installed base of users, Microsoft required NT to also support all the features of its single-user/single-tasking forebearer.
Windows 7 is a direct descendant of NT and Microsoft's need to support legacy users continues to this day (and in the opinion of many, has severely muddled Windows' internal design.)
Further, Microsoft hired a systems architect named Dave Cutler to design NT. Dave is best known for designing a competitor to Unix called VMS, the internal design of which differs significantly from that of Linux, which has caused a lot of problems for developers interested in porting their Unix programs to Windows.
The clearest example of this "impedance mismatch" between the internal design of Windows and Linux is how they handle event-driven, non-blocking input/output (io) on which Node relies to perform its (apparent) multitasking magic in a single thread of operation.
Linux supports two system-level functions called select() and epoll() which can be used to asynchronously inform a process of changes within the operating system that affect it. Node relies heavily on these functions but Windows doesn't support either, relying instead on "Change Notifications" (mostly) to handle event-driven io.
I'm moving from windows programming (By windows programming I mean using Windows API) to Linux Programming.
For programming Windows, the option we have is Win32API (MFC is just a C++ wrapper for the same).
I want to know if there is something like Linux API (equivalent to WINAPI) that is exposed directly to the programmer? Where can I find the reference?
With my little knowledge of POSIX library I see that it wraps around part of Linux API. But what about creating GUI applications? POSIX doesn't offer that. I know there are tons of 3rd party Widget toolkits like gtk, Qt etc. But I don't want to use the libraries that encapsulates Linux API. I want to learn using the "Core Linux API".
If there are somethings that I should know, please inform. Any programmer who is familiar with both Windows & Linux programming, please map the terminologies of Linux world so that I can quickly move on.
Any resources (books,tutorials,references) are highly appreciated.
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.
What you must understand is that Linux is very bare as to what is contained within it. The "Core" Linux API is POSIX and glibc. Linux is NOT graphical by default, so there is no core graphics library. Really, Windows could be stripped down to not have graphics also and thus not have parts of the win32 API like GDI. This you must understand. Linux is very lightweight compared to Windows.
For Linux there are two main graphical toolkits, GTK and Qt. I myself prefer GTK, but I'd research both. Also note that GTK and Qt exist for Windows to, because they are just wrappers. If you go take a look at the X protocol code for say xterm, you'll see why no one tries to actually creating graphical applications on top of it.
Oh, also SDL is pretty nice, it is pretty bare, but it is nice if your just needing a framebuffer for a window. It is portable between Linux and Windows and very easy to learn. But it will only stretch so far..
Linux and win aren't quite as different as it looks.
On both systems there exists a kernel that is not graphical.
It's just that Microsoft doesn't document this kernel and publishes an API that references various different components.
On Unix, it's more transparent. There really is a (non-GUI) kernel API and it is published. Then, there are services that run on top of this, optionally, and their interfaces are published without an attempt to merge them into an imaginary layer that doesn't really exist.
So, the lowest GUI level is a the X Window System and it has a lowest level library called Xlib. There are various libraries that run on top of this one, as you have noted.
I would highly recommended looking at the QT/C++ UI framework, it's arguably the most comprehensive UI toolkit for any platform.
We're using it at work developing cross platform apps that run on windows, osx and linux.
It also runs on Nokia's smart phone Operating System Maemo which has recently been merged with Intel's Moblin Linux OS, now called MeeGo.
This is going to sound insane since you're asking about "serious" stuff like C++ and C (and the "core linux API"), but you might want to consider building in something else. For instance:
Java Swing (many people love it! Others hate it and call it obsolete)
Mono GTK# (C# or VisualBasic or whatever you want, lots of people say it's pretty cool, but they're not not that many people)
Adobe AIR (ActionScript, you might hate it)
Titanium (totally new and unproven, but getting a lot of buzz in the iPhone world, at least)
And many other possibilities, some of which let you work on multiple platforms at once.
Sorry if this answer is not at all what you're looking for. The "real" answers on Linux are "pick a toolkit," which is also no answer at all :)
Have a look at Cairo. This something roughly similar to GDI+ and is under the hood of some of of the few usable GUI programs for Linux i.e. Firefox or Eclipse (SWT). It wraps most the natsy and ancient Linux stuff for you into a nice API that runs on most Linux installations without locking you into a entire subsystems like GTK or QT.
There is also the docs for the two different desktop platforms: Gnome and KDE that might help you down that road.
Is it possible to write a mobile application with J2ME and whenever we want to implement a functionality not offered by J2ME call native mobile API ? (kind of like what is done with .NET, whenever you need something not provided, you just call the Win32 API from the .NET platform).
While JNI is not officially supported in J2ME, the Symbian implementation of J2ME obviously uses something very similar.
Since most J2ME APIs have a corresponding Symbian OS C++ API, what Symbian did (a lot) is develop adaptation layers between the 2.
Between that and the new modular architecture of the IBM J9 virtual machine (from Series60 3rd edition feature pack 2 onward), it is technically possible to add a new API to the virtual machine without actually needing to recompile most of a handset firmware.
However, third party developers simply are not allowed to do it without a lot of help from the handset manufacturer.
A loopback socket connection is the solution that people have tipically implemented to transfer data accross the language barrier. Large-scale deployment is not the easiest task, though, as you technically need to install 2 applications on the device. Once you understand the threading model of the Symbian J2ME implementation, you also realize how ugly and inefficient a hack it is.
When you reach that kind of issue, it's time to learn Symbian OS C++ and do it right.
No. That's not possible with Java ME.
Only sort of. Actually it is possible but not directly. You can write a native server that listens on a local socket and send requests to it from your Java MIDlet. Someone even released a framework to do this called MIDP-JNI (as opposed to real JNI). Obviously the form of the solution imposes some limitations on what you can do with it but it isn't actually impossible.
Be aware that using this approach can make your application much more complex to debug.
If you are specifically looking out for Nokia/Symbian, then APIBridge http://wiki.forum.nokia.com/index.php/J2ME_API_Bridge_Interface could be a solution. Typically it is the 'official' version of 'native server on local socket' kind of thing. The APIBridge is 'extensible' & you can write your own 'plugins' for your suitable 'low-level' task.
I am planning to use SCTP for a embedded Linux project. Anybody has some comments on SCTP usage, mostly in one-to-many mode? Did it beat using a home-made UDP-based equivalent solution?
I control the network environement and all devices involved, so compatibility is not an issue.
I have made extensive use of lksctp and have found it to be robust and interoperable with many other implementations of sctp. The standard for the sockets API for SCTP is still evolving but is quite mature and I would expect any further changes to be backwards compatible.
I would use it with confidence.
The ACE library has a performance test for SCTP, so I would assume that it works.
Currently these programs provide the only example code on
how to use ACE's wrapper-facades for SCTP. In the future additional
code will be placed in the ACE_wrappers/examples/IPC_SAP/SOCK_SAP
directory.
Using a framework like ACE is a good idea anyway, as it alloes you to program on a higher level and shields you from the error prone low level details of socket programming. As an additional bonus your code will be portable to all platforms that ACE supports.
Best answer is the comment:
Also, SCTP support in Glibc is less than ideal (in other words, non-present) -- you must use the libraries from lksctp, and it's not entirely well-integrated into the normal sockets API. Just one more reason to use a nice library that encapsulates the low-level functionality :) – ephemient