Professional Web Applications Themes

Using AppleTalk framework in MacOS X? - Mac Programming

Can anyone give me any pointers on how to access the AppleTalk framework which is provided with MacOS X? I am porting a legacy application which requires AppleTalk support (PAP workstation and server). I see the AppleTalk framework in my System/Libraries/Frameworks folder, but Apple's standard distribution doesn't seem to include the header file to access it. Are these header files available publicly or to developers, or is there some other way to access the routines in this framework? I would appreciate any information you could provide... Steve Phillips Software Development Consultant Southborough, MA USA mailto: [email]steve.phillipsalum.mit.edu[/email]...

  1. #1

    Default Using AppleTalk framework in MacOS X?

    Can anyone give me any pointers on how to access the AppleTalk
    framework which is provided with MacOS X? I am porting a legacy
    application which requires AppleTalk support (PAP workstation and
    server). I see the AppleTalk framework in my
    System/Libraries/Frameworks folder, but Apple's standard distribution
    doesn't seem to include the header file to access it. Are these
    header files available publicly or to developers, or is there some
    other way to access the routines in this framework?

    I would appreciate any information you could provide...

    Steve Phillips
    Software Development Consultant
    Southborough, MA USA
    mailto: [email]steve.phillipsalum.mit.edu[/email]
    Lava Man Guest

  2. #2

    Default Re: Using AppleTalk framework in MacOS X?

    "Lava Man" <avpd16hotmail.com> wrote in message
    news:81ae97a5.0307240840.7e3dbcaaposting.google.c om...
    > Can anyone give me any pointers on how to access the AppleTalk
    > framework which is provided with MacOS X? I am porting a legacy
    > application which requires AppleTalk support (PAP workstation and
    > server). I see the AppleTalk framework in my
    > System/Libraries/Frameworks folder, but Apple's standard distribution
    > doesn't seem to include the header file to access it. Are these
    > header files available publicly or to developers, or is there some
    > other way to access the routines in this framework?
    >
    > I would appreciate any information you could provide...
    Header files are distributed with development environments, not in end-user
    installs. At minimum you need to install the Developer Tools CD that came
    with your operating system disc set. Updates to these tools (the latest is
    December 2002) are posted on the Apple Developer Connection site at
    [url]http://www.apple.com/developer[/url] (registration is free).

    If you're porting a legacy application, you're probably using the
    CodeWarrior development. Be sure to upgrade to the latest CodeWarrior (CW
    for Mac 8.3). If you're building a product that uses the CFM binary format
    (runs on 9 and X) when you link with CarbonLib that will automatically link
    you to the AppleTalk framework; if you're building for the Mach-O runtime
    format, you should add the AppleTalk.framework in your project and #include
    <AppleTalk/AppleTalk.h> in your source files.

    Chris Espinosa
    Apple


    Chris Espinosa Guest

  3. #3

    Default Wherefore the floating point inaccuracy?

    Gang,

    Is it Codewarrior? Is it the PPC? Or is it just the accepted nature of
    floating point math that it is inaccurate?

    By inaccurate I mean this:

    float x;

    x = 3.5 + 4.7;

    Examine the value of x (say in the debugger) and it is 8.20000000476837

    Now I can understand if you perform division or other complex math that
    you'll have such small "left over" digits, but can't the internal definition
    of a floating pt variable be able to accurately have 3.5 + 4.7 be exactly
    8.2?!?!?!

    Where is the reason for this inaccuracy? Is it codewarrior?

    Thx
    Ando

    Ando Sonenblick Guest

  4. #4

    Default Re: Wherefore the floating point inaccuracy?

    In article <BB4C644A.D8E3%andospritec.com>,
    Ando Sonenblick <andospritec.com> wrote:
    > By inaccurate I mean this:
    >
    > float x;
    >
    > x = 3.5 + 4.7;
    >
    > Where is the reason for this inaccuracy? Is it codewarrior?
    The reason is the IEEE standard for floating point numbers implemented
    by modern processors, and used on the Mac and in MS-Windows.
    <http://www.psc.edu/general/software/packages/ieee/ieee.html>


    You figure it out: floating point numbers are essentially a binary
    fraction and a 2-to-then-n scale factor.

    You understand Arabic numerals; numbers to the left of the decimal point
    are successively higher powers of 10, numbers to the left of the decimal
    point are successively lower powers of 10.

    so, 3.5 is 3 + 5/10
    this can be represented exactly in binary as:

    11.1


    i.e.:

    1 0 -1
    2 + 2 + 2

    Now try the same trick with 4.7
    You'll find that 7/10 can't be represented precisely in a finite
    number of negative powers of 2.
    David Phillip Oster Guest

  5. #5

    Default Re: Wherefore the floating point inaccuracy?

    In article <BB4C644A.D8E3%andospritec.com>,
    Ando Sonenblick <andospritec.com> wrote:
    > Gang,
    >
    > Is it Codewarrior? Is it the PPC? Or is it just the accepted nature of
    > floating point math that it is inaccurate?
    No. No. Yes. A better term is "approximate", as the inaccuracy is no
    greater than a known fraction of the value.

    More simply, floating point arithmetic is inherently slightly fuzzy.

    > By inaccurate I mean this:
    >
    > float x;
    >
    > x = 3.5 + 4.7;
    >
    > Examine the value of x (say in the debugger) and it is 8.20000000476837
    This is error=(8.20000000476837-8.2)=4.76837*10^-9, or
    (4.76837*10^-9)/8.2= 5.82*10^-10

    This is pretty good for a 32-bit float. Is this actually a 64-bit
    double float? Or, are we just lucky this time?

    > Now I can understand if you perform division or other complex math that
    > you'll have such small "left over" digits, but can't the internal definition
    > of a floating pt variable be able to accurately have 3.5 + 4.7 be exactly
    > 8.2?!?!?!
    >
    > Where is the reason for this inaccuracy? Is it codewarrior?
    Floating-point arithmetic is approximate, and numbers like 4.7 cannot be
    expressed exactly in binary, and so get rounded to the closest binary
    value, causing a small error. (Numbers like 3.5 are exact.)

    IEEE 754 floats, used by PPCs and just about everybody else, carry a
    23-bit mantissa, so the resolution is 2^-23= 1.192*10^-7, while 64-bit
    double floats have 52-bit mantissas, so the resolution is 2^-52=
    2.220*10^-16. In other words, floats have about six significant digits,
    while doubles have about sixteen digits. A significat digit is one that
    conveys information, so leading zeros (to the left) and noise digits (to
    the right) don't count. Nor does the decimal point. Only the digits in
    the middle count.

    Look in <float.h> for the characteristics of floating point arithmetic.

    A consequence of the fuzzy nature of floating point is that tests of
    equality cannot be done directly:

    If one has two floats (or doubles) A and B, the comparison test "if A==B
    then whatever" will almost always fail due to tiny errors in the
    computations of A and B, so whatever will never be executed.

    The correct way to do this is "if abs(A-B)<tol then whatever", where tol
    is a value that's large compared to the likely fuzz in A and B but small
    compared to A and B.

    Even better is to recast the problem so that tests of equality are not
    needed, so we get only something like "if A<B then whatever", which
    works despite the fuzz.

    Also beware of computing the same value A in two places, which we will
    call A1 and A2, and (implicitly) expecting that A1==A1. It never is,
    because optimizing compilers will never do exactly the same thing in the
    two places, even if the source code is letter-for-letter identical. If
    this matters, compute A once and save it for later use; do not recompute
    it.

    Joe Gwinn
    Joe Gwinn Guest

  6. #6

    Default Re: Wherefore the floating point inaccuracy?

    Ando Sonenblick wrote:
    >Is it Codewarrior? Is it the PPC? Or is it just the accepted nature of
    >floating point math that it is inaccurate?
    I can think of no better reference than this:

    "What Every Computer Scientist Should Know About Floating-Point Arithmetic"

    It's from Sun Microsystems.

    [url]http://docs.sun.com/source/806-3568/ncg_goldberg.html[/url]
    [url]http://docs-pdf.sun.com/800-7895/800-7895.pdf[/url]
    [url]http://docs.sun.com/db/doc/800-7895/6hos0aou4?q=Computer+Scientist+Should+Know+About+F loating-Point+&a=view[/url]

    Enjoy! :-)

    Mike Hall Guest

Similar Threads

  1. Dir 8.5 - MacOS 9.2 projector in MacOS X Classic
    By davepla in forum Macromedia Director Basics
    Replies: 0
    Last Post: March 4th, 08:30 AM
  2. Free FTP clients for MacOS 7.5.5 .. MacOS 9 ?
    By Rolf Hemmerling in forum Mac Networking
    Replies: 3
    Last Post: August 12th, 01:39 AM
  3. appletalk
    By Louie Miranda in forum Debian
    Replies: 1
    Last Post: July 31st, 04:30 PM
  4. No appletalk on WaveLan with MAC address table
    By Robertello in forum Mac Networking
    Replies: 0
    Last Post: July 22nd, 04:12 AM
  5. Linksys WAP 11 Appletalk Support?
    By Sam Arseneau in forum Mac Networking
    Replies: 1
    Last Post: July 16th, 08:10 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139