Background: This is for a university managed lab environment. Upper management wants to know how often users are using the various software we purchase for the labs. I've already implemented a solution for our Windows machines which consists of a client that tracks user process invocation and sends the results to a web service.
Now I need to create an equivalent Mac client but I have zero experience developing for the Mac platform and its various APIs. Our Macs are currently running 10.4, but will eventually be moving to 10.6 within the next year. I think I've got a handle on consuming the web service using something like gSOAP or even Mono. For the process tracking, I was looking at the Carbon Event Manager. But I've been reading that the Carbon APIs are on the road to being deprecated and I'd rather find something that will be supported moving forward.
Should I just use the Carbon stuff for as long as it works? Or is there some equivalent library I could be using that won't be phased out anytime soon?
Carbon APIs are not being deprecated, Carbon applications are. Feel free to use the event manager.
See The myth of Carbon’s 64-bit unavailability
Related
The last days I sent a new build of my app to Apple to fix some minor bugs with macOS Catalina. This evening Apple called me and explained that they are refusing the new version in the AppStore because the application monitors keystrokes. I use the Clipy/Magnet library (github.com/Clipy/Magnet) to manage the hotkeys. This library uses a Carbon API. Admittedly, I'm a little surprised - on the one hand that Apple is calling me directly via phone about this and on the other hand the use of this library has not caused any problems so far. The only thing I noticed about the new build was that Catalina asks for "Input-Monitoring" at the first start of the program. I've installed several other programs that also respond to global hotkeys and none of them require the permission for "input monitoring".
Does anyone have a similar phenomenon under Catalina or how do you solve the problem of query/monitoring global hotkeys?
I know of numerous applications using the MASShortcut framework, and I don't believe they've had issues with the store. It also uses a carbon API, but I think the issue in Magnet is the call to CGEvent.tapCreate which can globally monitor all keyboard input, and which MASShortcut doesn't use.
I need your advices what to use - Layered Service Provider or just load mine DLL in all
process and hook necessary functions using, NCodeHook or EasyHook library.
This is needed for inspection of HTTP traffic.
P.S. This need to be done for commercial application
Thanks!
Before making a decision you need to consider the following:
Code hooking:
AV doesn't like code hooking, if you're using a library that has external DLLs, run a check with AV total before committing to it.
Make sure the library's license works for you, for example, for LGPL you won't be able to embed the library as static without becoming GPL yourself.
I heard people managed to hook Metro apps, it's something to investigate.
If you have another code hooking app, it may conflict.
LSP:
The default MS sample/installer is broken.
You may get something working on a VM or fresh install, but to get LSP working properly across all OS and browsers, will take 6-12 months.
Will not work with Metro apps.
In Komodia we use a combo of LSP/WFP for our SDK, knowing what I know now, if I'd go back 4 years, I'd use LSP all over again.
Good luck.
Using Easyhook will be a nice way to do it check the following http://www.sghaida.com/easyhook-for-systemcall-hooking/
Apple has killed Carbon for 64 bit applications. I've got a pile of legacy code that targets carbon UI widgets that I'd like to keep alive for a while. Most of it is in the form of plugins and bundles that will have to go 64-bit in sync with their host platform.
The choice that Apple seems to be assuming is to throw all the legacy code away
and rewrite using Cocoa. It's not going to happen in the short run, if only because
the same legacy code is tied to a PC binding as well.
I'm considering 3 Options
(1) Dive into cocoa, create a compatibility package that supports the small subset
of carbon that I actually need.
(2) use Cocoatron as the new target. In the short run bridge carbon-to-cocotron, and maybe in the longer run convert to cocoatron native for both mac and pc. (ref: http://cocotron.org/)
(3) use QT as the new target. See option (2). (ref: http://qt.nokia.com/)
What I would really prefer is a fourth option, such as a bootleg copy of the 64 bit
Carbon beta that Apple killed, or a compatibility package explicitly intended just
to emulate carbon.
I would recommend you choose option 1. Creating a Cocoa UI wrapper for your code will likely not be as complex as you think. A common way to create a cross-platform app is to create the bulk of the app in cross-platform C++ and use Cocoa/Objective-C++ for the Mac UI and one of the Windows APIs for the Windows UI.
This option also has the advantage that it is fully supported by Apple and the APIs are stable and mature.
Cocotron is a nice idea but as of now it's not mature enough (in my opinion) to provide a robust cross-platform solution. I know there are successes with it but the sample size is small.
Qt is an option. However, it suffers from a very un-Mac-like UI. Using a Qt app on the Mac always feels like a quick port rather than a native app, and this is unlikely to ever change.
The "bootleg Carbon runtime" is just a fantasy, there is simply no way to get that working reliably and absolutely no chance to distribute it. You will need to find another way.
I am wondering what technologies are used by the new Mac OS AirDrop and if there is a way to use it on windows.
You know that AirDrop is a feature that will be introduced as part of Mac OS X Lion (version 10.7), right? That version of the OS is not even out yet, and it won't be until later this summer.
Furthermore, I assume that the handful of lucky developers who have a pre-release copy are under a strict non-disclosure agreement (this is Apple, and that's pretty standard policy in the industry anyway), which would keep them from giving any details about the feature in a public forum such as this one.
But, since I am not one of those lucky developers, I suppose I'm free to do a little speculating about how it might work. Presumably, it takes advantage of Apple's existing Bonjour network service discovery protocol (formerly known as Rendezvous) to locate other users nearby whose devices support AirDrop. The rest of the pieces have been part of Mac OS X for years, they just haven't been wrapped up in a fancy, easy to use interface (really, that's about all that software development is about nowadays). There's always been rich support for peer-to-peer networking, you've always been able to share files with other users, users have always had a public folder, etc. (This is UNIX we're talking about, after all.)
Will it work on Windows? Maybe. Apple has been surprisingly good in recent history about including its Windows brethren in on the fun—iTunes, Safari, MobileMe, etc. But it doesn't always happen right away. Rolling your own solution for Windows (or any other platform) would be pretty simple, but there's no guarantee that it will be compatible with Apple's.
Bonjour happens at layer 3, so it may be a small part of it.
The real question is how does AirDrop work at layer 2.
Airdrop was reverse-engineerd by the https://owlink.org/ folks. They implemented a free Python version called opendrop as well. The implementation is (unsurprisingly) quite hairy as you need to setup a special Wi-Fi link alongside some bluetooth voodoo, but it apparently works. Or at least it works better than whatever we had before, which was those few question around SE:
Implementing the AirDrop protocol
Is it possible to listen on the Airdrop protocol with my Ubuntu machine?
I need to run a native program and retrieve the output in an Adobe AIR client side only application. I know that AIR does not allow access to native applications, so what is the best way to achieve this? I came across this solution which works on Windows, but I need something that works on Mac as well. I'd rather not have two separate solutions if possible. Any suggestions?
I believe that Shu might be what you're looking for. It costs money, but its an API and bundler for AIR applications that gives them additional functionality.
To quote their site:
Shu provides you the developer with a
toolkit of commands to extend the
system capabilities of your AIR
application, features include,
controlling external applications,
opening external files, database
connectivity and control, system path
retrieval and screen capture
functionality.
I believe that its cross platform as well.
Also see
http://www.merapiproject.net/
http://aperture.fluorinefx.com/