prabhu@amelia.nas.nasa.gov (Dinesh K. Prabhu) (04/04/89)
Hi Netters,
I recently got MPW C(3.0) and I am planning on switching to that
environment. Could someone give me helpful tips on converting LSC 3.0
code to MPW C ? I saw in recent postings that int == short on LSC
and int == long on MPW. Are there many more tiny details like this ?
How about the headers ? Are they radically different in the two
environments ? I would appreciate it if someone could me answers to
these questions. Please email or post.
Thanks
DINESH K. PRABHU
M/S 230-2, NASA Ames Research Center, Moffett Field, CA 94035.levin@bbn.com (Joel B Levin) (04/05/89)
In article <1748@amelia.nas.nasa.gov> prabhu@amelia.nas.nasa.gov (Dinesh K. Prabhu) writes: | I recently got MPW C(3.0) and I am planning on switching to that | environment. Could someone give me helpful tips on converting LSC 3.0 | code to MPW C ? I saw in recent postings that int == short on LSC | and int == long on MPW. Are there many more tiny details like this ?... An interesting topic. I have been playing with LSC sources for a while, and with MPW 3 it's gotten a lot easier. For instance, I just ported the entire TransSkel set with demo programs to MPW 3, and it only took a few hours over several evenings. After I clean it up and make it properly portable I'll probably post the diffs. If the code has a portable definition for integers, you only have to change the definition: e.g. typedef int Integer; becomes typedef short Integer; The hardest part was all the .h files; MPW 3 follows very closely the Inside Mac organization. So not only are the names different (e.g., MenuMgr.h => Menus.h) but you'll probably need to #include more of them; the most common example of this was Memory.h to deal with all the Handle handling (:-)) calls. Often this did not show up until Link time. You'll have to get the type declarations right on the toolbox calls, since the .h files contain full prototypes. I suppose there is a switch to suppress this, but I preferred just fixing them. This was things like ControlHandle ch; ... DisposHandle (ch); had to change to DisposHandle ((Handle)ch); and wp = GetNewWindow (..., -1); had to be wp = GetNewWindow (..., (WindowPtr)-1); and a ProcPtr had to be changed to a GrowZoneProcPtr, etc. The compiler will show you them pretty fast. The remaining chore is to build the resources. If you have a version of the application or (as in the TransSkel stuff) a foo.proj.rsrc, you can Derez them and build a Rez file. In the latter case you'll need to add the FREF and BNDL resources, or at least I did. If you only have the RMaker source, then you'll need RMaker, I guess. CreateMake does an OK job of making a useable makefile, though I always change it (one day I'll tackle CreateMake which is, after all, just a script). For doing non-applications (DAs, INITs, WDEFs, etc.), there's more that I won't get into; the support for that kind of stuff, especially for globals, is quite different on MPW from LSC. Check the MPW examples. /JBL UUCP: {backbone}!bbn!levin POTS: (617) 873-3463 INTERNET: levin@bbn.com
levin@bbn.com (Joel B Levin) (04/05/89)
In article <38226@bbn.COM> levin@BBN.COM (Joel B Levin) writes: |In article <1748@amelia.nas.nasa.gov> prabhu@amelia.nas.nasa.gov (Dinesh K. Prabhu) writes: || I recently got MPW C(3.0) and I am planning on switching to that || environment. Could someone give me helpful tips on converting LSC 3.0 | |An interesting topic. I have been playing with LSC sources for a |while, and with MPW 3 it's gotten a lot easier. . . . I forgot one other incompatibility: the quickdraw globals. In LSC one refers to thePort, dkGray, etc. In MPW these are in a structure called qd; one refers to qd.thePort, qd.dkGray, etc. /JBL [I really don't know what I'm doing...] = UUCP: {backbone}!bbn!levin POTS: (617) 873-3463 INTERNET: levin@bbn.com
dierks@ndmath.UUCP (Tim Dierks) (04/05/89)
From article <38240@bbn.COM>, by levin@bbn.com (Joel B Levin): >In article <38226@bbn.COM> levin@BBN.COM (Joel B Levin) writes: >>In article <1748@amelia.nas.nasa.gov> prabhu@amelia.nas.nasa.gov (Dinesh K. Prabhu) writes: >>> I recently got MPW C(3.0) and I am planning on switching to that >>> environment. Could someone give me helpful tips on converting LSC 3.0 >> >> [ Notes about going from LSC to MPW] > > [More notes about LSC -> MPW] One other thing is that Str255s are different: in LSC, they're arrays of characters, in MPW, they're a struct, which means you occasionally have to do different things to them. The most annoying, however, is the fact that in MPW, when you try to call a Mac function that takes a string, it assumes you're transferring a C string and messes with it. It also insists that you pass variable of type Point by reference, rather than by value. Fortunately, it provides all-caps versions of the functions that work just like LSC's, but it's a pain in the neck anyway (all this may have been fixed in MPW 3.0, in which case just ignore me.) Anyway, I've just got a header file that includes lines like: #define DrawString DRAWSTRING Its a kludge, but it works. Tim Dierks dierks@ndmath.cc.nd.edu
levin@bbn.com (Joel B Levin) (04/06/89)
In article <1353@ndmath.UUCP> dierks@ndmath.UUCP (Tim Dierks) writes: |From article <38240@bbn.COM>, by levin@bbn.com (Joel B Levin): |>In article <38226@bbn.COM> levin@BBN.COM (Joel B Levin) writes: |>>In article <1748@amelia.nas.nasa.gov> prabhu@amelia.nas.nasa.gov (Dinesh K. Prabhu) writes: |>>> I recently got MPW C(3.0) and I am planning on switching to that |>>> environment. Could someone give me helpful tips on converting LSC 3.0 |>> |>> [ Notes about going from LSC to MPW] |> |> [More notes about LSC -> MPW] | | One other thing is that Str255s are different: in LSC, they're |arrays of characters, in MPW, they're a struct, which means you |occasionally have to do different things to them. The most annoying, Aha! that's what was great about MPW 3 C! Strings are defined as unsigned char[N], so LSC code works directly. The other thing that made porting LSC code relatively easy was that they also went back to the canonical forms of Toolbox and OS calls; the C versions with glue now are all lowercase. I did some porting of LSC to MPW 2.0.2 C and this was a royal pain (actually only the strings were, because a version of Earle Horton's compatibility #include file allowed the use of the canonical forms). /JBL UUCP: {backbone}!bbn!levin POTS: (617) 873-3463 INTERNET: levin@bbn.com
austing@Apple.COM (Glenn L. Austin) (04/08/89)
In article <1353@ndmath.UUCP> dierks@ndmath.UUCP (Tim Dierks) writes: >From article <38240@bbn.COM>, by levin@bbn.com (Joel B Levin): >>In article <38226@bbn.COM> levin@BBN.COM (Joel B Levin) writes: >>>In article <1748@amelia.nas.nasa.gov> prabhu@amelia.nas.nasa.gov (Dinesh K. Prabhu) writes: >>>> I recently got MPW C(3.0) and I am planning on switching to that >>>> environment. Could someone give me helpful tips on converting LSC 3.0 >>> >>> [ Notes about going from LSC to MPW] >> >> [More notes about LSC -> MPW] > > One other thing is that Str255s are different: Not in MPW 3.0 -- they are both declared as arrays of unsigned char. >Mac function that takes a string, it assumes you're transferring a C string and >messes with it. Once again, MPW 3.0 takes the string as you pass it -- so if you pass it a C string, MPW does nothing to the string to convert it to Pascal format. > It also insists that you pass variable of type Point by reference, Any structure of 4 bytes or less is passed by value -- as defined in the MPW C 3.0 Reference. >Fortunately, it provides all-caps versions of the functions Wrong again. All functions are defined as they are in IM. If you want to pass information in C format and have it automagically converted to Pascal, the functions that you call are all lowercase letters. About the only thing you have to worry about is that MPW defines int as a 32-bit value, whereas LSC defines them as 16-bit values. However, a simple header file can take care of all of this for the Mac: /* portable.h */ #ifndef Integer #define Integer short #endif #ifndef Longint #define Longint long #endif #ifndef NIL #define NIL 0L #endif ----------------------------------------------------------------------------- | Glenn L. Austin | The nice thing about standards is that | | Apple Computer, Inc. | there are so many of them to choose from. | | Internet: austing@apple.com | -Andrew S. Tanenbaum | ----------------------------------------------------------------------------- | All opinions stated above are mine -- who else would want them? | -----------------------------------------------------------------------------