INFO-MAC-REQUEST@SUMEX-AIM.ARPA (Moderator David Gelphman...) (11/20/86)
INFO-MAC Digest Wednesday, 19 Nov 1986 Volume 5 : Issue 13
Today's Topics:
Pop-up menus
A plea to developers
Re: Apple's response about Bugs in Apple Software
Macro editor for macintosh
EDT.MEdit
Re: MW 4.5 Counter
Re: Calendar program
Re: HD vs. Floppy: $/Kb
Re: HFS Fonts?
Info Wanted: Macintosh in the Laboratory
MacSPICE?
Re: connecting Tandy 200 to a Mac
document can't be opened
Difficulty in launching MacWrite
New system
Apple II Emulation on LIsa
Defender addendum
----------------------------------------------------------------------
Date: Wed, 19 Nov 86 12:15:44 PST
From: gunther.pa@Xerox.COM
Subject: Pop-up menus
This question relates to the MacTutor, Dec. '85, article by Mike
Schuster on Pop-up menus for the Mac. I've tried, unsuccessfully, to
implement it in Megamax C. Schuster apparently provides the Megamax
source as well as the printed Consulair source on a disk available from
MacTutor. I'm so far along now I'm really interested to find out why my
version does not work.
Has anyone either successfully implemented this code in Megamax C or
does anyone have the MacTutor Megamax source?
Some things puzzle me about how the bitmap allocation and pointers are
implemented. For one thing, it looks like the base address is
initialized to an odd address (bitmaps are supposed to be word-aligned)
but I may not be understanding it correctly.
Any insights would be appreciated.
Neil.
------------------------------
Date: Wed, 19 Nov 86 13:46 EST
From: CML5A9%IRISHMVS.BITNET@WISCVM.WISC.EDU
Subject: A plea to developers
After spending an afternoon with lots of other peoples
C code, I'd like to remind developers of programs for
the macintosh to PLEASE PLEASE PLEASE use something
like short,long,int16 or int32 when defining integers,
instead of the generic int.
Every person who writes a C compiler does the int in
a different way, and they all seem "wrong" to at least
one person.
This is especially true when writting code involving:
-Files
-ROM calls (!!!!)
-I/O
-Machine independant and portable code.
And needless to say, if anyone else is going to use the
source code, this applies even more!!!
It's simple enough to add a
#define int16 short
#define int32 long
(or whatever your compiler works with)
to the top of the code.
I thank you.
-Tom Dowdy
CML5A9@IRISHMVS.BITNET
"I am increasingly of the opinion that a vast majority
of wrong thinking people are right."
------------------------------
Date: Wed, 19 Nov 86 08:56:03 PST
From: chuq@Sun.COM (Chuq Von Rospach)
Subject: Re: Apple's response about Bugs in Apple Software
Let me take a differing position from Dave on George Deriso's note:
> After speaking with him, I concluded that the reason Apple hasn't done
> an adequate job supporting their products is because their resources
> are tied up in the new products. It seems to me that although everyone
> is excited about new products from Apple, it is shortsighted to not
> support the existing products. THERE ARE REAL PEOPLE OUT THERE WHO USE
> THEM AND EXPECT THEM TO WORK PROPERLY.
> I agree that the system software suffers from the problems mentioned above,
> namely may affect third party programs or Apple products. It is hard for
> me to understand how fixing MacWrite, MacPaint, or MacDraw bugs will affect
> third party products.
I disagree with this. There are products that aren't getting as much
support as they used to from Apple, both software and hardware. But frankly,
do they need it? I really don't think so.
The areas that need support ARE being supported -- the System, Finder,
printer files, and the ROMs. All of the critical parts of the Macintosh
that can only be dealt with by Apple.
What isn't being dealt with? MacWrite, MacPaint, and MacDraw.
MacWrite almost singlehandedly killed off the Word Processing market for the
Mac. It, like the 128K Mac (remember that?) is an obsolete product. Why
would anyone buy MacWrite at $195 (list -- remember, it isn't free anymore)
when they can buy Word for about $100. Or WriteNow, or any of the other
half dozen or so Word Processors that are invading the market now that
MacWrite has taken the back burner.
The same can be said for MacPaint. Both of these programs, by the way,
significantly deviate from published Apple interface standards. To bring
them up to spec would require many non-compatible changes to the programs.
Apple has made the decision to stay out of the application market. Since
the early days, when Apple marketed Mac programs because it had to, they've
left it all to third party people -- with the result that there are LOTS
of really good, competitive programs for the Mac. If Apple put resources
into updating these programs and started re-marketing them, it certainly
WOULD affect the third party market, to everyone's detriment.
I threw out my copy of MacPaint months ago, as well as MacWrite. I couldn't
function without Word, without FullPaint. If Apple hadn't taken this
stance and let the third party people take over the application market,
the mac would be much worse off. Apple, very rightly, sells machines, and
lets the rest of the world sell the programs that make the machine shine.
(Asute readers will notice I've glossed over MacDraw... Herein we bring it
into the fray)
The one place where I might disagree with the above is MacDraw. Why? Because
as of now, there isn't an application on the market that has replacement
functionality. SuperPaint probably will, once it leaves beta, but it isn't
really out and isn't accepted. Until such a time as something in the
third party, Apple needs to continue to support it so that people aren't
left out in the lurch.
Saying that Apple needs to dedicate lots of resources to MacWrite is like
saying it needs to dedicate lots of resources to the 128K skinny-Mac. It is
old, it is obsolete, it was wonderful then, rest in peace.
> >While Apple is no longer an "out-of-the-garage" company, its larger size
> >does not necessarily mean that we have endless resources to devote to these
> >tasks. The engineers who are sustaining existing products and effecting
> >fixes are also working on future generations of products.
> This seems to me to be a serious problem. If Apple must support existing
> products by using people who are working on newer products then that seems
> to me to be neglecting the interests of those who are currently using the
> product. This implies that there will never be nearly bug free software
> for any Apple computer since there will always be another product which
> is being worked on.
This is a fact of the real world. People don't like to do 100% maintenance
programming. If you don't give them new toys to play with, they find
companies who will. The person who enjoys maintenance programming is
rare indeed, and should be cherished...
Again, though, it is a matter of where the resources can best be put.
Why maintain obsolete software where there is better, compatible and cheaper
software on the market? I'd rather see new and nifty finders and better
hardware than a bug-free MacWrite. We don't NEED a bug-free MacWrite.
Apple isn't perfect, but in the last year they've made great strides.
APDA, posting system software to CompuServe and Delphi, they've worked
hard to improve between them and The Rest Of Us. The Mac Software is
faster and more reliable, there are a lot of really hot products in markets
(WP and Paint tools) that previously Apple had choked off with their products.
I'd rather see them continue the trends they've built than go off and bring
back the things that slowed down the third parties and shut down development...
chuq
------------------------------
Date: Wed, 19 Nov 86 15:31:21 PST
From: digiorgi@Jpl-VLSI.ARPA
Subject: Macro editor for macintosh
Listening to the conversations of people desiring a macro-capable
editing environment for the Macintosh, I was fairly amazed not to
hear anyone using MEdit for their work. I was also amazed that it had
not gotten to the SUMEX-AIM archives. MEdit is a menu-driven,
macro editor with a macro compiler and rather a nice set of
capabilities:
opens arbitrary #of windows (dependent upon RAM)
can be configured to act like your favorite EMacs, EDT etc
editor to a good degree.
allows binding of macros to arbitrary keys
has an auto-configuring transfer menu:
launches via SFGetFile the first time, automatically
inserts the pathname into a 5 position menu for
one click transfer
works on every Macintosh hardware configuration I have tried
thus far (XL,128,512,512E,Plus,Extended memory systems)
works under Switcher
opens arbitrarily large documents (limited by total RAM space)
comes with complete documentation
can open non-TEXT files
It only has a few drawbacks:
Large documents are sectioned into (max 32K) pages. Page size
is configurable.
Speed decreases with size of page.
On 64K ROM systems, it is sometimes a bit slow in character
throughput.
I use it constantly, as it produces either soft-wrap TEXT for inclusion into
Word or hard wrap TEXT. Much of my time is spent preparing
documents for upload to VAXen and I find it fantastic.
MEdit is ShareWare ($25 if you keep it... pay the man!) and the author
says, colloquially, "give it to anyone you want, but give all of it".
The author (Jacob Aebi? i always get his name wrong...) is the person
who brought the PD Modula-2 compiler to the networks. He is listed in the
About... dialog and in the documentation.
The following is a BinHex 4.0 version of a PackIt II compressed file and
contains:
MEdit v1.5
MComp
KeyCode DA
Medit.doc v1.5
Macros.mcr
Macros (compiled)
Pascal.mcr
Pascal (compiled)
The documentation is in MacWrite 4.5 format, set up for LaserWriter and
European paper. It was rather easy to reformat it for USA standard and is
very nice. The .mcr files are the standard macro examples.
Hope you all find this useful.
Godfrey DiGiorgi :: November 19, 1986
c/o digiorgi@jpl-vlsi.arpa
(my employer doesn't want to know anything about this net.)
"Sometimes in the middle, sometimes at the edges..."
[ archived as
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>UTILITY-MEDIT-15.HQX
DAVEG
]
------------------------------
Date: 19 Oct 86 11:31:10 EDT
From: Jeffrey Shulman <SHULMAN@RED.RUTGERS.EDU>
Subject: EDT.MEdit
[ Uploaded from Delphi by Jeff Shulman ]
Name: MEDIT VAX EDT MACRO
Date: 18-OCT-1986 21:05 by TECHNISOLVE
This is A MEdit Macro which emulates the VAX/VMS EDT editor. I have tried to
implement the most common Keypad Commands. I find it useful since I work on a
VAX for a living.
[ archived as
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>UTILITY-MEDIT-EDT.MACRO
DAVEG
]
------------------------------
From: "Steve Munson" <sbm@purdue.edu>
Subject: Re: MW 4.5 Counter
Date: Wed, 19 Nov 86 12:27:05 EST
Actually, the grep-wc DA, archived as DA-GREP-11.HQX, also counts
words, and it's free.
Steve Munson
sbm@Purdue.EDU
sbm@Purdue.CSNET
------------------------------
Date: Mon, 17 Nov 86 14:56 N
From: <INFOEARN%HLERUL5.BITNET@WISCVM.WISC.EDU>
Subject: Re: Calendar program
Keith,
This may or may not help, but friends of mine have written a calendar program
for use on AppleTalk with Omnis III, the multiuser database. You might
consider a similar solution.
-- Thomas
FRUIN@HLERUL5.BITNET
------------------------------
Date: Tue 18 Nov 86 23:30:43-PST
From: John M. Relph <Relph@BIONET>
Subject: Re: HD vs. Floppy: $/Kb
While I cannot find fault with Carl Dunham's math in his recent message,
there is one all-important assumption that was not made.
Time = Money (multiplied by some magic number)
*flame on*
I don't care how cheap floppies are when I have to swap two of them in
and out of the drive fifty times in a row to save one simple file or
load one font from another disk. And if I have to move files around
just to prevent such hairy disk swappage, then the time and trouble
I have to take to move said files is another hassle I don't need.
And of course, there's the plain speed difference. I'm not going to
rehash the figures for times to boot or launch an application from
a hard disk versus a floppy (DS or SS). And if you are doing something
like desktop publishing with Pagemaker, pasting in fullscreen paint
documents (and reducing them), and accessing word files, are you going
to want to have to always move the pertinent files to that work disk,
so you can reduce the number of swaps necessary? Yuck.
*flame off*
This factor makes the hard disk a very worthwhile investment.
-- John (Relph%Bionet@Sumex-Aim)
(we don't need no stinking disclaimers)
------------------------------
Date: Wed, 19 Nov 86 09:19 EST
From: CML5A9%IRISHMVS.BITNET@WISCVM.WISC.EDU
Subject: Re: HFS Fonts?
There was a question recently concerning the use of Word
and various fonts.
It has been my experience with Word that it does not always
handle fonts correctly. It is esp bad with LW Plus fonts,
printing in courier or some other such strange font instead
of what you asked for. As near as I can tell this is most
definately a Word problem. It (should) have nothing to do
with the file system you are running under.
As to the request for an "other" DA for fonts. This is
almost impossible to do. In addition, if it was done, it
would not be simple to use, requiring that you run the
DA before launching the application. Word (and as far as
I know all other Mac programs with font support) load in the
list of fonts at launch time. Changing the available fonts
during a run would not do anything. You would have to quit
Word and return to have access to these newly installed fonts.
I suspect this is why you haven't seen a Font/DA mover DA,
because it just isn't practical.
-Tom Dowdy
CML5A9@IRISHMVS.BITNET
"I am increasingly of the opinion that a vast majority
of wrong thinking people are right."
------------------------------
Date: Wed, 19 Nov 86 14:48:22 mst
From: bw%a@LANL.ARPA (Barbara Weintraub)
Subject: Info Wanted: Macintosh in the Laboratory
[]
Does anyone have experience using a Macintosh computer for data acquisition
and control of experiments? This request covers the new commercial
software/hardware packages (eg, LabView, BenchTop) and those developed for
use in your own lab.
Can a Mac function as a digitizer or storage 'scope?
Any information and opinions are welcome.
Thanks,
Barbara Weintraub USnail: LANL
Los Alamos Nat'l Lab CLS-7, MS E525
ARPA: bw@lanl Los Alamos, NM 87545
UUCP: ...cmcl2!lanl!bw Phone: (505) 667-9742
------------------------------
Date: Wed, 19 Nov 86 16:56:44 pst
From: mab@ads.ARPA (Mike Brzustowicz)
Subject: MacSPICE?
A friend of mine is look for some circuit simulation software for the mac
along the lines of SPICE. Does anyone know of any? Has anyone used any?
All pointers gratefully accepted.
-Mike
<mab@ads.arpa>
------------------------------
Date: Tue, 18 Nov 86 23:01:39 EST
From: Tim Browne <browne@MEDIA-LAB.MEDIA.MIT.EDU>
Subject: Re: connecting Tandy 200 to a Mac
Does anyone know the correct answer to the tandy 200 to Mac riddle of
a few days ago. Simple restated: what cable is the right cable for
handshaking both ways?? NOT THE 100...Thanks, Tim
------------------------------
Date: 17 Nov 86 16:42:51 EST
From: Patrick.Muir@rover.ri.cmu.edu
Subject: document can't be opened
I created a document with MacWrite, Saved it and later tried to open it. The
Mac responds with "This Document Can't Be opened". I can copy the document
without any problems, but I can't print or open it. Anyone have any
suggestions as to how I can get the document back?
------------------------------
Date: Wed, 19 Nov 86 09:56 EDT
From: <JCLARK%UTKVX1.BITNET@WISCVM.WISC.EDU>
Subject: Difficulty in launching MacWrite
I, too, had been receiving a "This application is either open or missiing..."
dialog box in attempting to open a MacWrite document. If I first opened
MacWrite, then there was not problem. This was on a MacPlus, SCSI hard
disk, using MacServe. I had not been using Switcher. I tried turning
cache on and off, checking to see if the the file were indeed "busy"
using the File Tools DA etc. I still had the problem whether
or not MacWrite was being launched from a floppy disk or a MacServe
volume. Finally as a last resort, I tried moving a copy of MacWrite onto
the desktop and opening a document directly from the Finder. It worked!
I have had no problems since when launching from a floppy or a MacServe
volume. I have no idea was is/was going on, but thought others who have
commented recently that they had had this problem might want to know at
least one work-around.
------------------------------
Date: Sun, 16 Nov 86 19:30:32 EST
From: ST401385%BROWNVM.BITNET@WISCVM.WISC.EDU
Subject: New system
Am I the only one, or has anybody else noticed that the new
"improved" system/finder for the mac SUCKS? It is terrible. It is
MUCH worse than the old system. If I thought they would do it, and
wasn't aghast at the thought of having to transfer all my files
(that I painstakingly transfered onto double sided disks) back onto
single sided ones, I would take my mac back to the computer store and
ask them to take out the new chip and the double sided disk-drive and
put my mac back the way it was before.
The advantage of the new finder is that it now knows about folders.
For an ordinary mac without a hard disk, this is a dubious improvement,
especially as the people who wrote the new finder chose to show you
everything that's in a folder when you open something from within
an application, even the things that you can't open. This may have
some minor value, but it mostly clutters up the filing system.
The main disadvantage of the new system is that it is damn huge.
On my old mac, I used to work by putting the system, finder, printer
driver, and application I wanted to use onto a RAM disk, and keeping the
files I want to work on on real disk. This worked fine; it meant I could
have plenty of space on my work disk, since they didn't need
system, finder, printer driver, or applications on them. On the new
system this seems to be impossible, apparently because of the size of
the system (I'm using--or trying to use--the program Ramstart 2.22,
which seems to be the latest version available. The program bombs
when you try to put the system on the ramdisk and then run it.) This
means the double sided disks really can't store much more than the old
single sided ones, since they have to have all the old junk that I used
to keep on ramdisk.
The new system is pretty stupid, too. It continuously wants
disk swaps, even when you can't figure what in the world it wants
them for. It is far too stupid to use free memory or even cache
to look ahead for information it will need off the disk in the future,
but instead asks for ten or fifteen disk swaps when launching an
application.
Example: I had system on one disk, MacWrite on Ram disk, and
I needed to look at a file on another disk to see if it was the
current version. Just LOOK, mind: not write anything. In order
to look at the file, the mac made me do TWENTY DISK SWAPS
between the disk with the system and the disk with the file I wanted
to look at. This is with MacWrite in Memory--I'd hate to guess how
many swaps it would want if Mac Write were on the system disk.
Why don't I just get a second disk drive or a hard disk, you
ask. Well, until I got this "upgrade", I was perfectly happy with
just one drive. I resent the fact that "improving" the ROM seems to
be a ploy to make me spend money on a second drive. Further, if the
Apple people think that the machine really needs two drives to run,
then, damn it, they should have made a machine with two drives.
They try to be suckering you in with a one drive machine, then either
forcing you to buy another drive to make it work well, or else
throw it out and find another brand.
The new system has a RAM-cache, which is pretty much useless.
First--secret number one--you can apparently turn it on and off
from the control panel, but actually doing this does nothing unless
you turn power off. Worse, though, one of the mac people here
explained that the cache is NOT write-through.
What this means is that if you are working on a document, say, and
"save" it, you actually save it to cache, not to disk. THIS IS
TOTALLY UNACCEPTABLE. The point of saving files is that in case of
a system crash (and macs DO occasionally bomb, despite what apple
seems to think), your document has been saved. But if it's only
written to cache, bye-bye document.
This is not an academic question. Another little "problem" the
new system has is that if the printer driver doesn't work, the machine
doesn't tell you. It doesn't give you an error code, it tells you
"Printing in progress" and then it hangs there. Forever. Or until you
turn off the machine. Among other things, when the computer store
installs the new ROM chip, they randomize the printer drivers (and don't
tell you about it) so that you can't print until you re-initialize the
printer choice using "chooser" and control panel from the desk accessories.
I lost one file this way, and spent about two days trying to figure out
what the computer store had screwed up to make it not print. Fortunately
it was a small file.
I could go on, but this whole thing annoys the hell out of me. When I
got the upgrade, I expected the system to work better, not worse. If I'd
wanted a cumbersome dinosaur, I would have gotten an IBM.
My advice: don't "upgrade" your system to the new ROM and double
sided disk drive unless you have a hard disk or two drives.
[ note from moderator: The comments above regarding the Mac disk caching system
are incorrect. According to postings from people at Apple computer, any
application which writes to disk should also FLUSHVOL to ensure that the
changes are actually written to the disk. Applications which do a SAVE and
don't flush the volume make the user run the risk of losing data if there
is a system error/power loss before a flushvol occurs. THIS BEHAVIOUR IS
THE SAME WHETHER YOU HAVE THE CACHE ENABLED OR NOT. The moral is that if
applications are written correctly you will not be affected by the state
of the cache. DAVEG ]
------------------------------
Sender: BHolland.ElSegundo@Xerox.COM
Date: 17 Nov 86 09:45:08 PST (Monday)
Subject: Apple II Emulation on LIsa
From: BHolland.ElSegundo@Xerox.COM
Will the Apple II/+/E/I Emulation work on the Lisa using Mac works ??
Bill
------------------------------
Date: Tue, 18 Nov 86 12:58:35 CST
From: AntiNeophilus <dubois@unix.macc.wisc.edu>
Subject: Defender addendum
The defender game posted by Bruce Horn is very nice. One missing command
in the instructions is that the command key reverses direction.
Yours,
Paul DuBois
------------------------------
End of INFO-MAC Digest
**********************