Path: utzoo!attcan!uunet!husc6!uwvax!umn-d-ub!gandreas From: gandreas@umn-d-ub.D.UMN.EDU (Glenn Andreas) Newsgroups: comp.sys.mac.programmer Subject: Re: Is MacApp C-compatible? Message-ID: <422@umn-d-ub.D.UMN.EDU> Date: 25 Jul 88 20:03:26 GMT References: <333@apexepa.UUCP> Reply-To: gandreas@ub.d.umn.edu.UUCP (Glenn Andreas) Organization: University of Minnesota, Duluth Lines: 70 In article <333@apexepa.UUCP> jcj@apexepa.UUCP (John Juback) writes: >I would like to find out if MacApp is compatible with MPW C. APDA tells >me that MPW Pascal is required to run MacApp, yet the APDAlog describes >MacApp as a library, so shouldn't I be able to just link the MacApp >library with a C program? Do I really need both Pascal and C compilers? > >Answers to the above questions, as well as general comments regarding MacApp >as a development environment, would be greatly appreciated. > >"Omit needless words." /\ | ) \ / > / \ | --- / > - Strunk and White / \ | ____ / \ > >John C. Juback Apex Software Corporation >{allegra,bellcore,cadre}!pitt!darth!apexepa!jcj Phone: (412) 681-4343 First, I'm not the world's greatest authority on MacApp, I just use it (and love it!), but you can not use C with MacApp. You need MPW Pascal. Period. Here's why: First, it is distributed as source (mostly Pascal, a bit of assembly). So you need Pascal to compile to object modules. Second, it's object oriented. That is, (among other things) the link modules have special naming conventions that can not be generated by MPW C. Not to mention the fact that all the methods are called via the method dispatcher (which works more or less by taking an integer selector and a handle to the object and looks up the actual address of the code based on these two things), and not just called procedures. Third, all the headers/interfaces to the units are in Pascal. Since the methods are somehow enumerated to create the selector numbers mentioned above, unless you figure this out, you would be calling the wrong routines (assuming that you were able to creat the C .h files (assuming you were able to write the dispatcher (assuming that you were able to call the methods with their funky names (assuming that you got it compiled in the first place)))). But, the good news is that MPW 3.0 with C++ is supposed to support all of this all by itself (or so I've heard - Duluth is a long way from where the action is :-). However, MacApp is, in my ego-inflated opinion, one of the best things to happen to programming since the Mac first came out. I've been Macprogramming since you had to do it on a Lisa, and wished there was a better way. I've always liked object oriented programming and even wrote a few libraries for making programming easier in TML (before I could afford MPW!). I even ported MacApp to TML. God that was awful. (Medium sized MacApp programs would hang the linker. If you had method "A" of both classes "one" and "two", you could only nest procedures inside one of the two methods (or face duplicate names). If you coded "BXOR(a,b)" the code would create a CMP instruction instead of an EOR.) But I did learn a lot about MacApp and how it worked. It can realy save you time by not having to recode main event loops in every program. Adding printing to (nearly) any printer involved about ten minutes of coding. It does however have a steep learning curve (as if Macprogramming doesn't already), but I found it well worth the time. You then spend your time writing code that makes your program do what makes it your program, and not writing code to make your program work like a mac program should. This is getting long, so mail if you have more questions. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= = "When I was young, all I wanted was to be | - gandreas@ub.d.umn.edu - = = ruler of the universe. Now that isn't | Glenn Andreas = = enough" - Alex P. Keaton | = =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=