Apple's Unix Porting Guide

hysterion writes "Just came across the nice Unix Porting Guide (pdf) posted by Apple earlier this month. Topics include NetInfo, using Project Builder with gnumake, autoconf, XFree86, Tcl/Tk, Qt ... it is a bit short on scripting languages, and they speak as if KDE were already ported, but other than that I found it an informative read." They also didn't mention fink, and they put "Unix" in all caps. However, they were honest about the shell scripting limitations of AppleScript, although they didn't mention that AppleScript -- especially via osascript -- is pretty buggy in Mac OS X right now (this is my annoyance of the week, so allow me to indulge myself).

"As if KDE was already ported"?

[Anonymous Coward]

It is... [opendarwin.org]

Re:"As if KDE was already ported"?

[Ranger Rick]

Yeah, it's not 100% but we've got things mostly working. I've got screenshots (including KDE in rootless mode, very nice =) up at my web page [befunk.com].

Re:"As if KDE was already ported"?

[jeffehobbs]

Aaaah! My eyes! The goggles, they do nothing!

I'm sorry, but compared to OS X, KDE is just soooo ugly and out of place. I appreciate that there might... possibly... be... functionality one could get with KDE ported apps, but X11-based apps still look like they took second place in an ugly contest.

~jeff

KDE + Darwin?

[feldsteins]

I had no idea that this had occured. It's exciting!

I'm given to wonder, however, why someone with a full OS X installation would wish to use KDE. Perhaps there are a dozen reasons I can't think off off-hand, but the real prize would be to run KDE on top of Darwin [apple.com]! Is this possible yet?

Darwin core + good GUI = another no-cost operating system on the loose. It would no doubt have far lower system requirements than OS X, too. The idea has me drooling already.

Re:KDE + Darwin?

[Ranger Rick]

Yes it is possible, one of the other guys on our porting team has gotten it running, we're now working on incorporating those bits so it's reproducable. :)

That's one of the reasons we moved things over to OpenDarwin rather than keeping it just in Fink, is so the Darwin folks can take advantage of it as well...

Of course they do

[Clue4All]

The operating system is UNIX, not Unix, though admittedly at this point it's more of a paradigm than an OS.

Re:Of course they do

[Da Schmiz]

The AC's right: the trademark is spelled in all caps. But see the Jargon File [astrian.net]:

Some people are confused over whether this word is appropriately `UNIX' or `Unix'; both forms are common, and used interchangeably. Dennis Ritchie says that the `UNIX' spelling originally happened in CACM's 1974 paper "The UNIX Time-Sharing System" because "we had a new typesetter and troff had just been invented and we were intoxicated by being able to produce small caps." Later, dmr tried to get the spelling changed to `Unix' in a couple of Bell Labs papers, on the grounds that the word is not acronymic. He failed, and eventually (his words) "wimped out" on the issue. So, while the trademark today is `UNIX', both capitalizations are grounded in ancient usage; the Jargon File uses `Unix' in deference to dmr's wishes.

Re:Of course they do

[Lars T.]

That is somewhat silly, since Unix originally was called UNICS, which was a take on MULTICS, which was an acronym. So the only reason to declare Unix a "word" as opposed to an acronym is that Ritchie became more serious with the project.

A Good "Where-To", "What's That" Guide

[Spencerian]

I'm not a developer, but this appears to have answered a great many questions for those developers teetering on the edge of Mac OS X development. My primary questions were answered pretty well from this document.

The nice thing about this document is how it tacitly implies that writing an OS X app can be done in such a way that it can be deployed just about anywhere with practically any imaging model and with many new or common IDEs. OS X, from a programmer's perspective, must seem extremely flexible.

Java porting guide

[pmorelli]

Here's a link on porting Java apps [apple.com] to Mac OS X, eg, menu bar issues, tweaks that don't break cross-platform compatibility but help the Mac experience. Pretty good.

Re:Deeply Disappointed in the Apple McIntosh

[dtfarmer]

Good luck compiling all that "linux code" on XP...jackass...

It's too bad some people don't have a sense of humor, can't laugh at themselves - I found the parent post to be sarcastically funny - it's obviously not a true story - and it's actually a pretty good troll....

Re:Deeply Disappointed in the Apple McIntosh

[Steve Cowan]

You forgot to mention the ADB caps lock key issue!

As for Fink....

[zhiwenchong]

This is from Fink's FAQ [sourceforge.net]:

Q2.3: What is your relation with Apple?
A: Apple is aware of Fink and has given us some support as part of their Open Source relations efforts. In the summer and fall of 2001, they provided us with pre-release seeds of new Mac OS X versions in the hope that Fink packages can be adapted in time for the release. Quote: "Hopefully it underscores the commitment that many suspect we're not willing to provide. We'll get better at the open source game over time." Thanks Apple!

Interactive Terminal Support for Applescript

[Anonymous Coward]

is what they need. If you run a task that takes ~5-10 minutes to complete (update prebindings) your applescript will stall for that long of time. Trying to "backround" it by putting a & at the end doesnt help ether, still waits for the prossess to finnish. I'd be really nice if i could have a little applescript studio application work interactvly with huge perl programs i've already written.

BTW: if anyone knows how to do this feel free to tell me :) [e-mail]

OSAScript ickiness

[dr00g911]

OSAscript is pretty darned cool, but it's been my annoyance of the week as well. Been playing with it the past couple of days to write a nice-looking iTunes remote for our office jukebox -- controlled via a browser, not the shell (doing it from the shell is cake, even on remote machines.)

As Pudge mentioned, it's VERY buggy though. A few things I've noticed:

• For remote scripting, you've gotta hard-code user names and passwords into the script that's getting executed. They don't get saved in the keychain like you're led to believe... documentation is very light, but eppc://user:pass@192.168.1.1 works. Beats typing in a user name and password repeatedly (possibly on multiple machines) even if it's an ugly and non-portable solution.
• You can't natively launch commands via a passthru(), system() or shell_exec() command through Apache, even if they're in an external, pre-compiled .acgi or Perl file. Fortunately, I stumbled upon ACGI Dispatcher [sentman.com] tonight (after 3 days on and off trying to control iTunes and Photoshop through apache, getting condition expected errors like mad, when the same commands work fine from the shell). Dispatcher allows you to do all of that stuff easily, and includes a iTunes remote CGI (D'oh!). Hopefully Apple will add in some provisions to facilitate OSAScript more robustly, as I'd like to stick to PHP/Perl for the heavy lifting on this stuff, and automating Photoshop (a stock photographer's back-end is one of my gigs right now) via PHP one-liners triggering 'Shop actions would absolutely rule. GDLib and Imagemagick are cool and all, but... the image quality difference on imageresample (even bicubic) and a Photoshop image size command can't even be compared when you've got people as picky about their images as photographers.

Re:OSAScript ickiness

[green pizza]

after 3 days on and off trying to control iTunes and Photoshop through apache...

Egads!

Re:OSAScript ickiness

[pudge]

Some notes:

1. I did get it to save the password in the Keychain. But it would disappear after awhile.
2. I could not even get it to work with hardcoded username/password. AEServer kept dying and leaving zombies behind, and I think osascript was trying to talk to zombies, because I kept getting authentication denied errors, even with a hardcoded username/password.

My current method is to run a background AppleScript in my login session that dumps the data I need, once a minute, to a file in /tmp, and then my cron job reads from that data, instead of calling an AppleScript directly with osascript. This doesn't work for controlling anything, and it doesn't work for immediate access to data, but all I am doing with it is putting a "Now Playing" on my home page [perl.org].

If I had the time, I would port the Mac:: perl modules, including Mac::AppleEvents and friends, to Mac OS X. Though, I am not sure if a program that executes raw Apple events has similar limitations to osascript; that is, I don't know whether these limitations are built in to osascript, or are built in to the AppleScript software. So that solution might not help me anyway. I still wish I had the time to do it, though.

Re:OSAScript ickiness

[dr00g911]

I've got a way to do live data from iTunes instead of the cron task way... (I read about the cron job on MacOShints, and it seemed a bit of a kludge). It requires the ACGI dispatcher I mentioned earlier.

Many thanks to a pile of people that wrote code for me to pick apart to get this working in my case...

My method of grabbing info like that is:

(from a PHP or Perl script):

if ($cmd == "status")
{
$itunesreadout = virtual('/cgi-bin/itunesstatus.acgi');
}

Then in the itunesstatus applescript:

tell application "iTunes" of machine "eppc://user:[e-mail]"
set ThePlayerState = player state as string

[do state checking, decide what to do if it's not playing]

set ThisTrack to current track
set TrackName to name of ThisTrack
set TrackArtist to artist of ThisTrack
set TrackAlbum to album of ThisTrack
set TrackLength to time of ThisTrack
set Length to duration of ThisTrack
set Position to player position

set ReturnInfo to "iTunes currently playing: " & TrackArtist & TrackName & " whatever else you want to include"

return ReturnInfo

end tell

This stuff is from memory, but the process and flow are up and running on our network at the office.

The first time it runs, it'll be a bit slow, but should return info instantly afterward