Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!DAVINCI.ACC.VIRGINIA.EDU!tmb From: tmb@DAVINCI.ACC.VIRGINIA.EDU ("Thomas M. Breeden") Newsgroups: comp.lang.modula2 Subject: (none) Message-ID: <8904201522.AA13845@uvaee.ee.Virginia.EDU> Date: 20 Apr 89 15:51:21 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Modula2 List Organization: The Internet Lines: 98 To: INFO-M2%UCF1VM.bitnet@jade.berkeley.edu Subject: Re: Logitech M2 Compilers Newsgroups: comp.lang.modula2 In-Reply-To: Organization: Image Processing Cntr, Univ of Va. Cc: In article you write: > >Rumour has it that the compiler division of Logitech folded and no longer >supports their Modula-2 compiler product line; does anyone have any information >substantiating this? Also, their VMS compiler seems not to conform to standard >calling procedures (when trying to link to C code this was discovered) and many >system calls requiring ADDRESSes seem not to function correctly. If anyone else >has had luck with such routines, please reply with E-MAIL. > Rob Rothkopf, Chairman of Computer Resources College of Natural Sciences & Mathematics State University of New York at Buffalo 404 Wilkeson Quad, Amherst Campus Buffalo, New York 14261 (716) 636-2235 I hope that it is not true that Logitech is abandoning their M2 compilers! If you have heard anything definite about that rumor, I would appreciate the info. I have made good use of the Logitech VMS compiler. Version 4.0-1 opsys interface definition modules appear to work well, though I haven't used all of them, of course. If you have a version on the compiler before 4.0, it would pay to get the later one, since they seem to have made a number of improvements which make it fit into the VMS environment better. Especially, they made it easy to call M2 procs from other languages. I have had good success using my M2 modules from VMS C programs (and also vice-versa, but UNFORTUNATELY, my boss is requiring new code be written in C). I would be glad to send you examples of C linked code or of any of our M2 support modules you might be interested in. I've accumulated a number of useful (admittedly non-standard) routines including: "MagTape0", raw magtape handling procs "Terminal", an extented replacement for Logitech's "AnsiTerminal", screen oriented output for ANSI codes "EditKeyboard", ANSI keycode reading "TextIO", a TextFile parameterized InOut "In1", guared input of numbers and strings "DynStr0", dynamic memory string handling procs etc. One problem with the supplied opsys $FOREIGN DEFINITION MODULES I have run into, however, is that for parameters marked as string descriptor passing (%STDESCR) will always pass a string, even if empty. VMS, however, sometimes uses a string descriptor address of 0 to mean no string, which has different implications from an empty string. Thus, for such a case you may need to write your own foreign definition module with an %IMMED ADDRESS parameter. (I have appended an example at the end here.) Generally, though, the fact that the M2 compiler will construct the string descriptor for you makes it easier to call these opsys routines with it than with, say, the DEC VMS C compiler. Logitech CommonInputOutputProcedures.DEF has: PROCEDURE LIB$GET_FOREIGN ( VAR %STDESCR getstr : ARRAY OF CHAR ; %STDESCR prompt : ARRAY OF CHAR ; VAR outlen : CARDINAL ; VAR forcep : BOOLEAN ) : CARDINAL ; (*##########################################*) %FOREIGN DEFINITION MODULE SilentGETFOREIGN; (* v1.0-112088 *) (*##########################################*) (* Necessary since Logitechs module CommonInputOutputProcedures Version 4.0-0 of FEBRUARY 1987 does not provide for null prompt, which is needed bypass prompting if no command line exists. *) FROM SYSTEM IMPORT ADDRESS; EXPORT QUALIFIED LIB$GET_FOREIGN; PROCEDURE LIB$GET_FOREIGN ( VAR %STDESCR getstr : ARRAY OF CHAR ; %IMMED prompt : ADDRESS; (* should be set to zero *) VAR outlen : CARDINAL ; VAR forcep : BOOLEAN ) : CARDINAL ; END SilentGETFOREIGN.