I have a 64 bit cocoa project that needs to use a 32-bit rendering library, which I cannot port to 64-bit.
I decided to separate it to a rendering service, which will be compiled in 32-bit and will provide an interface for the library, and the main project, which will be compiled in 64-bit and will access the rendering service.
I am wondering what is the best way to do the interprocess communication. I am looking for a solution that will provide fast communication and easy api.
It seems that XPC (and specifically, NSXPCConnection) is the recommended solution nowadays. However, I'm not sure - is it implemented for 32-bit applications?
In addition, I need to pass a fairly large quantity of data (max ~5MB), and so I worry about the performance and speed of the XPC. Is shared memory mapping is possible/recommended in this situation? can it work in conjunction with xpc?
For 32-to-64-bit APIs, Apple does use XPC services in their own apps, like Pages, to migrate old data to a more recent API.
Although I have yet to get it to work using NSXPCConnection, and Apple's own apps use the functions found in xpc/xpc.h.
Related
This question follows the previous one below:
Easy way to guarantee binary compatibility for C++ library, C linkage?
I wondered if making interface functions of C++ DLL or shared library with C linkage brings forward compatibility of Compiler and of standard library.
extern "C" someAPI();
The most voted answer was saying that I am wrong. The answer recommended making it open-source. And never mentioned about COM or CORBA. Making it open-source is not always possible.
But recently I am reading books about Windows COM. And I think COM maybe brings the compatibility I wanted. And there is another thing CORBA.
So I wonder if these things, COM and CORBA, really brings forward compatibity of compiler and standard library?
I think network library ACE uses CORBA. And that is only one I know about CORBA.
Isn't CORBA popular nowadays?
What about COM? ActiveX is maybe disappearing but WDF(Windows Driver Foundation) depends on COM.
Thank you very much!
Yes, COM was created, among other reasons, to overcome source code (and .obj, static lib, etc.) reuse issues, whether that source is C/C++ or anything else.
The essence of COM (v-table layout + IUnknown, forget about registration, OLE, Automation, marshaling, and other additional stuff) is very simple (in fact, it's hard to make it more simple). Since it only relies on binary contracts, you can write COM client and/or server code using any language (and any platform, but in reality, only Windows uses it). So you can have a 32-bit COM client written in python talk to a 64-bit COM server written in C++ for example (well, this example in fact requires some cross process marshaling, so it's not pure lightweight COM).
COM is very far from being dead or disappearing (because it's, again, quite simple). "ActiveX" was a marketing / tech mix name, but it's basically COM, and is massively used in Windows, by Windows and 3rd parties.
COM over the physical network (DCOM) is indeed disappearing (in favor of other technologies, like Web, sockets, HTTP, REST, or in general technologies more simple than COM), and what's still used today is basically in-process and out-process COM (out-process is somehow DCOM on the same machine).
I know that CORBA was once upon a time a strong COM competitor (especially because it was available on multiple platforms, including Windows), but it seems to be seriously declining, also in favor of the same more simple technologies (web, etc.).
I wrote an application in a JS-based framework called Titanium. This framework doesn't have some functions, so I'm bundling autohotkeys, and using STDIN/STDOUT to connect the two. Autohotkeys has a cool function DllCall which allows to interconect with the operating system and should help me close the gap between the JS-based framework and the missing functionality.
To give you an example, Titanium allows me to bind to a specific port. But if I bind to 0 and let the OS pick a free port (as it should), it will work, but there's no way to tell which port it actually bound to.
Now since I come from web applications, DLLs are new to me; so I have a few questions:
Is there like a big doc with all the DLLs and all their methods?
How do I know if some methods are dependent on some services? I mean I've heard some rely on RPCs, COM, COM+, WMIs, etc. which a user can turn off and if it does, these methods won't work. Is there also a place where I can get more info on this?
Are there any off-the-shelf DLLs, with their methods, which I can trust that they will work 100% from XP up to 7?
Are there any access permissions I should know about? Are they documented.
If you also come from web programming, is there anything else I should be aware about?
Thank you very much.
You can find a (mostly) complete documentation of all Windows API functions (which reside in DLLs) either online on MSDN or offline using the documentation from the Windows SDK.
For example look at the documentation for SHGetSpecialFolderPath. There you can find various information, like the DLL (shell32.dll), any prerequisites (min. IE 4) and the platform availablity. (min. Windows 2000) Also security considerations are documented.
All API functions are documented more or less in this manner. A good starting point is the Windows Developer Reference. From there you can browse through the many API functions.
Basically the answer to every question is that you should search MSDN for the functions or APIs you are interested in and read the documentation there:
http://msdn.microsoft.com/en-us/library/ms123401.aspx
They document which operating systems the functions are available in so it should be easy to write something that works in Windows XP and up.
I've been using MYNetwork by the venerable Jens Alfke for an app of mine that allows devices to connect and share info over the network, it's actually a mission-critical part of the app. I tried writing my own wrapper for all of the C-level stuff you have to do for Bonjour, but it didn't work out so well, so I moved to MYNetwork.
It's been great so far, but the fact it's essentially opaque to me is causing trouble, as is that I want to move over to ARC once we can submit apps with it (there's a lot of Objective-C object references in structs, which ARC hates).
Can anyone recommend a similar wrapper, ideally that allows easy message passing between a client and a server over Bonjour as well as service discovery?
Just a thought- Would using ZeroMQ advertised and discovered by the stock NSNetService suffice? Separating the service pub/sub from the actual communication would allow you to use other bonjour libraries like Avahi on linux too. ZeroMQ is sufficiently simple to make wrapping trivial, yet powerful enough to cope with complex network topologies, fast.
I have experience with both technologies in isolation but not together although I see no reason why it wouldn't work. The only caveat right now is the limited body of collective experience of ZeroMQ use on iOS but I'd expect that to change over time.
You know you can disable ARC for specific files? So, you can just disable ARC for the library, and keep it on for your other files.
Disable Automatic Reference Counting for Some Files
I'm a .NET developer with some questions about a small Mac project coming up.
We are going to be creating a small program for Mac OSX. The software will need to have a simple UI (1 screen) and will need to consume a WCF web service.
Should we code on our Windows boxes or on Mac machines? We have a couple Mac Minis, but we mostly do Windows development.
What IDE/dev environment should we use? (Eclipse, Xcode, etc.)
How does Mac software deployment generally work?
...
No one has mentioned Java/Eclipse. Isn't that an option?
Here are two options:
Write in Objective-C, using Xcode on Macs
Write in C#, using Mono on Windows or on a Mac with SharpDevelop
The advantage of #1 is the resulting app will be much easier to deploy to others, but you might have trouble consuming the WCF service. It depends on what exact interface you are exposing and what the types of the parameters are.
The advantage of #2 is that you can use your C# skills. I don't know the state of WCF in Mono, and the GUI may not look native.
If you go with #1, the main issue will be using Objective-C. Since you are targeting the Mac, make sure you enable the Garbage Collector, or else you will have to also learn memory-management. If you use Xcode 4, it's similar in spirit to Visual Studio, although the details are different. For a simple project, following the tutorials will probably be enough -- I suspect the hard part will be interacting with WCF. To make your life easier, make the interface to the service extremely simple (simple parameter types and returns).
Your question is overly broad. You have two options:
When in Rome...: download Xcode, look at example apps, read Apple's documentation, find some tutorials, and learn Mac app development the usual way.
The Devil You Know...: look into stuff like the Mono project that will let you write a Mac app in C#, so you can use your existing libraries and don't have to learn Objective-C.
Which is better depends on your needs. If you just want to get a small app done and don't have a lot of time/money, I'd go with #2. If you're concerned about quality (compatibility libraries always have their quirks), I'd go with #1. My gut says #2 is better for you.
OK, this is basically just about any non-default OS API running on all different OS. But for my example let´s consider platform Windows, API SDL (Simple DirectMedia Layer).
Actually this question came to my mind when I was reading about SDL. Originally, I thought that on Windows (and basically any other OS) you must use OS API to make certain actions, like writing to screen, creating window and so on, because that API knows what kernel calls and system subroutines calls it has to do. But when I read about SDL, I surprised me, because, you cannot make computer to do anything more than OS can, since you cannot access HW directly, only thru OS API, from Console allocation to DirectX.
So, my question actually is, how does this not-default-OS APIs work? Do they use (wrap) original system API (like MFC wraps win32 api)? Or, do they actually have direct access to Windows kernel? Or is there any third, way in between?
Indeed, SDL is a wrapper for OS-specific calls, although with many simplifications and convenience functions. On Windows, SDL uses DirectX.