[comp.unix.aux] Audio CD's / AppleCD SC

grissom@boltupright.Colorado.EDU (04/23/91)

Is it possible to play Audio CD's under either the 24 or 32 Command
Shell using Apple's Foreign File Access, Audio CD Access file, and 
the CD Remote DA with the AppleCD SC.  I get an error when it tries to
launch the Foreign File Access startup file after login.


Mike Grissom
University of Colorado
grissom@spot.Colorado.EDU

blob@Apple.COM (Brian Bechtel) (04/23/91)

grissom@boltupright.Colorado.EDU writes:

>Is it possible to play Audio CD's under either the 24 or 32 Command
>Shell using Apple's Foreign File Access, Audio CD Access file, and 
>the CD Remote DA with the AppleCD SC.  I get an error when it tries to
>launch the Foreign File Access startup file after login.

No, as mentioned in the A/UX documentation, these files aren't supported
under A/UX.  Both Audio CD Access and the CD Remote DA use SCSI calls
which aren't supported by A/UX.  Foreign File Access is the wrapper of
calls that supports Audio CD Access.

--Brian Bechtel     blob@apple.com     "My opinion, not Apple's"

usenet@Apple.COM (USENET Administrator) (04/25/91)

grissom@spot.Coloraro.EDU writes:
>Is it possible to play Audio CD's under either the 24 or 32 Command
>Shell using Apple's Foreign File Access, Audio CD Access file, and 
>the CD Remote DA with the AppleCD SC.
From: rick@crowbar.apple.com (Rick Auricchio)
Path: crowbar!rick

    Nope.
--
Rick Auricchio	 rick@apple.COM 	 Mooney N894AR    	 (408) 974-4227
Apple Computer Inc, A/UX Engineering,10300 Bubb Rd, MS 50-UX Cupertino CA 95014
		Work is for people who don't know how to fly.
My opinion is my own. My employer? They use a windsock and a fire extinguisher.
t %
            name            % name.as_string %
            translations    % standard_translations %
            install         % set_actions(% action %) %
            borderWidth     % 1 %
            borderColor     % 'black' %
            background      % 'gray' %
        ]]

The %-ed items are evaluated, the others (eg "widget") are not. This list is
one of the arguments to a widget instantiator. If I wrote it in a statically
typed language, I expect I'd have to (a) gather each name-value pair into a
twople [*1] and (b) inject each of the values into a suitable union type.

If anyone's really interested, I'll explain what it means. I'm happy to admit
that type errors may occur at run-time here; in fact, I'll lay odds that many
of those same type errors would occur in a statically-typed language (when
projecting a value back out of the presumed union type). So we need a way of
handling exceptions; but we knew *that* already.

It would be bootless to tell me that I ought to have an interface to the
instantiator that took (say) the widget as a separate argument, the colour(s)
as others, etc; one of the points about this interface is that given a widget
description, it can be modified (usually by appending stuff on the end) without
instantiating it, or inspected.
--

Regards, Kers.      | "You're better off  not dreaming of  the things to come;
Caravan:            | Dreams  are always ending  far too soon."