Lazarus
Programming => Operating Systems => macOS / Mac OS X => Topic started by: c_knowles4834 on October 24, 2021, 05:14:23 am
-
Hello all,
I was wondering if anyone knew of a way to have two applications talk to one another as they both run on the same computer?
Being that I am very new to the world of programming and want to challenge my abilities a bit, I had the idea of creating a messaging application that I could run with two windows that are independent of one another but can have text messages sent between them.
I have done some reading on this topic but cannot find anything substantial or conclusive to warrant a solution to my problem. Any advice will help!
Thanks,
-
One of the thing can be used to let (two) programs to communicate on the same computer is IPC.
You posted this question under MacOS sub forum, not sure but in the link below you can find an IPC demo (simpleipc) that works on Linux and Windows:
https://wiki.freepascal.org/Portal:HowTo_Demos#General (https://wiki.freepascal.org/Portal:HowTo_Demos#General)
-
I have a pair of Pascal programs talking to each other over ZeroMQ. Production usage is on Linux but programs also tested working on MacOS, and across network between Linux and MacOS.
ZeroMQ provides the transport. For application payload I used Protocol Buffers; other possibilities include JSON and msgpack.
- https://zeromq.org/
- https://github.com/DJMaster/zeromq-fpc.git
- https://developers.google.com/protocol-buffers/
- https://github.com/lalexs75/protobuf-fpc.git
-
One of the thing can be used to let (two) programs to communicate on the same computer is IPC.
I didn't know that either. Today, I learned something new this morning, thank you handoku.
Have a nice day brother.
-
...
You posted this question under MacOS sub forum, not sure but in the link below you can find an IPC demo (simpleipc) that works on Linux and Windows:
...
Will work fine on the Mac too. I use IPC in tomboy-ng, works exactly the same on all three platforms. Easy and reliable.
Davo
-
Sorry fellas for the confusion, I forgot to mention that I am working on a macOS (Big Sur v. 11.6 to be exact).
I appreciate the help though, I will give your suggestions a try!
Thanks!
-
My cross platform solution is to use shared memory. For Windows, you use a Mutex
http://msdn.microsoft.com/en-us/library/windows/desktop/ms682411%28v=vs.85%29.aspx
For Unix you use shmget
https://man7.org/linux/man-pages/man2/shmget.2.html
Here is my code:
https://github.com/rordenlab/MRIcroGL/blob/master/yokesharemem.pas/
You can try this out in a compiled application:
https://github.com/rordenlab/MRIcroGL/releases
Choose File/NewWindow to open a new instance. If the Display/Yoke menu item is toggled, clicking on one location in one image shows you the corresponding image in another.
I agree with @dbannon that IPC is a good solution as well. I would use shared memory if you have a very simple, fixed amount of data, whereas IPC allows a lot more flexibility.
-
If you start a new communication interface from scratch, I would recommend to use sockets. I know it might sound a bit of an overkill, but if you have a unit that does socket communication well, you can always use it later for inter-computer communication as well. Also it is probably more platform independent than other solutions.
I think developing it is a useful investment for the future...
-
If you start a new communication interface from scratch, I would recommend to use sockets. I know it might sound a bit of an overkill, but if you have a unit that does socket communication well, you can always use it later for inter-computer communication as well. Also it is probably more platform independent than other solutions.
I think developing it is a useful investment for the future...
This sounds reasonable, but according to the Wiki article (https://wiki.freepascal.org/Sockets) on sockets the unit is deprecated. Is this incorrect or are only parts of the Sockets package deprecated?
-
Correct.
Use fpsock from the fcl-net package instead.
-
This sounds reasonable, but according to the Wiki article (https://wiki.freepascal.org/Sockets) on sockets the unit is deprecated. Is this incorrect or are only parts of the Sockets package deprecated?
In fairness, he might have been making a general point rather than referring to a specific RTL/FCL unit or package.
However there are so many variants of sockets (TCP/UDP in both the inet and unix domains) and so many wrappers with varying degrees of sophistication (including lots of stuff based on HTTP, as well obviously as MQTT) that it's difficult to know where to begin.
The IPC unit (noting that this is distinct from the general topic of "Inter-Process Communication") is probably as good a place as any, but I'd suggest that it's always worth researching what it's using at a lower level in a given context.
MarkMLl
-
This sounds reasonable, but according to the Wiki article (https://wiki.freepascal.org/Sockets) on sockets the unit is deprecated. Is this incorrect or are only parts of the Sockets package deprecated?
In fairness, he might have been making a general point rather than referring to a specific RTL/FCL unit or package.
Indeed. My point simply was, that if you start from scratch understanding and developing various options to use for communication between application then why not to start it with something that is also working among computers. Nowadays, the most used is IP based communication with TCP or UDP. On any operating system, there surely is a mechanism to access the Internet, i.e. can communicate. Also on any machine I know, you can use localhost (is it called something else on any system?) to loopback your requests to your own machine. So anything that is good for inter-machine is also good for intra-machine, but not vice-versa.
My comment was a bit misleading for two reasons: "sockets" I meant TCP/UDP, but not unix sockets, as that is only for intra-machine communication. Also there is a "sockets" unit you found, but I did not refer to any particular implementation. Sockets is old, fpsock is recommended as a replacement, but you can go as "overkill" (sorry, if I offend anyone) as the otherwise amazing Indy.
-
If you start a new communication interface from scratch, I would recommend to use sockets. I know it might sound a bit of an overkill, but if you have a unit that does socket communication well, you can always use it later for inter-computer communication as well. Also it is probably more platform independent than other solutions.
I think developing it is a useful investment for the future...
This sounds reasonable, but according to the Wiki article (https://wiki.freepascal.org/Sockets) on sockets the unit is deprecated. Is this incorrect or are only parts of the Sockets package deprecated?
No, the wiki page is about the package. The Sockets unit is the recommended way.
Correct.
Use fpsock from the fcl-net package instead.
No, the FpSock unit is not cross platform and also prone to memory leaks. Use the SSockets unit which is a wrapper around Sockets and also supports SSL and which is the base for TFPHTTPClient, TFPHTTPServer and friends.
Sockets is old, fpsock is recommended as a replacement, but you can go as "overkill" (sorry, if I offend anyone) as the otherwise amazing Indy.
Again, no, the Sockets unit provided by FPC is the base unit used by things like TFPHTTPClient and such. The Sockets package provided by older Lazarus versions is deprecated. Also don't use FpSock.
-
My comment was a bit misleading for two reasons: "sockets" I meant TCP/UDP, but not unix sockets, as that is only for intra-machine communication. Also there is a "sockets" unit you found, but I did not refer to any particular implementation. Sockets is old, fpsock is recommended as a replacement, but you can go as "overkill" (sorry, if I offend anyone) as the otherwise amazing Indy.
I'd emphasise that unix sockets use the standard sockets API, they're distinct from pipes etc. As such and in particular because they don't rely on a numbered port, IMO they're to be preferred for same-host master-slave communications.
MarkMLl