For Windows there is Win32 API, what about for Mac? On Wikipedia
http://en.wikipedia.org/wiki/Cocoa_(API)
it is said that Cocoa is "one of" the API... what about the full story?
At what level? The low level API is largely but not entirely FreeBSD, and below that there is still a Mach API (some things still use Mach ports for IPC, I believe; at least, launchd supports them). At the upper level are two APIs: Cocoa and Carbon. Cocoa is the native API; Carbon is intended for programs ported from older MacOS. (Which includes parts of OSX itself; for a long time Finder was a Carbon app.)
The Windows situation isn't all that different, actually; there was for a long time a Win16 emulation API present in 32-bit Windows, and in the early days of Windows NT it had both POSIX and 16-bit OS/2 APIs.
That pretty much is the full story. Mac OS X does support other APIs, but they're either deprecated (Carbon), or intended primarily to support "foreign" software (Java, X11, POSIX). The native API is Cocoa.
Mac OS X is Unix underneath. That's the "other" API.
Related
First, I can't communicate in english very well.
I will develop PKI.
I can control token in firefox, thunderbird but can't control mac native program(ex. safari, mail).
How can I control the token in os x 10.9(mavericks) native program (ex. safari, mail) ?
I heard use tokend but, also heard now tokend is deprecated.
Is that right?
and, I saw macosforge.org. but I didn't know.
frankly speaking, I'm a Windows developer. so, I don't know much about mac development environments.
Hope you can help.
TokenD is technically deprecated (as is the entire CDSA subsystem it sits upon) since at OSX 10.7.
It sounds like you want a PKCS#11 module to work with native components, you may want to take a look at Gemalto's PKCS#11 -> TokenD bridge: https://smartcardservices.macosforge.org/trac/browser/trunk/Tokend/PKCS11
Note that TokenD -> PKCS#11 usage is tricky in that updates to the contents of the PKCS#11 device may or may not show up until you remove/insert the token.
If you are unfamiliar with Mac OSX build environments, you will likely want to hire/contract out with someone familiar with legacy Mac OSX security (I say legacy since the "new" environment does not yet interact with external security devices).
If I want to write applications that use the Mac OSX UI, is Objective-C the only choice that I have to take advantage of all the frameworks that Apple provides?
Can I use Java, which is installed with Mac OS X?
I think Objective-C will provide the best coverage, yes, but if you want to consider portability and the possibility of getting your applications running under Windows and/or Linux, then choose Qt and C++.
The frameworks for native UI applications on Mac OS X (collectively known as Cocoa) are written in Objective-C so Objective-C is probably the best choice for writing your own applications, although there are bindings for Python and Ruby.
There are other toolkits that can be used (Mac OS X is a *nix system after all) but unless you are writing cross-platform apps, most people will advise you to use Objective-C and Cocoa.
MacRuby, an implementation of Ruby 1.9 on top of Mac OS X Objective-C runtime and Foundation framework, is another way to go.
You still need a deep knowledge of Cocoa and a good understanding of Objective-C.
It will be provided with Mac OS X 10.7 Lion as a private framework. It already integrates very well in XCode 4 workflow, with templates for all type of application (including windowed, it goes without saying).
(MacRuby makes RubyCocoa, the Cocoa binding for Ruby, obsolete.)
The JVM for Java under Mac OS X is no longer provided by Apple, but by Oracle (see here).
I guess Objective-C is the best choice for native OS X Applications. But if you want your Applications to run under other OSs (like Windows or Linux), you'll most likely use C++ and some GUI-Toolkit which supports all of them.
If you come from the Perl world, here is Sherm's CamelBones too.
I read that Mac OS X and bsd are related. How closely are they related. Can Mac OS X software be tweaked and installed on BSD?
Back in the days of OS X 10.4 I spent some time failing to write a VFS for OS X. In those days, of the major subsystems of the kernel, only the network stack and the VFS were still truly BSD. At that time, even the VFS had been partly rewritten to make it more modular (all the BSD VFS data structures became opaque pointers and the API was through what were called KPI functions). I believe the network stack was going the same way. There was also a thin layer at the interface with userland that made the OS look like BSD to userland programs.
Everything else had been pretty much rewritten or replaced: memory management, process management etc came from the Mach microkernel; the device driver subsystem was written from the ground up by Apple.
In terms of userland programming, OS X is very similar to BSD and programs written for BSD should be easily portable. However, OS X has a lot of APIs that aren't available in BSD. These include almost everything to do with the user interface - graphics, sound etc. There are also other interfaces that don't exist in BSD such as the launch API which is the OS X preferred way of launching background processes.
The Wikipedia BSD article is good (and accords with my own understanding, for what that's worth). It says that Darwin, the system on which Apple's Mac OS X is built, is a derivative of 4.4BSD-Lite2 and FreeBSD, and notes that 4.4BSD is the last release that Berkeley was involved with.
So, Darwin is as BSD as you can get (just like all the other BSDs!). OS X refers to those parts of the distribution which aren't open-source, principally the GUI, but including a variety of frameworks, and anything which relies on these won't be portable.
OS X as a whole is a UNIX 03 system. That's equivalent to being a truly POSIX-compliant system (as opposed to being POSIX-like).
As other answers have noted, the userland parts of the OS are unsurprising to anyone with much unix experience, and I've rarely had any difficulty building portable-unix software on OS X.
In contrast, the non-userland parts of the OS are pretty different. Apple seems to be willing to innovate in those areas fairly cheerfully. I think (but I'm not positive) that these changes are formally part of Darwin. One of the most obvious differences is that launchd has replaced cron, at, inetd, and much of the startup infrastructure.
If the Mac software uses Cocoa, Apple's proprietary display library (which it does, if it runs on the Mac with a GUI and does not require starting an X server), then you may have some issues running the code on a normal BSD system.
If your code only uses POSIX-specified functions, it will cleanly port to Linux, BSD, and even Windows.
It is true that Mac OS X and BSD are related. Although they have different kernels, they share a common ancestor and significant userland code. Obviously, I can't quantify "how close" - that's subjective.
Mac OS X is one flavor of BSD Unix. As Borelaid already pointed out, that does not necessarily mean that porting Mac apps to other flavors of BSD would be easy or even manageable, much less so than between other common BSD flavors. Every one of them brings their own specifics, and OS X more than most.
Porting programs from other BSD flavors to OS X also involves work and does not always work (smoothly or at all), but is usually much more straightforward.
It depends on what kinds of apps you are trying to port. If you write POSIX-compatible C/C++ console programs, they will compile and work just fine under any POSIX-compatible system (mostly Linux and BSD flavors), but note that OS X often doesn't implement the newest POSIX functions (e.g. utimensat) which are available in Linux. On the other hand, graphical applications use Cocoa or the older Carbon, which would require GNUstep. Porting graphical applications is quite uncommon because every graphical environment has different design standards and conventions, so graphical applications usually have to be written from scratch for each graphical environment.
Installed - no.
Ported from source, maybe - see Gnustep, Cocotron, EtoileOS - all of which offer varying degrees of compatibility with the Cocoa development stack (but not with the older Carbon).
There is a limited amount of x-platform objective-C software developed that way.
QuickTime provides a set of APIs named "Windows API", as described here.
Its description tells the APIs are used for Windows, but the references also says the APIs are available on OS X 10.3 and later. The function of those APIs are mainly thread synchronization or thread scheduling.
Why those APIs marked "for Windows" are available on OS X? Are they intended for writing cross-platform code?
These functions are necessary on preemptive multitasking environments. When QuickTime was introduced, Apple didn't have a preemptive OS (besides A/UX and A/ROSE). When ported to Windows NT, they added these functions, so were called 'Windows API'. Later, with Rhapsody and MacOS X, Apple maintained the same functions (but i think there are some alternatives now). Yes, the whole QuickTime API is cross-platform.
What is the best programming language for writing MIDI-interactive musical application that would be run on MAC and on Windows?
I've written cross platform (Mac OS X and Windows) MIDI applications using C++. I used the RtMidi for MIDI I/O which was incredibly easy to get going (on every platform just it just worked out of the box). The advantage of C++ is that you can use native GUIs on each platform, but if you're not already into C++ I'd say a cross platform project is a pretty ambitious first project.
One possibility is .NET (C# or VB.Net), which runs on Windows (of course) and Mac (thanks to Mono). The downside is that .NET does not have any native support for MIDI, so you'd have to tap into two different native APIs for MIDI.
Java is another possibility, since it has a number of MIDI-supporting libraries available. Your UI is bound to look pretty terrible, though.
Python has substantial support for MIDI and runs on Mac and Win.
pygame.midi
PyPortMidi
PythonMIDI
pyrtmidi
For both mac and windows I would suggest Java. Midi is just a protocol so any language can do it. A good framework will speed things up a lot. Java has frameworks to work with Midi and other multimedia sources.
PortMidi is another popular cross-platform MIDI library. Qt is a nice cross-platform Framework, GUI and utility library.
It's an old thread, but nowdays you can use .NET. I mean official cross-platform .NET from Microsoft, not Mono. In this case I can recommend my library – DryWetMIDI. Its core part (working with MIDI files, processing MIDI data and so on) is cross-platform for any OS supported by .NET.
As for working with MIDI devices, this API supports Windows and macOS (that's what you need). Full documentation of the library availabale here: https://melanchall.github.io/drywetmidi. There you can find full API reference and help articles. For example, overview article on working with MIDI devices.
The library is distributed via NuGet package and can be installed via NuGet on both Windows and macOS.