gerson@parc.xerox.com (Dan Gerson) (06/08/91)
I'd like to be able to use A/UX as a programming environment for building standard (non-A/UX) MacOS applications. Basically, I want to be able to use Emacs, g++, etc. instead of the limited development choices available under the MacOS. According to the 1.1 documentation (yes, I'm running 2.0.1 but I never bought a new doc set), the only apparent way to do this is for me to use GNU tools or whatever to write and debug the program under A/UX, and then to port the sources to the Mac, and run a MacOS compiler to generate the executable. I'd prefer to be able to use g++ etc. directly. One reason is that there is not a g++ which runs under MacOS. Of course, I will be writing everything in a AT&T C++ 2.0 conformant subset anyway, so I could possibly port the code to Zortech C++ or whatever. But that would preclude me from using any useful Unix libraries which might just happen to work under MacOS (that is, if they don't make any system calls - at least none that I don't supply my own version of. For example, lex and yacc should work ok when I define yyinput etc.). I understand that the problem is that the A/UX compilers will be generating AppleDouble files, where the data file is a COFF format executable. But this raises two questions: 1) Is there a way to translate COFF into CODE resources? If there isn't, is there any real reason why I couldn't write such a beast? 2) Even if I could translate COFF to a MacOS-style AppleDouble or AppleSingle, is it really worth it anyway? If I can use libg++, yacc, lex, etc., it might be. But will the linked images be usable under MacOS anyway? Can I simply redefine malloc etc., or is the problem much more pervasive? I can of course conditionalize the few calls which might require the Mactoolbox glue routines - but I don't expect to have many modules which actually require the code to be different between A/UX and the MacOS. Any ideas? Just give up and buy Zortech C++ (if it is available and is at least 2.0 conformant, although I prefer 2.1). -- Dan Gerson gerson@parc.xerox.com Xerox Palo Alto Research Center 415-494-4745 3333 Coyote Hill Road Palo Alto, CA 94304 USA
tony@tui.marcam.dsir.govt.nz (Tony Cooper) (06/08/91)
In article <GERSON.91Jun7135216@dupin.parc.xerox.com>, gerson@parc.xerox.com (Dan Gerson) writes: |> I'd like to be able to use A/UX as a programming environment for building standard |> 1) Is there a way to translate COFF into CODE resources? If there isn't, is |> there any real reason why I couldn't write such a beast? Yes. No. The COFF stuff has a whole library devoted to it under A/UX. So it's easy to get out what you want from a COFF file. Then just translate it to a CODE resource. I've never tried CODE resources but I wrote a simple program to turn a COFF file into a DRVR resource. I don't know what the format of a CODE resource is but it should be easy once you know. Tony Cooper
ksand@apple.com (Kent Sandvik) (06/09/91)
In article <GERSON.91Jun7135216@dupin.parc.xerox.com>, gerson@parc.xerox.com (Dan Gerson) writes: > I'd like to be able to use A/UX as a programming environment for building standard > (non-A/UX) MacOS applications. Basically, I want to be able to use Emacs, g++, etc. > instead of the limited development choices available under the MacOS. Well, it's a matter of taste, after a couple of years of exposure of Mac development tools, especially on the OOPS side, I'm not a die-hard UNIX tool user anymore (who could do C++ programming without a decent browser :-) ?). > According to the 1.1 documentation (yes, I'm running 2.0.1 but I never bought a > new doc set), the only apparent way to do this is for me to use GNU tools or > whatever to write and debug the program under A/UX, and then to port the sources > to the Mac, and run a MacOS compiler to generate the executable. Many of the GNU tools are ported to the MPW MacOS environment (gcc, g++ according to a rumor I heard last week, flex, bison...). Instead of gdb one could use Jasik's Debugger, SADE or SourceBug, which are far more graphical (and in that sense easy to learn). > I'd prefer to be able to use g++ etc. directly. One reason is that there is not > a g++ which runs under MacOS. Of course, I will be writing everything in a AT&T > C++ 2.0 conformant subset anyway, so I could possibly port the code to Zortech > C++ or whatever. But that would preclude me from using any useful Unix > libraries which might just happen to work under MacOS (that is, if they don't > make any system calls - at least none that I don't supply my own version of. > For example, lex and yacc should work ok when I define yyinput etc.). Someone correct me if I'm wrong, but the g++ does not conform in all cases with Cfront, so there are some additional features that will not work in either environment. We have both AT&T Cfront and Zortech C++ ported for the MPW environment (and I'm still waiting for the verification that g++ is ported as well). > I understand that the problem is that the A/UX compilers will be generating > AppleDouble files, where the data file is a COFF format executable. But this > raises two questions: Yes, the A/UX environment, as a UNIX one, produces SysV COFF object files, while for instance MPW has it's own object file format for inter-language linking. > 1) Is there a way to translate COFF into CODE resources? If there isn't, is > there any real reason why I couldn't write such a beast? I think that code conforming to ARM in the case of C++ is a better way for transporting software from one environment to another. You still have to take into consideration issues with operating system support, like how to for instance support fork/exec:s under MacOS (hint, latest d e v e l o p article had a good article about threads under MacOS). > 2) Even if I could translate COFF to a MacOS-style AppleDouble or AppleSingle, > is it really worth it anyway? If I can use libg++, yacc, lex, etc., it might > be. But will the linked images be usable under MacOS anyway? Can I simply > redefine malloc etc., or is the problem much more pervasive? I can of course > conditionalize the few calls which might require the Mactoolbox glue routines - > but I don't expect to have many modules which actually require the code to be > different between A/UX and the MacOS. Many of the standard C library routines, such as malloc, lseek and such are supported as libraries under MPW and Think C. The question in many cases, like both mentioned earlier, is about performance and how well this works under MacOS. As a good example: malloc is using NewPtr, a non-relocatable block of memory is reserved for the buffer. Now non-relocatable blocks of memory are not very efficient in small memory space systems (Classic, Mac Plus and such), so a rewrite using relocatable blocks (handles) is a better solution in the long term. Same with lseek, this is a basic routine, which does not take into consideration any of the special functions of the MacOS file system, which other trap calls do. > Any ideas? Just give up and buy Zortech C++ (if it is available and is at least > 2.0 conformant, although I prefer 2.1). A new MPW C++ with AT&T 2.1 support is on the pipeline. Regards, Kent Sandvik
paul@taniwha.UUCP (Paul Campbell) (06/09/91)
In article <GERSON.91Jun7135216@dupin.parc.xerox.com>, gerson@parc.xerox.com (Dan Gerson) writes: |> I'd like to be able to use A/UX as a programming environment for building standard |> 1) Is there a way to translate COFF into CODE resources? If there isn't, is |> there any real reason why I couldn't write such a beast? No not really, this is because most Unix compilers/linkers (including the A/UX ones) don't make position independant code (PIC), this is mostly because PIC code often runs slower (and data is a real pain). CODE resources need PIC code and a compiler that understands how to build an 'a5 world' I recomend you use MPW or some such Paul -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P Tom Metzger's White Ayrian Resistance has been enjoined to stop selling Nazi Bart Simpson t-shirts - Tom of course got it wrong, Bart is yellow, not white.
ksand@Apple.COM (Kent Sandvik, 120dB or more) (06/10/91)
In article <867@taniwha.UUCP> paul@taniwha.UUCP (Paul Campbell) writes: >In article <GERSON.91Jun7135216@dupin.parc.xerox.com>, >gerson@parc.xerox.com (Dan Gerson) writes: >|> I'd like to be able to use A/UX as a programming environment for >building standard > >|> 1) Is there a way to translate COFF into CODE resources? If there isn't, is >|> there any real reason why I couldn't write such a beast? > >No not really, this is because most Unix compilers/linkers (including >the A/UX ones) don't make position independant code (PIC), this is mostly >because PIC code often runs slower (and data is a real pain). CODE resources >need PIC code and a compiler that understands how to build an 'a5 world' >I recomend you use MPW or some such Paul, yes that's right, I totally forgot the issue with position dependent code. As a good example, check the binaries in the sash bin folder, those are genuine A/UX apps moved over to the MacOS environment, and they want to get loaded somewhere around 639k, so that's the reason some systems that have increased their system heap zone have problems with A/Ux Startup. reg, Kent PS: Anyone for Usenix/Nashville? -- Kent Sandvik, DTS Rock Lobster Disclaimer: I am not working with Public Relations.
tony@tui.marcam.dsir.govt.nz (Tony Cooper) (06/11/91)
In article <867@taniwha.UUCP>, paul@taniwha.UUCP (Paul Campbell) writes: |> |> |> 1) Is there a way to translate COFF into CODE resources? If there isn't, is |> |> there any real reason why I couldn't write such a beast? |> |> No not really, this is because most Unix compilers/linkers (including |> the A/UX ones) don't make position independant code (PIC), this is mostly |> because PIC code often runs slower (and data is a real pain). CODE resources |> need PIC code and a compiler that understands how to build an 'a5 world' |> I recomend you use MPW or some such I don't think this is true. I think PIC code is easy in A/UX, but maybe there are various degrees of PIC and maybe A5 globals mess things up. I wrote a DRVR resource using A/UX cc. I presume a DRVR needs PIC code. So I guess I was lucky that my code turned out to be PIC. Or was I? I don't know. But this is what I did: cc -O drvr.c ld -x -r -o drvr drvr.o -lmac -lat -lld -lmr -lc dumpcoff drvr .text > drvr.r where dumpcoff just does a hex dump of the .text part of drvr. Now since drvr has not been linked into an executable it is PIC is it not? Or maybe it is PIC as long as it has no global variables. In that case there is a way round that too so that globals (but not A5 globals) are stuck in the right place. And a bit of glue code can handle the case of A5 globals too. PIC code is important in Unix cos it's needed for things like dynamic linkers and shared libraries and whatnot. But I don't really know what I'm talking about. I don't know how long branches and various stuff like that is done. Cheers, Tony