I'd like to get into some mac os x systems programming and wondered, although mac os x is a Mach and bsd hybrid, would a bsd programming book suffice since I can't seem to find any books on mac os x systems level coding (or mac os x architecture)?
Any pointers would be much appreciated.
Thanks
ste
You'll want to pick up a copy of Amit Singh's excellent Mac OS X Internals: A Systems Approach.
Beyond that, books on BSD can be helpful, yes, though it depends on what level of system programming you're interested in. If you're mainly going to be working with the kernel, it won't be as useful.
you might find the System Technology Overview from the Apple Developer Connection website helpful.
It contains links to several more documents which go into more detail about specific OS X technologies.
You might also find more information if you browse the index of the Apple Developer Library. For example the 'Getting Started' articles or the 'Drivers, Kernel & Hardware' topics.
Related
I am student working on an academic project - 'Porting KVM to MAC OS X'. I gathered a lot of literature regarding KVM, MAC OS X etc., But, I am still unclear as how to proceed. I checked Apple's Developer website which lists a hundred things to do for the porting process.I dont understand why Mac, having UNIX at its heart, needs a lot of changes to the source code, just to make it run.
Also, I heard that Fink (and also macports) is a tool, using which I can port any Unix application to Mac OS X. Is that true? I checked Fink's website, where in I don't find any details which suggests that I can use Fink as a tool for porting. All I see is Fink (and also macports) is a package management system which has several linux applications and will run only those applications on Mac. KVM is not there on the list. So, again I am confused. Please suggest me, how to go about it? Just one step. Is the way Apple community suggesting, the only way? Please help.
I believe that you are looking at the wrong direction.
KVM is not an application. QEMU, the standard user interface for KVM, is mostly a front-end. The main part of KVM lies within the Linux kernel. You would have to provide an equivalent of that kernel code for OS X.
This is a completely different beast than application porting. There is no standard like POSIX within the kernel of an operating system - there is not even the guarantee of internal interface compatibility between different versions of the same kernel. The Linux and OS X kernels are completely different even in their basic design, since OS X uses a Mach-based kernel.
You will have to understand how both kernels work and find out what changes you need to make. Depending on how different the two kernels are, your task might even amount to a full re-implementation of KVM. You will also need a concrete understanding of how virtualization is implemented on modern CPUs and quite probably a more than passing knowledge of assembly and various low-level computer specifics.
if you find something with the functionality you are looking for, it wont be a port of KVM.
the level that you would be abstracting doesn't even exist on the mac, the bottom layers are all different...
(Approximation)
lintel ->
BIOS : BOOTLOADER : LINUX_KERNEL : INIT
Macintel->
UEFI : MACH_MICROKERNEL : BSD_STUFF : LAUNCHD
both being POSIX you might expect more underpinnings to be the same, but really they are all different...
For someone familiar with Linux kernel programming, what are some resources for getting started with OSX kernel programming? I've read some of the Apple Developer resources, but they seem fairly generic (e.g. basic concurrency control primitives). Specifically I am interested in file system development.
Amit Singh's book "Mac OS X Internals" contains a chapter describing the Implementation of HFS+, which might be helpful. If you find resources describing BSD's VFS layer, that might help too, as that's where OS X's VFS layer originates (though with its own page cache, called the Unified Buffer Cache or UBC). Moreover, you could try poking around in the source code of MacFuse and its descendants. Looking at the source of some of the simpler file systems (HFS+ is a bit big for this) will probably also help.
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.
I would love to begin developing applications for the MAC OS X, although I have to idea where to start.
Problem: I currently do not, and cannot afford a new MAC OS X-based computer.
Solution: A very good friend loves trying out things that I've made for Windows, and also owns a MAC OS X computer, and is willing to test these new creations.
Now I am faced with another problem. I don't know which language to use to develop these apps in. I am a .NET Developer and seeing as though I can only use a Windows based PC to develop MAC apps, where should I start?
I've heard of Mono, and have used it on Linux before, would Mono be an option for MAC development on a Windows based computer, too? Are there any other ways around this?
Any help is appreciated. :)
Thank you
jt
You could start with a cross platform language like Java, Python or Ruby. The applications you write this way either work immediately on OSX or need only little adjustments. I work with Java to develop for OSX, windows and linux. Java is not too different from C# and comes completely free. With some extra work Java applications can look like native OSX or windows or linux.
But this way you don't get any of the special features of OSX. For these you do need the OSX environment objective-c and cocoa.
If you don't want your applications to be total shite that makes me cry, then buy a Mac and start reading and learning about what makes a high quality Mac OS X application. The standards for quality are much higher on this side of the river, you'll soon see.
You need to have MacOS X and use Xcode with Objective C; this is the native environment, and you won't be able to appreciate MacOS X UX without using it. You may be able to install MacOS X on a PC, although this isn't approved or supported by Apple.
Just don't take half measures, it isn't worth it.
Sorry for this late answer, but I am having the same problem.
After looking around, I have seen people be able to install OS X 10.6 (Snow Leopard) on their Windows 7 computers using a virtual machine. Maybe this website from lifehacker may help:
http://lifehacker.com/5583650/run-mac-os-x-in-virtualbox-on-windows
These people tell you how to install Snow Leopard. You may not install Xcode 4.33 on Snow Leopard, but it's worth a try. There also may be places where they show you how to install Lion itself onto their PC's, but Lifehacker has the most straightforward tutorials.
Hope this helps!
All the other answers are good. You need OS X and XCode. Since,at the moment you can't afford a Mac machine and seeing how the language of choice for both OS X and iOS is objective-c, you could start with learning C programming on windows. Objective-C is a superset of C. Knowing C Langauge will speed up your learning curve once you can afford to buy Mac. (or you might decide that C pointers are just too hard and save some money)
Also google how to create a hackintosh. I've seen couple articles on lifehacker on how to do it. It's not ideal but perhaps it would allow you to run XCode and create apps for iPhone or iPad.
I need to decide whether I should support Mac OS X 10.4 / Tiger, and the decision likely hinges on what percentage of mac users are still running Tiger. I didn't find anything too reliable on the interwebs nor on Apple's developer website. Let's ignore the impending Snow Leopard release and it's impact on Mac OS version usage distribution.
Does anyone know of a study that might provide insight? Any other suggestions on how to figure this out? If you quote any numbers/percentages please include a pointer to the source.
Take a look at the Sparkle+ stats, that the Adium project is collecting.
The stats are available here.
OmniGroup keeps track of the system configurations that use their software updater. The current split is roughly 60/40 in Leopard's favor.
Keep in mind that, judging from previous releases, Apple will likely drop official support of Tiger once Snow Leopard is released, which should be any day now.
It really depends on what user audience your software has (whether they're likely to upgrade or not). I don't have a study, but considering how each major update costs money, I'm sure there are many non-power users who are still on older editions.
You're better off targeting Leopard only, especially with Snow Leopard coming out at the end of the week with a lot of changes to key technologies. Apple moves pretty quickly and soon enough supporting Leopard will be your legacy support.
From the Adium Sparkle+ stats that weichsel linked to:
10.3 : 2170 ( 1.3%)
10.4 : 28645 (16.3%)
10.5 or above: 134269 (82.4%)