INFO-MAC@SUMEX-AIM.STANFORD.EDU.UUCP (03/02/87)
INFO-MAC Digest Monday, 2 Mar 1987 Volume 5 : Issue 59
Today's Topics:
DrawPicture and Scrolling
Draw/Word Mystery
Frozen Cursor
Shutting down & SCSI drives...
shutting down HD20
Re: MacPaint (V5 #58)
warning about Finder substitutes
Word 3.0 review (long)
MacHangul (Korean Language)
Conference on compatibility with "future" Macs
Many, many, many comments about AppleShare
DVI to ImageWriter
IBM PC <-> Macintosh Word conversions
Kanji Talk
Re: KanjiTalk (was Chinese Macintosh Softwares)
Macintosh Compatibility Alert (forwarded from Joel West)
Usenet Mac Digest V3 #16
Usenet Mac Digest V3 #17
----------------------------------------------------------------------
Date: 28 Feb 1987 10:08-EST
From: Chuck.Weinstock@sei.cmu.edu
Subject: DrawPicture and Scrolling
I want to scroll a picture that is larger than my window. I cannot
figure out how to tell QuickDraw to make a different portion of the
picture visible. Can anyone give me a hand?
Chuck
------------------------------
Date: Thu, 26 Feb 1987 22:10 PST
From: GFA0009%CALSTATE.BITNET@wiscvm.wisc.edu
Subject: Draw/Word Mystery
I recently prepared a diagram in Draw (saved in PICT format), copied it to
the Clipboard, and pasted it into a Word document. It looked just fine on
the screen. I printed the document on a Laserwriter and lo and behold!
some of the lines in the diagram didn't print. I went back to Draw, and it
printed just fine from there. I tried bringing the lines to the front,
grouping, etc., and cuting and pasting via the Scrapbook. But each time
the same problem recurred: the diagram looked correct on the screen, but
the same ##&@!! lines were omitted from the printed copy.
I can't figure out why this is happening. Has anyone had similar problems?
Are there any suggestions/work-arounds? I'd be grateful for any advice...
Thanks in advance.
Andre Lehre
Geology
Humboldt State University
P.S. I am using a Mac+ with current versions of System and Finder; printer is
a Laserwriter+ again with the most current driver and prep; Draw is 1.9,
Word is 1.05.
------------------------------
Date: 28 Feb 87 19:34:00 EST
From: Richard Zaccone <ZACCONE%BUCKNELL.BITNET@wiscvm.wisc.edu>
Subject: Frozen Cursor
I just did some house cleaning on my DataFrame. After getting rid of some
files, I backed everything up with SuperBackup. Now, everytime I change
into the directory that contains SuperBackup, the cursor freezes. No
matter what I do, it won't move (which means I can't get out of the
directory again or do anything else). I have to push the restart button to
get out. I tried throwing away the directory and then restoring it, but
this didn't work. I still get a frozen cursor when I change into the
directory. Can anyone tell me how to get out of this? I now have a whole
directory of programs that I can't use!
Rick Zaccone
zaccone@bucknell.bitnet
------------------------------
Date: Sat, 28 Feb 87 12:43:23 EST
From: JURGEN%UMASS.BITNET@wiscvm.wisc.edu
Subject: Shutting down & SCSI drives...
The info on shutting down in the last digest was very helpful as i am also
working on a project that needs to make use of it... But this brings up an
interesting question in my mind... I have a Dataframe 20 that was upgraded
with the XP ROMs, and while I am _extremely_ pleased with its performance,
the amount of time needed to restart after a crash is a _royal_ pain in the
rear. I'm doing some very experimental development work, and crashes are
frequent. So... my question is this: would it be possible to install a
"valid" shutdown as an init somehow so that the proper unmounting and re-
starting is performed when a system error occurs..? Kind of like some of
the "crashsaver" inits I've seen out there..? I don't have much experience
with init resources, which is why I'm posting this question here first,
but I think such an animal would be highly appreciated by a lot of users,
and I'd be willing to try and write one. Any info and comments welcome...
Jurgen E Botz
------------------------------
Date: Sun, 1 Mar 87 13:50:09 PST
From: digiorgi@Jpl-VLSI.ARPA
Subject: shutting down HD20
A clean way of shutting down, at least with the HD20, is to
elicit the ShutDown item in the Finder and just hold the Mouse
Button down until you power off the machine. I have had much fewer
directory mishaps and much faster booting when I did this.
Holding the mouse button down, the machine cycles through ejecting
diskettes from the floppy drives. It only starts a boot sequence
after you let up the mouse button.
Godfrey DiGiorgi
digiorgi@jpl-vlsi
March 1, 1987
------------------------------
Date: Sat, 28 Feb 87 15:29:24 PST
From: jww@sdcsvax.ucsd.edu (Joel West)
Subject: Re: MacPaint (V5 #58)
The file format is fully described by Tech Note #86, which also
includes a useful program to read MacPaint files.
Joel West
{ucbvax,ihnp4}!sdcsvax!jww (ihnp4!gould9!joel once I fix news)
jww@sdcsvax.ucsd.edu if you must
------------------------------
Date: Sun, 1 Mar 87 21:17:47 EST
From: Mike Kraley <kraley@ccw.bbn.com>
Subject: warning about Finder substitutes
Each day I learn more wonderful things that the Finder very
quietly does for us. Since these are not well documented (at
least in anything I've ever seen), some programs can get you into
trouble. For example, I've just been using DiskTop, an otherwise
wonderful Finder subsitute DA that allows you to move, rename,
delete, find, etc. files. But beware: if you move an application
with DiskTop, and you then try to launch a document that
corresponds to that application, the Finder will give you an
error message. It seems that the Finder keeps track of where the
application of each kind is located in a resource in the Desktop
file and keeps this up to date when it moves an application.
DiskTop obviously does not do this. This is alluded to in IM,
but not really spelled out.
The algorithm to just move a file (move vs. copy, setting Finder
flags right, fixing the desktop, getting both forks, etc.) is
decidedly non-trivial.
...Mike
ps. to the poster who asked a couple of weeks ago about the
format of this resource, I've pretty much figured it all out now.
if you still need help, let me know.
------------------------------
From: jww@sdcsvax.ucsd.edu (Joel West)
Date: 28 Feb 87 02:55:33 GMT
Subject: Word 3.0 review (long)
[
archived as [SUMEX-AIM.Stanford.EDU]<INFO-MAC>REPORT-WORD-30.TXT
DoD
]
------------------------------
Date: Sat 28 Feb 87 01:47:03-PST
From: Seung Yoo <YOO@SPOCC.STANFORD.EDU>
Subject: MacHangul (Korean Language)
This is the shareware program about Korean language.
It consists of 2 programs. Mac Hangul(III) 3.11 is a DA
to make the keyboard to Korean. Hangul 3.01 is nine Korean fonts.
After you choose Mac Hangul from DA menu and Hangul font from font menu,
you can make Korean. Also you can mix English and Korean.
Mac Hangul is compatable with MacWrite (4.5) and MS Word (1.05) .
Following is the list of the people for more information.
1) Dr. Young-Soo Kim : Author 2) Dr. Byung Woo Kong
823-2 Siheung-Dong, Kuro-ku, 1015 Thornton Ct.
Seoul, Korea 150-03 North Wales, PA 19454
Tel) Seoul 803-5347 Tel) 215-362-7950
3) Kyongsok Kim 4) Seung-Hyun Yoo
kkim@b.cs.uiuc.edu yoo@star.stanford.edu
1107 W. Green St., Apt. 121 707 Cro Mem
Urbana, IL 61801-3044 Stanford, CA 94305
Tel) 217-384-0513 Tel) 415-327-6027
[
archived as
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>MACHANGUL-PART1.HQX
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>MACHANGUL-PART2.HQX
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>MACHANGUL-PART3.HQX
DoD
]
------------------------------
Date: 26 Feb 87 07:20:00 EST
From: "ERI::SMITH" <smith%eri.decnet%mghccc@harvard>
Subject: Conference on compatibility with "future" Macs
Reply-to: "ERI::SMITH" <smith%eri.decnet%mghccc@harvard>
This is an edited transcript of the Apple Compatibility CO
held Thursday, February 12, 1987.
Copyright (c) 1987 by Apple Computer, Inc. and MCU, Inc.
[
archived as
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>REPORT-APPLE-COMPATIBILITY-CO.TXT
DoD
]
------------------------------
Date: Sun 1 Mar 87 20:02:09-PST
From: Dwayne Virnau... <INFO-MAC-REQUEST@SUMEX-AIM.STANFORD.EDU>
Subject: Many, many, many comments about AppleShare
Since posting the original message from Dorothy Bender (MIKE?)
<HK.DEB@forsythe.stanford.edu> about AppleShare I have received quite
a few messages going through a point by point rebuttal. I posted one
reply by Larry Rosenstein because his was the first and I had no idea
I would receive so many others.
Most of these messages go over the same points Larry mentions, although
there are a few minor differences. So I have posted these messages into
the archives, and will add any future messages on this subject into the
same file.
Comments from
Dorothy Bender <HK.DEB@forsythe.stanford.edu> (MIKE?)
Larry Rosenstein (apple computer)
microsof!ericr@beaver.cs.washington.edu
ssp@Sun.COM (S Page [Tech Pubs {windows}] 354-4688)
ucscc!ucsck.carl@ucbvax.Berkeley.EDU (Carl C. Hewitt)
+ any others that I should receive are archived as
[SUMEX-AIM.Stanford.EDU]<INFO-MAC>REPORT-APPLESHARE.TXT
Dwayne Virnau...
Moderator
(ps, I received a few more such replies before I decided to archive them.
I you sent such a reply and wish it archived, please resend it.)
------------------------------
Date: Fri, 27 Feb 87 15:21:29 EST
From: Lap@UDEL.EDU
Subject: DVI to ImageWriter
Does anyone know if there exists a UNIX program which converts
DVI files from TeX to print on the ImageWriter dot matrix printer?
Please send replies to lap@huey.udel.edu.
Larry Pearlstein
------------------------------
Date: 25 Feb 87 20:11:00 EST
From: "ERI::SMITH" <smith%eri.decnet%mghccc@harvard.harvard.edu>
Subject: IBM PC <-> Macintosh Word conversions
Reply-to: "ERI::SMITH" <smith%eri.decnet%mghccc@harvard.harvard.edu>
Scott Johnson asks about converting files between the Macintosh and IBM PC
versions of Microsoft Word.
With the Macintosh version 1.05 of Word, Microsoft distributed a utility
called Word Convert. In every copy I've seen, this utility is documented
separately from the manual in a small leaflet about 1.05. In at least some
distributions, the contents of the "program" and "backup" disks are not
identical, Word Convert being contained on only one of them.
Word Convert works quite well on files transferred e.g. via Dayna's FT100,
and by other transfer methods we've used (PC to VAX to Mac via XMODEM).
According to Microsoft, the structural differences are minor but significant
and involve things like byte order in 4-byte integers.
One problem is that Word Convert does NOT do anything intelligent about
mapping fonts on the IBM side into anything resembling a "corresponding"
font on the Mac side. The mapping seems to be arbitrary and unpredictable.
The problem is made worse by the fact that many IBM users have monospacing
printers and no idea of what font they're using, or even that they're using
a font. And they often make things line up with spaces rather than tabs.
Generally speaking, plain vanilla monospaced fonts on the IBM tend to map
into Chicago (!) on the Macintosh, probably because they're both numbered 0
in some Microsoft numbering scheme.
The problem should become academic when (if?) Macintosh Word 3.0 is released.
Reportedly, Macintosh and IBM versions of Word will have different formats,
but will be able to read each others' formats directly, performing conversion
on the fly. Moreover, they will both be able to read and write Microsoft
RTF format, which is a representation of fully formatted Word documents that
requires only plain ASCII (and lots of \ characters!).
I think they will both be able to convert to and from IBM DCA format.
Reportedly Apple will offer a MacWrite-to-DCA conversion utility sometime
this year as well.
Daniel P. B. Smith ARPA: smith%eri.decnet@mghccc.harvard.edu
Eye Research Institute CompuServe: 74706,661
20 Staniford Street Telephone (voice): 617 742-3140
Boston, MA 02114
------------------------------
Date: Sat, 28 Feb 87 23:57:41 jst
From: nojima%ntt.junet@nttlab (Hisao NOJIMA)
Subject: Kanji Talk
> From: chi@eniac.seas.upenn.edu (Wei-Juang Chi)
> Subject: Chinese Macintosh Softwares
>
> (3) February 1987 MacWorld (p 13) - Apple computer's KanjiTalk, the
> operating system that converts any Mac Plus to a Japanese Mac, to allow
> printing on the LaserWriter. Anyone out there knows about this?
KanjiTalk is developed by Apple Japan and it is primarily intended
for Japanese Mac+, which has 128KB kanji ROM in it. I asked Apple
Japan and found that KanjiTalk works on plain Mac+, which does not
have Kanji ROMs. What you need to run KanjiTalk are two disks, one is
KanjiTalk system disk and the other is the font disk.
As KanjiTalk is one of the system software for Mac, you may freely
copy them. (According to Apple Japan.)
If you cannot get them from Apple, I will send them to INFO-MAC
archive by air mail, and you can get the copy. (Dear Moderator: Is it
necessary ?)
The trouble is that KanjiTalk is not yet stable software.
The most recent version is 1.1, which still have lots of bugs. And,
it does not support LaserWriter yet, which I am not sure, though. (I
use Ver.1.0, because on V.1.1, you cannot use Kanji on GUIDE. You can
use kanji on GUIDE on 1.0, however.)
H Nojima
nojima%NTT-20@SUMEX-AIM.stanford.edu
------------------------------
Date: Saturday, 28 Feb 1987 19:39:42-PST
From: shimono%tkov58.DEC@decwrl.DEC.COM (Takao Taxi Shimono)
Subject: Re: KanjiTalk (was Chinese Macintosh Softwares)
The following below is a recent Info-Japan mailing.
Maybe I can post KanjiTalk.hqx, but I don't think
you can use it without any documentation.
Incidentally, I seldom use KanjiTalk on my Mac.
-Taxi (Takao shimono%tkov58.DEC@decwrl.DEC.COM)
/DEC-Japan/SWS/AITC/studio.h
>From: RHEA::DECWRL::"nojima%ntt.junet@nttlab" "Hisao NOJIMA"
>To: su01%andrew.cmu.edu%SUMEX-AIM@NTT-20 ! Stuart Uleman
>Subj: RE: KanjiTalk, anyone?
>Date: Thu, 12 Feb 87 15:24:29 jst
>Cc: info-japan%MC.LCS.MIT.EDU%SUMEX-AIM@NTT-20
>Message-Id: <8702120624.AA14534@nttlab.ntt.junet>
>> Has anybody out there in Net-Land succeeded in getting the KanjiTalk
>> system?? I've talked to Apple Japan many times, but haven't been
>> able to convince them just to let me buy the software/firmware without
>> upgrading my Mac. My problem is that I have no earthly desire to
>> take my Mac all the way to Japan to get it installed and bring it
>> back. KanjiTalk simply isn't worth THAT much to me. But it would
>> be a great thing to have if I could get my hands on it....
>>
>> Advice/Comments, anyone?
>>
>> Stuart Uleman (su01@andrew.cmu.edu)
>
> I asked Cannon System Hanbai and Hi-Tecs, both of which are the major
>Mac distributers in Japan and found the followings.
>
> 1. You will need 20000yen to upgrade Mac+(English) to
> Mac+(Japanese). It is the cost to replace the ROM. The dealers
> have to return the original ROMS to Apple, you have to bring your
> Mac to your nearest authorized Mac dealers. (Tokyo may be the
> nearest to you.) So, there is no upgrade kit for users.
> 2. But, KanjiTalk works on English version of MacPlus. You simply
> need KanjiTalk system disk and Font Disk.
> 3. If you don't replace the ROM, the space for the kanji fonts are
> taken in the RAM area of Mac+ (120KB), but anyway, it works.
> 4. Then, how can you obtain the KanjiTalk software ? The easiest
> way is find somebody that already have a copy. You can make a
> copy from him/her.
> --- I called Apple Japan. They said that as it was a kind of
> the system software, there is no restriction on copying. You
> may copy them. No problem on the copyright. ---
>
> But, the problem is that KanjiTalk still has lot of bugs. They
>released version 1.1 recently, which was worse than V.1.0.
> And, somebody has to translate the poorly written manual.
>
> H Nojima
------------------------------
Date: Tue, 24 Feb 87 10:31:01 pst
From: kent (Christopher A. Kent)
Subject: Macintosh Compatibility Alert (forwarded from Joel West)
The MacInTouch article noted compatibility problems with a number
of pieces of software. Now Apple has sent out a packet to certified
developers, all but announcing a new machine "soon" and a 68020-based
product under development:
Macintosh Compatibility Alert -- February 1987
Stop! Do not throw this away.
Contains important compatibility information. (OK)
This is a special compatiblity mailing to all Macintosh Certified
Developers. We're not trying to limit its distribution, so copy
any and all of this information and distribute it freely (and for free).
You've seen some of these technical ntoes before, but we've included
them for emphasis.
THE FUTURE IS CLOSER THAN YOU THINK
Apple Engineering has been working on variations on the Macintosh
theme. They've gone to great lengths to make sure that existing software
will continue to work when the changes hit the streets, but they can only
go so far.
Now it's your turn. We've put together this mailing to give you an idea
of what things may cause you trouble in the near future. The compatibility
issues you've been putting off until later need to be looked at NOW.
We're not just telling you it's a good idea to stay in the crosswalks,
we're telling you there's a truck on its way and it's headed straight
for you (and your applications).
This mailing includes the following:
Technical Note #2A--Compatibility Checklist (2/9/87)
Development System Compatibility Note
Technical Note #117--Compatibility: Why and How (DRAFT, 2/9/87)
Technical Note #7--A Few Quick Debugging Tips (4/16/86)
Technical Note #83--System Heap Size Warning (6/21/86)
Technical Note #100--Compatibility with Large-Screen Displays (11/15/86)
Technical Note #2--Macintosh Compatiblity Guidelines (2/9/87)
[ 2A is a summary of 117. I'll present 2A with paraphrase of 117 as
background, and my own comments in [] -jww]
<117: Bad Things
"These are the current top ten commandments:
I. Thou shalt not assume the screen is a fixed size.
II. Thou shalt not assume the screen is at a fixed location
III. Thou shalt not assume that rowBytes is equal to the width of the screen.
IV. Thou shalt not use nil handles or nil pointers.
V. Thou shalt not create or use fake handles.
VI. Thou shalt not write code that modifies itself.
VII. Thou shalt think twice about code designed strictly for copy protection.
VIII.Thou shalt check errors returned as function results.
IX. Thou shalt not access hardware directly.
X. Thou shalt not use any of the bits that are reserved (unused means
reserved.) "
#2A: Macintosh Compatiblity Checklist
... If you do not follow the guidelines in this note, your software is
virtually guaranteed to fail on future Macintosh computers.
* Do not hard-code for a screen size of 512 by 342 pixels. Get the
size and memory location fo the screen from the QuickDraw global
screenBits.
* If you're creating an offscreen bitmap, do not assume that the entire
screen image is smaler than 32K bytes (that is, don't assume a short
integer)
<117: use screenBits.bounds for the size, screenBits.baseAddr for the
location. Use mBarHeight on 128k ROM and later for menu bar height,
instead of a constant 20.
Do not assume that the screen bitmap is rowbytes wide.
"With an Ultra-Large screen, the number of bytes used for screen memory
may be in the 500,000 byte range...a 16 bit Integer will not be able
to hold the 500,000 number, so a LongInt would be required."
>
[ 500,000 bytes ~~ 1,024 x 1,024 x 4 bit planes. The universities
have said they want Megapixel machines, so presumably Apple will get
there before Steve Jobs' non-competition agreement runs out this summer,
although Jobs is said to be behind schedule. ]
* Do not hard-code the addresses of the SCC, VIA, or IWM chips. Get the
addresses of these chips from the low-memory variables SCCRd, SCCWr,
VIA, and IWM.
<117: you can use the hardware directly, but use the indirect address >
* Avoid using the TRAP instruction, since exception frame formats vary
on different members of the 68000 microprocessor family. Also, avoid
using the RTE instruction except as a true return from exception.
<117: Don't write self-modifying code, such as copy-protection code.
"There are third-party upgrades available that add a 68020 to a Macintosh.
Because of the 68020's cahce, programs that modify themselves stand a good
chance of having problems when run on a 68020. This is a compatiblity
problem that should not be missed. (nudge, nudge, wink, wink.)" >
[ The TRAP is why MacWrite crashes on the Levco Prodigy or any 68020 or
later. Using RTE for a subroutine return is lazy or foolish or both;
it fails on a 68010 or later. RTD is much better and safer, but
requires >= 68010.]
* When your application opens a file ... do not repeatedly open and
close the file. Instead, leave the file open until the
user [closes the window]. This will prevent unwanted shared
access if the document resides on a shared volume, such as
a file server.
* If you application creates temporary files, be sure that the filenames
are unique...
* Do not assume there is a maximum of 1 megabyte of RAM, or that the
only valid RAM sizes are 512k and 1M, or even that 512k is available
(you may be running under Switcher.)
* Do not directly manipulate a master pointer's flag bits...
[ I.e., we plan to make addresses in the master pointer 32 bits, not
24 bits as at present ]
<117: Don't use bits that are reserved... only the top bit of ROM85
($28E) refers to the 128K ROM. "This means the rest of the bits in that
word are reserved, since nothing is described about any further bits...
An example of a bad way to do the comparison is:
...
IF Rom85Ptr^ = $7FFF THEN RomsAre 128 := True { Bad test. }
ELSE RomasAre128 := False;
">
[ from MacInTouch 'Mac II First Look': "Cricket Draw gives a message
saying it's only compatbile with 128K ROMs and quits to the Finder."]
* Do not assume the system [sic] application heaps start at a fixed
address...use SysZone and ApplZone.
<117:"It is still your choice whether you will be concerned with
compatiblity or not. Apple will not put out a warrant for your
arrest. However, if you are doing things that are specifically
illegal, Apple will also not worry about "breaking" your program.">
Joel West MCI Mail: 282-8879
Western Software Technology, POB 2733, Vista, CA 92083
{cbosgd, ihnp4, pyramid, sdcsvax, ucla-cs} !gould9!joel
joel%gould9.uucp@NOSC.ARPA
------------------------------
Date: Sun, 1 Mar 87 10:46 EDT
From: Jeffrey Shulman <SHULMAN%slb-test.csnet@RELAY.CS.NET>
Subject: Usenet Mac Digest V3 #16
Usenet Mac Digest Saturday, February 28, 1987 Volume 3 : Issue 16
Today's Topics:
Administrativia: Digest distribution changes
Startup problems
Bug in "IsDialogEvent" ?
IBM TEXT FIlE to MAC+
Harrier Strike Force Upgrades
INITs in LSC?
Sector Read Source?
Re: Developing Software For Visually Impaired
Re: Public Domain Software For/By The Handicapped
Another area: software for mentally retarded
Re: Database for MAC+
C compiler & linker that will generate ROMable code
Re: MPW Debugger
Re: Coral Object Logo
Re: Database for MAC+
Re: Desktop drawing
Can Mac's and PC's get along?
Damaged Mac disk recovery
[
archived as [SUMEX-AIM.Stanford.EDU]<INFO-MAC>USENETV3-16.ARC
DoD
]
------------------------------
Date: Sun, 1 Mar 87 11:07 EDT
From: Jeffrey Shulman <SHULMAN%slb-test.csnet@RELAY.CS.NET>
Subject: Usenet Mac Digest V3 #17
Usenet Mac Digest Saturday, February 28, 1987 Volume 3 : Issue 17
Today's Topics:
Mac magnification
Help wanted: appendPicture routine needed.
TimeManager interface, TML Pascal for example ?
Re: IBM TEXT FIlE to MAC+
HD20SCSI problems
Help with NEC Spinwriter needed.
Re: Coral Object Logo
Termcap or curses calls in MegaMax C
Vertical Retrace Tasks
List of available tools for visually impaired on Mac
Re: Mac Excell and Filemaker Plus !
Generic Printer Driver Needed
Re: Vertical Retrace Tasks
Remote Mac Access
Macterminal with NON-Apple modem
WMgrPort/Desktop Drawing
Re: Coral Object Logo
Re: Delphi Mac Digest V3 #12 Discussion of GAUSS replacement/APL
Color Transparencies
[
archived as [SUMEX-AIM.Stanford.EDU]<INFO-MAC>USENETV3-17.ARC
DoD
]
------------------------------
End of INFO-MAC Digest
**********************