Mac Forum / Programming / Mac Programming / May 2007

A:

B:

I do not see how B follows logically from A.

<http://developer.apple.com/referencelibrary/GettingStarted/GS_HardwareDr
ivers/index.html>

AFAIK, Automator does nothing that you could not also do on the system.

<http://developer.apple.com/documentation/Carbon/Reference/QuartzEventSer
vicesRef/index.html>

No. Other options include Java and wxWidgets, but there are many, many
more.

If you have installed the developer tools: /usr/bin/as.

From your question, it lt looks like you think you will need to use
assembler to do what you want. I doubt that.

Reinder

That's correct.  Generally speaking, the only events your application
should be concerned with are those that occur when the user interacts
with it.  This has some significant benefits.  For example, application
code can become a lot simpler, since it only needs to deal with
situations it's affirmatively prepared for.  Application code can also
block when it has nothing to do, freeing up CPU for other operations or
even (if the event load on the overall system is low enough) for the
CPU to be slowed or suspended by power management.  No application on
Mac OS X should *ever* spin-wait for events.

The antecedent does not follow from the precedent.  I worked on a suite
of applications that leveraged a barcode scanner that behaved as a USB
keyboard.  All it required was using a custom subclass of NSApplication
and overriding -sendEvent: to observe keyboard events within my
application.

Sure, if the user pulled the trigger to scan something and the
application wasn't active, they got essentially random typing.  For
this application - a custom line-of-business application - we could
just say "don't do that."  Before making more work for yourself, see if
you can do the same thing.

If you *do* want to get lower-level access to the event stream, say
because you intend to filter it, there's pretty much only one way to
go:  A Core Graphics event tap, described in the Quartz Event Services
Reference:  
<http://developer.apple.com/documentation/Carbon/Reference/QuartzEventServicesRef
/Reference/reference.html>

Note

that due to the low level of the interface and the secure, multiuser
nature of Mac OS X, it won't be nearly as simple as (say) just
installing a jGNEFilter to monitor events.  Also note that event taps
are only supported in Mac OS X 10.4 or later.

Event taps, as above.

Cocoa and Carbon are pretty much the only game in town for high-end
native applications.  Java is also available and well-supported.  If
you want to write command-line utilities only, you can of course use
the wealth of BSD-derived and POSIX APIs available on Mac OS X.

I would seriously question your priorities if you wanted to write
production code in assembly rather than leveraging high-level
frameworks like Cocoa.  After all, if nothing else you'll have to write
your code twice, once for PowerPC-based Macs and once for Intel-based
Macs.

Assembly is great to use when you absolutely need it.  But it should be
avoided at all costs when you don't.  That's why you won't get very far
asking for an "asm compiler" for Mac OS X -- why would anyone bother
with anything like that standalone? -- but the Xcode suite does include
assemblers in addition to compilers.

 -- Chris