[fa.info-mac] INFO-MAC Digest V2 #27

info-mac@uw-beaver (04/06/85)

From: Moderator John Mark Agosta <INFO-MAC-REQUEST@SUMEX-AIM.ARPA>


INFO-MAC Digest           Friday, 5 Apr 1985       Volume 2 : Issue 27

Today's Topics:
            New VMS versions of macput.c macget.c xbin.c etc.
                     Cursor control with MacTerminal
                Looking for bitmap -> MacPaint conversion
                Re: Things like Trash Can & Folder Icons?
                           PC Network opinions
                  Floating Point Co-processor for Mac?


----------------------------------------------------------------------

From: stew%lhasa@harvard.ARPA
Subject: New VMS versions of macput.c macget.c xbin.c etc.
Date: 	1 Apr 85 20:42 EST

[ Note This "shar" type file is saved in <info-mac>VMSGETPUT.COM,
  a name that conforms with VMS filenaming conventions.
  This superceeds Stewart's previous submission, VMS-MACPUT-GET-C.DCL
  Just the 00README file is duplicated here. -jma ]

$ COPY SYS$INPUT: 00README.TXT $ DECK/DOLLAR=">> End <<" Here is a new
VMS version of macget, macput, xbin and other things.  These programs
were originally written by Dave Johnson at Brown University, and were
modified for VMS and the Vax-11 C compiler by Stewart Rubenstein at
Harvard University.  It may be used and distributed but not sold for
profit.

The two programs which I have added are DUMPINF and FIXINF.  DUMPINF
will list the contents of a .INF file stored on your vax.  FIXINF
creates a new .INF file from an existing one by zeroing the location,
flags, lock and all undefined fields.  I have found that this
occasionally helps in downloading a recalcitrant file.  These may both
be used with any number of arguments, any of which may include
wildcards.  The fgen() function in FGEN.C is a general purpose C
interface for this purpose.

The low-level i/o routines have been sped up considerably.  MacGet, in
particular, should work much better and faster now.

This file should be unpacked by executing it as a command procedure.
It will create the files 00README.TXT (this file), DUMPINF.C, FGEN.C, 
FIXINF.C, GETPUT.C, MACGET.C, MACGET.HLP, MACGETPUT.H, MACPUT.C, 
MACPUT.HLP, MAKE.COM, RDT.C and TTYIO.MAR.  The command procedure 
MAKE.COM will compile and link everything.

Please send comments, bug reports, etc to:
   Stew Rubenstein
   rubenstein@harvard.arpa
   {ihnp4, seismo, ut-sally}!harvard!rubenstein >> End <<

------------------------------

Date: Thu, 04 Apr 85 22:15:30 EST
From: Tom Russell  <EN301034%BROWNVM.BITNET@WISCVM.ARPA>
Reply-to: EN301034%BROWNVM.BITNET@WISCVM.ARPA
Subject: Cursor control with MacTerminal

     This works because MacTerm pretends to be a VT100, and VT100s
     send that sequence of characters when you press their left-
     cursor-move key.

------------------------------

Date: Thu, 4 Apr 85 08:12:18 est
From: Ephraim Vishniac <vishniac%wang-inst.csnet@csnet-relay.arpa>
Subject: Looking for bitmap -> MacPaint conversion

A colleague of mine is attempting to transfer images from a Wang 
Professional Imaging Computer (PIC) to a Macintosh.  Converting from 
PIC native format to a straight bitmap is easy, as is cutting
rectangular regions of the bitmap and sending them to the Mac.
Problem: neither from Aztec C nor from MacPascal has he been able to
use PackBits successfully.

As a temporary solution, we're cutting regions of the right size for 
startup screens, and using screenmaker to do the conversion to
MacPaint format.  This isn't very satisfactory, as it only gives a
fraction of a full MacPaint page.

Can someone help us out with:

        An example of PackBits use in C? (Any C will do.)

        A program that does bitmap -> MacPaint conversion on larger
areas?

        An example of PackBits use in any language at all?

        The absolute ideal: source code for ScreenMaker?

Thanks in advance,

Ephraim Vishniac
  [apollo, bbncca, cadmus, decvax, harvard, linus,
masscomp]!wanginst!vishniac
  vishniac%Wang-Inst@Csnet-Relay

------------------------------

Date: Thu, 4 Apr 85 14:33 MST
From: "Kevin W. Laurent" <KLaurent@DENVER.ARPA>
Subject: Re: Things like Trash Can & Folder Icons?

This was covered last year on INFO-MAC (I had asked the question) but 
it's probably worth repeating cause I think this capability would be 
useful if available.  Herewith is my original request and Mark
Nodine's reply:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Date:  Wed, 31 Oct 84 13:17 MST From:
"Kevin W. Laurent" <KLaurent@DENVER.ARPA> Subject:  On Starting
Applications To:  Info-Mac@SUMEX-AIM.ARPA Message-ID:
<841031201752.497071@DENVER.ARPA> ReSent-date: Thu 1 Nov 84
15:47:52-PST ReSent-From: Ed Pattermann <PATTERMANN@SUMEX-AIM.ARPA> 
ReSent-To: info-mac: ;

There are two common ways to start a Mac application--opening the 
application itself (via File menu pick or double-click) or opening a 
document ``wedded'' to the application.  On the Xerox Star there is 
another way of starting an application (of course, they don't call it 
such) and I'm wondering whether this method is implemented on the Mac.
Let's call this third application start up method the
Drag-Icon-Outline method.  Here's how Drag-Icon-Outline works on the
Star (to start printing a document on the laser printer):

 1. The user selects a document icon to be printed and pushes either
MOVE
    or COPY from the keyboard (this is similar to the click-and-hold
    process on the Mac).
 2. The user moves the small version of the icon (icon outline on the
    Mac) over top of the Printer icon.
 3. The user clicks the mouse, dropping the small document icon on top
    of the printer icon (same as releasing the mouse button on the
Mac).
 4. The application begins.

A similar effect occurs on the Mac.  For instance, selecting a file
icon and dragging its outline on top of the disk icon until its image
inverts causes the dragged file to be copied to the now selected disk.
Two other cases exhibit similar characteristics--putting an
icon-object in a folder, and using the trashcan to discard an
icon-object.  So, again, the question I have is...Can an *application*
(suitably crafted) be started using the Drag-Icon-Outline method or
are the uses of this method restricted to Finder functions?

The idea behind using this method is that it alleviates the need for 
going through the open file sequence once inside the application (i.e.
selecting Open from the File menu, scrolling through a list of files
in an Open Dialog Box, and double-clicking the name of the file).

Any ideas?

 KLaurent@DENVER ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 #15 (55 lines in body):  Delivery-Date:  30 November 1984 08:23 mst 
Delivery-By:  KLaurent.Userast Date:  Friday, 2 November 1984 07:43
mst From:  Mark H. Nodine <mnodine at BBNH> Subject:  Re: On Starting
Applications To:  Kevin W. Laurent <KLaurent at DENVER> cc:  info-mac
at SUMEX-AIM, mnodine at BBNH In-Reply-To:  Your message of Wed, 31
Oct 84 13:17 MST

The Drag-Icon-Outline method which you have described could almost
certainly be implemented, but it would have to be the Finder that is
suitably crafted rather than (or perhaps in addition to - more on that
later) the application.  There is, however, a little-known fact about
the way the finder works which allows the same effect to be achieved
in certain circumstances.  Say, for example, you have a text file
which was not created with MacWrite, but which you wish to edit with
MacWrite.  What you can do is the following:
   (1) Select the text file.
   (2) Use shift-click to select MacWrite in addition to the text
file.
   (3) Choose Open out of the File menu.  This will fire up MacWrite
to open the text file.  There is a short-cut to steps 2-3 for the
adventuresome: it is possible to do a shift-double-click by holding
the shift key down for the first click in the double-click sequence
and releasing it before the second click.  This means you do
   (1) Select the text file.
   (2) Shift-double-click MacWrite.  That will do it.  For
applications which can multiple files to be open at once, this method
can be extended in the obvious way by preselecting all of the
documents before shift-double-clicking the application.

There are three restrictions to this method.  Perhaps the most painful
and least intuitive is that all the documents and the application have
to be in the same window for this to work.  This is because a
shift-click unselects anything which is not in the same window.  The
other two restrictions are on the part of the application.  The second
restriction is that the application must be written to take advantage
of what are called the Application Parameters.  These are pieces of
information which the Finder makes available to the application and
include the name of the application, the reference number of the
applications resource file, and some information about each of the
files which were selected when the application was started.  The third
restriction is that which the application places upon the kinds of 
files it is prepared to deal with.  In the case of MacWrite, for
example, it is glad to edit any file with type TEXT (the type of the
file is part of the information you get in the Application Parameters
for each file), but would probably not allow you to edit a file of
type APPL which contains resources.  For more information on the
Application Parameters, see the Segment Loader manual in Inside
MacIntosh.  For more information about how applications are to deal
with said parameters, see "The Structure of a MacIntosh Application"
(also in Inside Mac).

One additional problem is that multiple file selections do not get
presented to the application in the order in which you selected them,
but rather in an order which seems to be determined by their graphical
positions within the desktop.

So the long and short of it is that many programs can be started up to
be initially opened to a file which they did not create (i.e., one
which is not ``wedded'' to the application), and any programs you
write can be made to do likewise.

                              Enjoy,
                              Mark

------------------------------

Date: 4 Apr 1985 09:45-EST
Sender: LIZZA@USC-ISI.ARPA
Subject: PC Network opinions
From: LIZZA@USC-ISI.ARPA

        When looking for a good price on an external Apple disk drive
last year I discovered PC network was the cheapest.  At the time,
these drives were scarce so when I ordered I asked specifically if
they were in stock.  I was assured they were and that it would arrive
within two weeks.  After allowing three weeks I called customer
service and was assured that the drive would arrive momentarily.
After two more weeks I called again.  This time they checked the
inventory (for the first time) and I was told I was eleventh on the
waiting list!  It should only take another four weeks or so!
Infuriated, I cancelled the order and demanded that my $8.00
membership fee be refunded.  They said they would but my VISA was
never credited.

        Reviewing MacWorld, their prices are not generally any lower
than Bottom Line, et al, once all the extra charges are added
(wholesale plus 11% for credit cards).  Also, their catalog is most
poorly organized (you gotta know what you want by manufacturer,
browsing is a pain).  In short, I'll look elsewhere even if it might
cost a bit more.

------------------------------

Date: Thu, 4 Apr 85 09:19:03 pst
From: Gordon Finlay <finlay%civil.ubc.cdn%ubc.csnet@csnet-relay.arpa>
Subject: Floating Point Co-processor for Mac?

Does anybody know if someone has developed a hardware interface
between the Mac and a Motorola 68881 floating point co-processor? It
should be possible to do it using a daughter board in the same fashion
as the Hyperdrive. If so, do any companies developing compilers
provide or plan to provide support for it?

Several engineers I have talked to lament the lack of hardware
floating point support on the Mac for numerically intensive work such
as finite element problems. This is one area where they prefer the
IBM-PC with its support for the 8087.

------------------------------

End of INFO-MAC Digest
**********************