rajohn@hubcap.UUCP (r alan johnson) (02/07/89)
This may be a stupid question, but since the Microsoft FORTRAN 4.1 compiler tells me that it is possible to link Microsoft C object files, is is just as possible to link Turbo C 1.5 object files? I want the Turbo C graphics in my fortran code, but I can't seem to figure this one out. The docs. aren't very much help, either in Microsoft's or Borland's case on this one. (Or am I reading the wrong pages?) An object file is an object file isn't it? (at least in this case?) Any help will be appreciated! Thanks, R. Alan Johnson (rajohn@hubcap.clemson.edu)
BVAUGHAN@pucc.Princeton.EDU (Barbara Vaughan) (02/08/89)
In article <4328@hubcap.UUCP>, rajohn@hubcap.UUCP (r alan johnson) writes: >This may be a stupid question, but since the Microsoft FORTRAN 4.1 >compiler tells me that it is possible to link Microsoft C object files, >is it just as possible to link Turbo C 1.5 object files? ...An object >file is an object file, isn't it? > No, unfortunately not. You can't even link together two Fortran routines compiled with different compilers. In the cases, such as you mention, where routines from one language can be combined with those from another, compatiblity of instructions, word length, I/O handling, and many other things that normally wouldn't be compatible has been estab- lished. Even then, one must proceed with great caution. A quote from my Lahey Fortran F77L manual, advising programmers who wish to link Lahey Fortran routines with Lattice C routines, will give you an idea of the complications: "Since Fortran stores multidimensional arrays in column-major order, while C stores arrays in row-major order, it is usually not convenient to pass multidimensional arrays... (if you do)...an n-dimensional array A that is declared: A(i1,i2,...in) ... must be accessed with subcripts reversed in C...: A(in,in-1...i1). Also, the first element of a C array dimension is 0, so Fortran arrays should be dimensioned (0:n-1) for an array of size n. " I have been looking for a library of Fortran-callable graphics routines (see my previous posting) and so far have heard of one, although I haven't seen it yet. It is called NO LIMIT by M.E.F Environmental, Limited of Austin, Texas. It provides "graphics, screen control, communications, character/string manipulation,", etc. The graphics it supports include the basic DRAW functions, GET, PUT, PAINT, ROTATE and various others. Microsoft is one of the four Fortran compilers they claim compatibility with. For those who are primarily interested in text screen control (scrolling, windows, etc.) along with cursor control and keyboard control, the Spindrift Library from Spindrift Laboratories, Arling- ton Heights, IL is quite useful. It is available for F77L (Lahey) and Microsoft Fortran. I have used it to create user-interface menus in my Fortran programs. Barbara Vaughan
mfryba@phoenix.Princeton.EDU (Martin Francis Ryba) (02/08/89)
In article <7104@pucc.Princeton.EDU> BVAUGHAN@pucc.Princeton.EDU writes: > I have been looking for a library of Fortran-callable graphics >routines (see my previous posting) and so far have heard of one, >although I haven't seen it yet. It is called NO LIMIT by M.E.F >Barbara Vaughan We have been using the EGA Toolkit by Connell Scientific Graphics with Lahey Fortran on various 286's and 386's with fine results. They claim their stuff can be compatible with *any* language or installed as a separate driver (or something like that). Essentially the toolkit is a bunch of routines written in assembly code. We also have some custom routines that use the Lahey interrupt to do simple things like cursor position and string output. Marty Ryba (slave physics grad student) They don't care if I exist, let alone what my opinions are! marty@puppsr.princeton.edu Marty Ryba (slave physics grad student) They don't care if I exist, let alone what my opinions are!
kaufman@maxzilla.Encore.COM (Lar Kaufman) (02/10/89)
In article <4328@hubcap.UUCP> rajohn@hubcap.UUCP (r alan johnson) writes: >This may be a stupid question, but since the Microsoft FORTRAN 4.1 >compiler tells me that it is possible to link Microsoft C object files, >is is just as possible to link Turbo C 1.5 object files? I want the Turbo C >graphics in my fortran code, but I can't seem to figure this one out. >The docs. aren't very much help, either in Microsoft's or Borland's case >on this one. (Or am I reading the wrong pages?) An object file is an >object file isn't it? (at least in this case?) Any help will be appreciated! Your best bet to marry Microsoft Fortran with Turbo C is probably a third-party product designed for the purpose. I suggest Phoenix Technologies' PLink-86 (or whatever is most current). Phoenix is located in Norwood, MA. Sorry, I don't have a phone number for them. -lar Secular Animism, a value system for our times. Lar Kaufman <= my opinions kaufman@Encore.com Fidonet: 1:322/470@508-534-1842 (Green Dog of MassNet Central)
BVAUGHAN@pucc.Princeton.EDU (Barbara Vaughan) (02/11/89)
In article <4869@xenna.Encore.COM>, kaufman@maxzilla.Encore.COM (Lar Kaufman) writes: >In article <4328@hubcap.UUCP> rajohn@hubcap.UUCP (r alan johnson) writes: >>This may be a stupid question, but since the Microsoft FORTRAN 4.1 >>compiler tells me that it is possible to link Microsoft C object files, >>is is just as possible to link Turbo C 1.5 object files? I want the Turbo C >> An object file is an object file isn't it? ated! > >Your best bet to marry Microsoft Fortran with Turbo C is probably a >third-party product designed for the purpose. I suggest Phoenix >Technologies' PLink-86 (or whatever is most current). This is not true; in my previous followup to this posting, I explained why. I have PLink-86 Plus, and I quote from their manual: "Do not mix and match object files from different compilers. Unlike mainframe compilers, microcomputer compilers are often incom- patible with each other. PLink86 plus will link the programs and tell you about addressing problems, but there is no way for the linker to know if the run-time systems of the two languages can coexist." The Microsoft linker and the IBM linker will do the same. If and only if a comiler claims to produse object code compatible with that of another compiler should you attempt to link the two. Even then, as I said before, you usually must use a restricted subset of both languages.
mcdonald@uxe.cso.uiuc.edu (02/12/89)
>If and only >if a comiler claims to produse object code compatible with that of >another compiler should you attempt to link the two. Even then, as I >said before, you usually must use a restricted subset of both languages. Not entirely true. I have used assembly glue routines to link Microsoft C and RyanMcFarland Fortran - and they use violently different calling conventions. The restricted part is true: you have to be sure that EITHER the run-time io systems are compatible, OR make sure that one doesn't get loaded. With the Microsoft languages, there are relatively easy ways to do this: compile with /Fa /Oil /Gs to get rid of as many calls as possible (remove stack check calls and use inline subroutines where possible) and generate assembly output. Then edit the .asm files to remove things like the __acrtused global. A MSC program done that way, with NO floating arithmetic, and using no IO, only harmless calls like strcpy, etc, will be pretty generically useable. Floating point is easy too, if you have an '87: use /FPi87 AND, and this is bizarre in the extreme, make a dummy assembler routine containing all those weird FISRQQ-like globals that appear in a link map you get if you link without any run-time modules. That is, make variables with those names and make them public, then assemble it and link with your files. (Microsoft languages with /FPi87 generate actual '87 calls in their .obj modules. BUT, unless you do this bizarre thing, Microsoft's LINKER REMOVES THOSE INSTRUCTIONS AND REPLACES THEM WITH SOFTWARE INTERRUPTS.) If they would document things better, it would be easier to do links like this. Doug McDonald
murphy@pur-phy (William J. Murphy) (02/13/89)
In article <7104@pucc.Princeton.EDU> BVAUGHAN@pucc.Princeton.EDU writes: >In article <4328@hubcap.UUCP>, rajohn@hubcap.UUCP (r alan johnson) writes: > >>This may be a stupid question, but since the Microsoft FORTRAN 4.1 >>compiler tells me that it is possible to link Microsoft C object files, >>is it just as possible to link Turbo C 1.5 object files? ...An object >>file is an object file, isn't it? >> > I have been looking for a library of Fortran-callable graphics >routines (see my previous posting) and so far have heard of one, >although I haven't seen it yet. It is called NO LIMIT by M.E.F >Environmental, Limited of Austin, Texas. It provides "graphics, I know of another library for Fortran graphics on the PC, it is a product called GRAFMATIC. A person I work with somehow got hold of the library of object routines, so I viewed the object code to see what is was. There seemed to be support for creating plots for publication. I doubt that I would use it since there are no docs with it. (yes it is pirated) and second, I would not use it since it is pirated. If you want a price, Programmer's Connection carried this product, so look in a Byte, or Computer Shopper to find their number. Bill Murphy