jcj@apexepa.UUCP (John Juback) (07/18/88)
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-4343gandreas@umn-d-ub.D.UMN.EDU (Glenn Andreas) (07/26/88)
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 | = =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
lsr@Apple.COM (Larry Rosenstein) (07/27/88)
In article <422@umn-d-ub.D.UMN.EDU> gandreas@ub.d.umn.edu.UUCP (Glenn Andreas) writes: >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? > >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: MPW supports bulding programs in any mixture of Pascal, C, and Assembler. I also think this is extended to include Modula-2 and FORTRAN, since 3rd parties provide MPW-compatible compilers for those languages. Any language that uses the MPW linker and run-time conventions can be linked with a MacApp program. This means you can use a FORTRAN or C routine inside your MacApp program. You still have to write some Object Pascal, however, because using MacApp means you have to override some methods to implement your user interface. MacApp places no restrictions on how you implement the internals of your application, so they can be in C, Fortran, Assembler, etc. The current version of MacApp is distributed as Object Pascal source, so you need a compiler that can build it. (Currently this means MPW Pascal or TML Pascal II; eventually Lightspeed Pascal 2.0.) >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 When MPW C++ is available (sometime in the fall), you will be able to write a MacApp program entirely in C++ (with no Object Pascal). You can make subclasses of Object Pascal classes in C++ and vice versa. (MacApp will continue to be written in Object Pascal.) Presumably, C++ programmers will get a compiler version of MacApp, so they won't need to have a Pascal compiler, but I don't know the details of this. The current version of MacApp available from APDA is 1.1.1; in the very near future a beta release of MacApp 2.0 will be available. MacApp 2.1 will be the version that supports C++. You can send any other questions about MacApp to me. (There is also a mailing list macapp@Apple.COM which will the current MacApp engineers as well.) Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr
mce@tc.fluke.COM (Brian McElhinney) (07/28/88)
gandreas@ub.d.umn.edu.UUCP (Glenn Andreas) writes: >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. You can call C functions from within MacApp-based programs. However, it is not for the faint of heart. You have to link the resulting program carefully, ignoring hundreds of link errors (Really! No, really! I mean it. It even says so in the manual). And you still have to understand and use MacApp. Brian McElhinney mce@tc.fluke.com