Professional Web Applications Themes

Newbee - porting Windows & Unix code - where to start - Mac Programming

Dear group I do have a 20+ year backround in developping all kind of C software on various platforms including Unixes and Windows. However, I now have to port a little tool to the Macintosh world and so far never touched a Mac. I do have a Ei-Mac (spelling?) with the bare OS9 installed at hands. The tool which actually does some UDP network IO and should prompt the user with some windows should run on Os9 and later (if this is possible). I do have the following questions: - Which compiler / debuger etc. should I use? I'm on ...

  1. #1

    Default Newbee - porting Windows & Unix code - where to start

    Dear group

    I do have a 20+ year backround in developping all kind of C software
    on various platforms including Unixes and Windows. However, I now have
    to port a little tool to the Macintosh world and so far never touched
    a Mac. I do have a Ei-Mac (spelling?) with the bare OS9 installed at
    hands. The tool which actually does some UDP network IO and should
    prompt the user with some windows should run on Os9 and later (if this
    is possible).

    I do have the following questions:

    - Which compiler / debuger etc. should I use? I'm on a tight budget
    hence would prefer freeware. I don't need bells and whistles - just a
    C compiler and debugger is fine. I don't mind GUI stuff though.

    - Where should I start? Is there a tutorial that centers around
    porting from other platforms to the Mac (i.e. compareing Win32 API
    with mac or similar?) or any other good point to start? Here I would
    prefer online sources but I'm willing to buy a book if needed.

    - Is it possible at all to compile a program under OS9 which is
    useable under OSX or do I have to compile for both OS's ?

    - Is it possible to create a CD that will autoboot on Windows and
    Macintoshes provided I put the propper executeable files on it or is
    the CD format the Mac uses so totally differnt?

    TIA

    Markus
    Markus Guest

  2. #2

    Default Re: Newbee - porting Windows & Unix code - where to start

    In article <com>,
    Markus Zingg <ch> wrote:
     
     

    It's either iMac or eMac. See store.apple.com
     

    The first question you should consider is 'do I really need Mac OS 9
    support?'. If you stick to Mac OS X you probably can leverage your
    existing Unix knowledge. The learning curve for Mac OS 9 networking will
    be a lot higher.
     

    Mac OS 9 has Macintosh Programmers Workshop (MPW)
    <http://developer.apple.com/tools/mpw-tools/>. It has a Unix-inspired
    command line, but be prepared for a learning curve.

    As a assembly-level debugger, you can use MacsBug
    <http://developer.apple.com/tools/debuggers/MacsBug/>

    Mac OS X ships with gcc and gdb, and a free GUI
    <http://developer.apple.com/tools/xcode/>
     

    <http://developer.apple.com/referencelibrary/GettingStarted/GS_Porting/in
    dex.html>
     

    It may be possible to create a 'Carbon' application under Mac OS 9 that
    runs on both platforms, but I think you will want to develop under Mac
    OS X (it has such things as protected memory and preemptive multitasking)
     

    The Mac reads Windows CDs fine. I am not sure whether autorun still is
    available on Mac OS X. It is a virus vector.

    Reinder
    Reinder Guest

  3. #3

    Default Re: Newbee - porting Windows & Unix code - where to start

    Reinder,
     
    >
    >It's either iMac or eMac. See store.apple.com[/ref]

    From visiting the store.apple.com it looks like an eMac. I don't have
    it right here - hence could not check on the device. Thanks for the
    pointer.
     
    >
    >The first question you should consider is 'do I really need Mac OS 9
    >support?'. If you stick to Mac OS X you probably can leverage your
    >existing Unix knowledge. The learning curve for Mac OS 9 networking will
    >be a lot higher.[/ref]

    Unfortunately OS 9 is an absolut requierement since marketing told
    that our targeted audience is widely useing it. Can't judge wether
    this is true or not but well, it's a requirement.

    I was reading some of the docs that are online available about
    networking under OS 9. I did not found the API to be so very odd.

    It's probably important to understand that the software I have to port
    is just an installation program to perform the initial networking
    configuration of a device we manufacture and which is suposed to also
    cooperate with Mac installations. The programm really mostly consist
    of a welcome screen, a screen to choose the language and one to enter
    IP configuration information for the device. Technically all it must
    do is send and read some UDP packets to / from the deivice - really
    noting fancy.
     
    >
    >Mac OS 9 has Macintosh Programmers Workshop (MPW)
    ><http://developer.apple.com/tools/mpw-tools/>. It has a Unix-inspired
    >command line, but be prepared for a learning curve.
    >
    >As a assembly-level debugger, you can use MacsBug
    ><http://developer.apple.com/tools/debuggers/MacsBug/>[/ref]

    Uhh - no C level debugger? Well, life is harsh sometimes :-)
     
    >
    ><http://developer.apple.com/referencelibrary/GettingStarted/GS_Porting/in
    >dex.html>

    >
    >It may be possible to create a 'Carbon' application under Mac OS 9 that
    >runs on both platforms, but I think you will want to develop under Mac
    >OS X (it has such things as protected memory and preemptive multitasking)[/ref]

    Could you elaborate on this carbon application thingy? Is this a
    certain developement envireonement or just some conservative codeing
    style etc? If it's the latter, how does low level network programing
    fit into the picture? Or does OSX have some sort of sandbox/emulator
    embedded that allows to run older app's in compatibilty mode or such?

    The installation tool I have to write does not ask much in the area of
    what OSX could offer, so I figure I will be much happier with code
    that runs on both platforms unchanged. I'm therefore much more
    interested in having a solution that runs on both platforms.
     
    >
    >The Mac reads Windows CDs fine. I am not sure whether autorun still is
    >available on Mac OS X. It is a virus vector.[/ref]

    ok

    Markus

    Markus Guest

  4. #4

    Default Re: Newbee - porting Windows & Unix code - where to start

    > From visiting the store.apple.com it looks like an eMac.

    It might also be an older iMac, like this one
    <http://applehistory.norhost.net/imac.html>
     

    Well, there are high-level debuggers, but I thought you need a low-level
    one to debug networking stuff, and I am not sure whether Apple still has
    a free high-level one (a quick check shows that there is one:
    <http://developer.apple.com/tools/debuggers/PowerMacDebugger/>)
     

    Carbon is a set of APIs that is available both on Mac OS 9 and Mac OS X
    (on Mac OS 9, you may need to ship an extension that implements some of
    the APIs)
     

    I don't know that much about that. On Mac OS 9, I would guess that you
    need to look up 'Open Transport' on the Apple site
    <http://developer.apple.com/macos/opentransport/>
     

    It has such a thing, but it may not be installed. Even if it is
    installed, users will not like it if your application uses it. It makes
    your application look old, giving the impression that your hardware is
    not well-supported (similar to the way seeing a Windows 3.1 file
    selector in a modern Windows application does not increase one's trust
    in an application)

    Finally: I can't see how getting Mac OS 9 knowledge for this one
    installer can be economical (for the Mac OS X part, one could argue that
    getting to know Mac OS X is worth something, but investing time to get
    to know development environments on Mac OS 9?). Have you considered
    hiring somebody with Mac knowledge to do this? (and no, I am not
    soliciting)

    Reinder
    Reinder Guest

  5. #5

    Default Re: Newbee - porting Windows & Unix code - where to start

    Reinder Verlinde <invalid> wrote:
     
    >
    > Carbon is a set of APIs that is available both on Mac OS 9 and Mac OS X
    > (on Mac OS 9, you may need to ship an extension that implements some of
    > the APIs)[/ref]

    To be precise, Carbon is a cleaned up version of the old Mac OS API's.
    It was created to make it possible to migrate programs written for (say)
    Mac OS 7 to Mac OS X. Carbon today is used for the bulk of commercial
    software. Although Mac OS 9 has been decleared 'dead', the Carbon API's
    are still very much alive. This means that nowadays you can develop
    Carbon programs that are not compatible with OS 9. As long as you are
    aware of this, this shouldn't be a limitation for your use though.

    Have you (Markus) considered using Java? It is available on both OS 9
    (1.1.8) and OS X (1.3+) I imagine at least the gui part would be easier
    to program. Don't know how easy it would be to talk to you device, or
    maybe you can just write a configuration file?

    Patrick Machielse
    Patrick Guest

  6. #6

    Default Re: Newbee - porting Windows & Unix code - where to start

    Patrick,

    Thanks for your reply.
     

    Any pointer to this specification / doentation?
     

    Does "migrate" mean recompiling sourcecode or is such software binary
    compatible among mac os versions?
     

    Not yet, but now that you mention it I might take a closer look.
     

    The key question here would be if java is installed and available by
    default on all Macs.Our marketing really want a solution where the
    installation CD can be inserted into the machine and the program start
    up. (OK, if this should not work due to security limitations on say
    OSX we could live with that cause the users obviousely would not
    expect such behaviour and should be able to know how to start a
    program off a CD)
     

    Configuration file is IMHO no option. This is not about installing a
    driver or such. All networking protocols needed to use the device are
    available to Mac Applications already. It's really just about
    configureing the IP parameters of the device in a non DHCP scenario
    wehre all of the network consists exclusively of macs (no Windows or
    Linux PC's around or wanted). The program simply broadcasts some UDP
    packets into the current network segment which are then echoed by the
    device(s) and allow for the initial configuration. I doubth that
    scripting of any sort could solve this (ok, I obviousely don't know
    what's available to what level on a mac in this area) but it's
    important to understand that the complete networking protocol to do
    the configuratoin is finished and that the devices are in production
    already. I.e. it's not an option to add any code on the device end.
    That's really also not needed if I can handcraft a UDP packet on a mac
    which seems to be possible.

    Markus

    Markus Guest

  7. #7

    Default Re: Newbee - porting Windows & Unix code - where to start

    Reinder Verlinde <invalid> wrote in message news:<wxs.nl>... 
    >
    > It may be possible to create a 'Carbon' application under Mac OS 9 that
    > runs on both platforms[/ref]

    This is definitely possible if you confine yourself to the Carbon API.

    T
    Toby Guest

  8. #8

    Default Re: Newbee - porting Windows & Unix code - where to start

    In article <com>,
    Markus Zingg <ch> wrote:
     
    >
    > Any pointer to this specification / doentation?[/ref]

    <http://developer.apple.com/carbon/>

    and

    <http://developer.apple.com/doentation/Carbon/Carbon.html>

     
    >
    > Does "migrate" mean recompiling sourcecode or is such software binary
    > compatible among mac os versions?[/ref]

    In 1984, Macs were introduced with files with resource forks.
    Applications were files of type 'APPL', with a resource fork containing
    'CODE' resources. Resource 'CODE' 0 held a segment descriptor table,
    and resources 'CODE' 1..n held the executable code for the segments.
    Operating system calls were accessed through Motorola TRAP instructions.

    These TRAP instructions are specified in the .h files, for example if
    you look in Quickdraw.h in the :Universal:Headers:CIncludes: folder,
    you'll see stuff looking like:

    void PaintRect(const Rect * r) ONEWORDINLINE(0xA8A2);

    where ONEWORDINLINE is a macro, which, on a 68K compiler, tells the
    compiler everything it needs to generate a call to the O.S.

    In the '90s, when Apple switched to the PowerPC, they added PowerPC
    executable code in PEF, the "Preferred Executable Format" for the
    PowerPC architecture, defined by IBM, the source of the PowerPC chip.,
    usually in the data fork, and if an application contained a 'cfrg' 0
    resource, then PowerPC macs would use it to find the PowerPC executable
    code, while 68k macs would continue to execute the 68k version of the
    application. That way, you could have a single file that would appear as
    an application in the Finder, and run correctly on either 68K or PowerPC
    Macs. Applications that had both 68K and PowerPC code would get the
    "native" one loaded on the specific Mac they were running on that time,
    so would not just run on all Macs, but would run as fast as possible on
    the current Mac, they were known as "fat" applications.

    The switching was very fast, and the user could use a mix of 68k and
    PowerPC programs seamlessly, without caring about which was which.

    The PowerPC doesn't use a TRAP instruction to access the O.S., instead
    it uses a scheme where you must link against a "stub library", and when
    the user trys to run the program, the loader component of the operating
    system matches the stub library with actual shared libraries that are
    kept in the :System Folder:Extensions: folder. This is the DLL Hell
    problem familiar to Windows users, saved only by the Mac's lack of a
    fragile registry.

    Apple also added the "Mixed Mode Manager", a convention for wrapping
    function pointers that decorates them with info for how they should be
    interpreted. Using the Mixed Mode Manager, PowerPC programs could call
    68k plugins, and 68K programs could call PowerPC plugins, and each could
    call callback routines in the other processor architecture. Different
    linker formats were also supported, for example original 68k and also
    CFM-68k.

    Then some people who were unaware of Apple's history and traditions took
    over, and instead of extending the mixed mode manager and the cfrg
    system, and instead of continuing with the executable format that the
    PowerPC was designed for, they switched to the one that happened to come
    from GNU's gcc (Mach-O). They also usurped the names of all the O.S.
    calls, now the programmer links with either InterfaceLib (old style
    PowerPC) or CarbonLib (new style PowerPC) stub libraries, and if Carbon,
    adds a 'carb' 0 resource. Now the loader loads against InterfaceLib or
    CarbonLib, and you are up and running. What this means is you can't have
    a single file that is recognized and run as a native application on all
    Macs: if it has PowerPC code, and that code uses CarbonLib, then it
    won't run on early PowerPC Macs that don't have the CarbonLib shared
    library installed. (It was an optional component before OS 9.)

    The Carbon API is available on OS X still, both as PEF and as Mach-O,
    but new development is only present in the Mach-O version. You can,
    with some pain in a Carbon PEF program, programmaticly load a Mach-O
    shared library into RAM and extract function pointers from it, and with
    some pain, pass a PEF callback to a Mach-O call and vice versa, but it
    is painful.

    Instead of seamlessly running earlier apps, OS X starts a slow classic
    Mac emulator, which only runs if the user has the optional OS 9
    installed. the emulator, called "Classic" takes about a minute to start,
    so a Mac user usually says, "Oh, " the first time he double clicks
    on a classic app after booting his OS X machine.

    There was a third-party post-linker for the Metrowerks C/C++ compiler
    called FatCarbon that got around this problem, and let you build an app
    that had two copies of your PowerPC code in it, one that linked with
    InterfaceLib, and one with CarbonLib, and FatCarbon would arrange for
    the CarbonLib version to be used if the shared library for CarbonLib was
    actually present.

    So, there we stand: classic 68K code resources, PowerPC in PEF format
    linked against InterfaceLib, PowerPC in PEF format linked against
    CarbonLib, PowerPC in Mach-O format, all generated from the same source
    code, but you can't package all of them usefully into a single file that
    will be recognized as an executable application on all Macs. What you
    can do is: register your four-byte application signature on Apple's web
    site (you should do this anyway), and make the doent's icon look like
    an app. The real apps would be buried in folder, automaticly launched
    when you double click on the doent (because the Finder has made an
    appropriate desktop database on the partition that you cloned the CD
    from.) that launches the appropiate app: bundled for OSX, otherwise
    classic 68K code or InterfaceLib PowerPC PEF.

    Hire an expert. Don't try to get all these details right on the first
    Mac program you've ever written.
    David Guest

  9. #9

    Default Re: Newbee - porting Windows & Unix code - where to start

    Markus Zingg <ch> wrote:
     
    >
    > Any pointer to this specification / doentation?[/ref]

    I don't have the exact url at hand, but <http://developer.apple.com>
    should come close. The doentation on the site has improved vastly
    over the last year. Be sure to sign on for a free 'online' membership to
    Apple Developer Connection (ADC) so you can download the latest
    software. Also check out the mailing lists for developers hosted by
    Apple <http://search.lists.apple.com/>. Lots of smart people there...
     
    >
    > Does "migrate" mean recompiling sourcecode or is such software binary
    > compatible among mac os versions?[/ref]

    If you compile on OS 9 you end up with a binary in the 'PEF' format.
    This can be executed by both OS 9 and OS X systems. On OS X however you
    can only compile to the newer Mach-O binary format, which cannot be
    executed by OS 9 systems. If you want to create a single binary for Mac
    OS 9 (aka 'Classic') and OS X you will have to compile on OS 9. (which
    means you don't have to whorry about using new Carbon calls either)

    (I'm not speaking from experience here, but this is how I 'remember'.
    Please visit the Apple docs for the definitive answer)
     
    >
    > Not yet, but now that you mention it I might take a closer look.[/ref]

    Maybe you can put the configuration code in a single, platform specific
    C function you call using JNI. (again: no experience here ;-) )
     
    >
    > The key question here would be if java is installed and available by
    > default on all Macs. Our marketing really want a solution where the
    > installation CD can be inserted into the machine and the program start
    > up.[/ref]

    And rightly so! On OS X Java is _allways_ installed. On OS 9 you can opt
    out of Java during the install, I think. But installing OS 9 is too long
    ago for me, luckily! Apple does provide a JVM installer for OS 9 which
    you can distribute with your product.

    Good luck,

    Patrick
    Patrick Guest

  10. #10

    Default Re: Newbee - porting Windows & Unix code - where to start

    In article <1geeg8t.1ic07kn1yogzhqN%nl>,
    nl (Patrick Machielse) wrote:
     
     
    > >
    > > Not yet, but now that you mention it I might take a closer look.[/ref]
    >
    > Maybe you can put the configuration code in a single, platform specific
    > C function you call using JNI. (again: no experience here ;-) )[/ref]

    Or just write it all in Java if you can. :)
     
    > >
    > > The key question here would be if java is installed and available by
    > > default on all Macs. Our marketing really want a solution where the
    > > installation CD can be inserted into the machine and the program start
    > > up.[/ref]
    >
    > And rightly so! On OS X Java is _allways_ installed. On OS 9 you can opt
    > out of Java during the install, I think. But installing OS 9 is too long
    > ago for me, luckily! Apple does provide a JVM installer for OS 9 which
    > you can distribute with your product.[/ref]

    Java is installed by default on Mac OS 9. You can opt out of it during
    the install, but very, very few people did so. You had to dig through a
    few levels of dialogs and controls to find the check box that let you
    turn it off.

    -Eric

    --
    Eric Albert stanford.edu
    http://rescomp.stanford.edu/~ejalbert/
    Eric Guest

  11. #11

    Default Re: Newbee - porting Windows & Unix code - where to start

    On 25/05/2004, Markus Zingg wrote in message
    <com>:
     

    The difference between developing for OS 9 and developing for
    OS X is like the difference between Windows 2.0 and Windows NT.
    With your Unix background you'll find learning OS X very easy.
    Learning OS 9 will be absolute hell and involve you learning all
    sorts of obsolete APIs, and it will stop you using a lot of the
    more cool functions of OS X.

    I'd strongly suggest that you stick to OS X. If you do that,
    you can use the very high-power free development tools which
    come with OS X and give full access to all the necessary
    doentation, libraries and compilers you need to develop
    professional OS X applications.
     

    There is no autoboot function for OS X. It would be too easy
    to write a virus which exploited it. Macintosh users are clever
    enough to start an application themselves when they want to.

    Simon.
    --
    Using pre-release version of newsreader.
    Please tell me if it does weird things.
    Simon Guest

Similar Threads

  1. porting UNIX file utilities to OS X? (HFS+ questions)
    By Will Benton in forum Mac Programming
    Replies: 1
    Last Post: August 11th, 03:25 PM
  2. Porting code to Mac (part 2)
    By Eric Albert in forum Mac Programming
    Replies: 0
    Last Post: August 10th, 01:08 AM
  3. Porting code to Mac
    By Stephen Fraser in forum Mac Programming
    Replies: 2
    Last Post: August 3rd, 04:16 PM
  4. porting perl scripts from NT to UNIX
    By Sisyphus in forum PERL Miscellaneous
    Replies: 0
    Last Post: July 29th, 01:15 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