INFO-MAC-REQUEST@SUMEX-AIM.ARPA (Moderator David Gelphman...) (08/25/86)
INFO-MAC Digest Sunday, 24 Aug 1986 Volume 4 : Issue 104
Today's Topics:
Survey: Transition from Lisa to Mac [ from net.micro.mac ]
Hard disk issues
Re: C+-
Need help creating fonts
Interlace and Dbase Mac
Micahdrive Whine
MacIntosh + schematics?
Dataframe screwholes
----------------------------------------------------------------------
Date: Sat, 23 Aug 86 19:08:15 cdt
From: werner@ngp.UTEXAS.EDU (Werner Uhrig)
Subject: Survey: Transition from Lisa to Mac [ from net.micro.mac ]
[ note from moderator: this was sent from Werner Uhrig but originally
appeared on usenet. Since it didn't make it into the usenet digest but
is of interest to much of the Mac programming community, I am posting
it in its entirity. DAVEG ]
From mugc@utecfa.UUCP (ModemUserGroupChairman) Thu Aug 21 13:55:22 1986
Subject: Survey: Transition from Lisa to Mac... (LONG)
I was not planning on posting the results of my survey
because I didn't think too many people would be interested. Well, I
was wrong :-) So here it is:
The original question that I posted:
We (where I work) do some software development for the
Macintosh. As such, we are registered Apple developers and we
develop software using 2 lisa's and the Lisa Workshop development
environment. As many of you know, Apple is offering a chance to
trade-in a Lisa for a Macintosh-Plus with 20M hard disk (after
paying $2400 Cdn). We are reasonably satisfied with the dev. system
on the Lisa, but nevertheless are considering the trade-in offer.
I know that many people out there develop software on the
Macintosh using 3rd party compilers. In order to decide whether or
not we should make the transition, and in order to make the
transition as painless as possible, should we so decide, I would
appreciate it if those out there would answer some of my questions.
1. The Lisa Workshop, as I understand, runs the 68000 in user
mode. This makes error recovery in case of crashes safer than on
the Mac. This is important for a dev. system because crashes waste
a lot of time in rebooting. And also, after an hour of editing, you
don't want an Id 28 bomb (stack and heap collision)! Do any dev.
systems on the Mac do this, or in some (other) way make recovery
possible.
2. How good are the C compilers out there? I am interested in:
a. full toolbox support.
b. full Kernighan and Ritchie C
c. Reasonably fast compiles
d. Good code (tight and fast).
e. Compatiblity with Workshop Linker and RMaker if possible.
3. How good are the dev. systems. Ie., are the following present:
a. Nice command line or menu-driven environment.
b. Lots of good dev. tools, such as diff, grep, make etc.
c. Provision for running the resulting program from within
the system in such a way so that program crash does not crash
the dev. system
4. How good are the Pascal compilers on the Mac? I'm looking for:
a. Pascal compilers which will compiler ANY (within reason)
program which compiles on the Workshop
b. Pascal compilers which link with toolbox linker (if I need to).
c. ,, ,, ,, output fairly tight code.
5. Finally, if anyone has made the transition from Lisa to Mac/+,
would you like to share your experience?
Thanks for going through this rather long posting. I imagine
there are others interested in this as well, if I get enough
replies, I'll condense them and repost to the net. Also, if
we do make the transition, I'll post our experiences.
Appreciatively,
Anees Munshi.
Advanced Systems Technologies,
Honeywell Information Systems Ltd,
515 Consumers Road, North York, Ontario M2J 4Z2.
(416) 492-0770
The only net address I know:
@ University of Toronto Engineering Comp. Facility :A
{allegra,ihnp4,linus,decvax}!utzoo!utcsri!utecfa!mugc
{ihnp4|decvax|utzoo|utcsri}!utecfa!utecfb!munshi
-----------------------------------------------------------------
Answer #1: MAC-C from Consulair Corporation.
1: MAC-C (version 4.52) runs in the supervisor mode.
> 2. How good are the C compilers out there?
> I am interested in:
> a. full toolbox support.
> b. full Kernighan and Ritchie C
> c. Reasonably fast compiles
> d. Good code (tight and fast).
> e. Compatiblity with Workshop Linker and RMaker if possible.
(willc@tekchips (William Clinger) and kff@kesmai (Kelton Flinn)
write:)
2:
a. Mac C has full toolbox support, all the ROM calls WITHOUT glue
routines. It understands HFS.
b. I don't think Mac C is full Kernighan and Ritchie, but I don't
know K&R well enough to point out any differences. The biggest
problem for Semantic has been the substitution of a nonstandard
CatchSignal/Signal for setjmp/longjmp. I don't think
setjmp/longjmp is in K&R, however.
c. Mac C has three passes, including assembly. It's no
speed-burner but it's bearable unless you're using floppies.
d. I can't say that the generated code is particularly tight or
fast, but ... the code isn't much worse than code generated by
the Berkeley Unix compiler and is probably better in some ways.
[some stuff deleted at request] ... The compiler does generate
absurdly large stack frames. I think this is related to the
80-bit floating point, and may be fixed in more recent
versions.
e. I believe Consulair wrote the Workshop Linker, but the new Mac
C linker is better. I'm pretty sure they maintained backward
compatibility. We use Mac C with RMaker.
>3. How good are the dev. systems. Ie., are the following present:
>
> a. Nice command line or menu-driven environment.
> b. Lots of good dev. tools, such as diff, grep, make etc.
> c. Provision for running the resulting program from within
> the system in such a way so that program crash does not
> crash the dev. system
(willc@tekchips and kff@kesmai reply:)
a. Mac C is menu-driven.
b. Mac C has none of the three except for an exec facility, which
will compile and link your entire application but I don't think
it will do it selectively like make. (I haven't used exec.).
However, for an additional $100, you can buy diff, grep, a
profiler, and "SuperMake". I [kff@kesmai]have done a fair
amount of hand-optimization of critical routines in assembler.
The profiler utility came in very handy there, it by itself
was worth the extra $100.
c. Macsbug will trap most errors. Perfect protection is
impossible on the Macintosh unless all pointer and array
references are checked at run time, et cetera.
-------------------------------------------------------------------
I myself have acquired and used the Beta version of MPW
(Macintosh Programmers' Workshop) on a Lisa running MacWorks. We
have used the Pascal compiler and the tools provided with it a fair
amount, so I am in a position to make comments on it. I have NOT
seen the MAC-C system (previous review), so can't say how MPW
compares with the MAC-C development environment. I have also not
been able to get the C compiler on our copy of MPW to work, but
then I have not had a real use for using it yet (our application is
all pascal code) and so have not looked into getting a fix.
1: MPW is also a supervisor mode system. Crashes are fatal unless
your program uses a restart procedure (ours doesn't). I have not
tried running the debugger, so I can't really say anything about
that either.
2: I have not really used the C compiler (since it doesn't work
:-), but I have read the documentation and it looks good :->
3: Here the MPW really wins.
a. There is a nice command line interface. The command interpreter
has a syntax very much like the Unix shells, however deliberate and
studied care was taken to make it look as different as Unix as
possible, at least on the cosmetic level: For instance, instead of
the back-slash escape character, the greek lower-case delta is used;
instead of the "*" wildcard character, the <approximately-equals>
symbol was used!
b. All the standard tools such as cat, ls, cmp, diff, grep, make
etc have been provided. Here again though, all the names have been
deliberately changed so if you are used to using Unix you might
like to set up aliases in the start-up file to map all the MPW
names to the more familiar Unix names. I haven't used their make,
but I believe the syntax might be a little different.
c. There is a provision for running programs from within MPW.
Running programs like Macwrite and Macpaint is fairly safe, but
debugging from within MPW may not be the healthiest thing on earth.
Having 2 Macs is definitely useful.
General remarks:
The MPW shell is really quite powerful. The system also comes
along with a number of utilities and these utilities work. For many
of the shell-commands, there are menu equivalents, often with
function-key equivalents so there are often a number of ways of
doing a single thing. The shell is merged with an editor so cutting
and pasting is also possible within the worksheet (commands
window). This allows you to easily edit commands to correct typos
etc. The editor is somewhat like the Lisa development system
systems editor except that it does not have markers -- real let
down. Otherwise it is fairly complete and more polished than most
of the editors I have seen on the Mac.
4: The MPW pascal compiler is very compatible with the Lisa Pascal
workshop.
a. The compiler will compile ANY program written on the Lisa as
long as the program on the LISA does not push the limits of the Mac
such as in global data size, procedure size and segment size.
b. The MPW linker is quite different from the Lisa Pascal linker.
However, object files can be converted to the Mac format from the
Lisa format.
c. The code produced does not seem to be as tight as the Lisa's
code, but the difference was not more than about 15% or so.
5: Finally, if there are any further questions on the MPW
environment that you would like to ask me, just go ahead and mail!
Regards,
Anees Munshi.
Advanced Systems Technologies,
Honeywell Information Systems Ltd,
515 Consumers Road, North York, Ontario M2J 4Z2.
(416) 492-0770
The only net address I know:
@ University of Toronto Engineering Comp. Facility :A
{allegra,ihnp4,linus,decvax}!utzoo!utcsri!utecfa!mugc
{allegra,ihnp4,linus,decvax}!utzoo!utcsri!utecfb!munshi
------------------------------
Date: Sat, 23 Aug 86 15:28 PDT
From: PUGH%CCV.MFENET@LLL-MFE.ARPA
Subject: Hard disk issues
I have been trying to write a program to examine my hard disk and determine
where all the space has gone (can you tell that I have filled it up?) and
have been running into problems. Let me elaborate.
I have been cruising the HFS tree structure as per TN #68 and getting info on
all the files in all the directories. This gives me a number that should be
the total disk space used for all the files on the disk. Actually I get two
numbers, logical and physical lengths. I am using physical lengths, which are
really the sum of the physical lengths of the data and resource forks. This
sum comes out to be significantly less than the number given by doing a Get
Info on the disk icon in the Finder. By less I mean about 1.8 Meg less. A
comparison of the file counts reveals that my program is counting all the files,
while the Get Info is reporting that there is one less file. Sounds weird.
I cross referenced the file count from the volume header info and I am correct
and the Finder is off by one. Question 1) What gives? Is the Finder WRONG???
Well, I realize that there is more info on the disk than just the files, so I
got Volume IV of Inside Mac and perused it for some hours and started checking
out the B*-tree situation. I also found that Fedit+ will show the extent of
the B*-trees (both the Extents and Catalog trees). These are actually quite
small, about half a Meg. Well, some more snooping turned up a number that is
exactly what the Get Info returned for the entire disk. It seems that this
formula is what you get when you do a Get Info on your hard disk icon (you can
get the numbers from Fedit+): Used = Available - Free - Btrees. Question 2)
What the heck good is that? This formula comes out to the byte, a little too
close for chance. Is this really the way it is done and if so, why?
OK, so I went and did a Get Info on all the folders in my hard disk and added
them up, just to be masocistic. The sum came out very close to my file space
sum (off by 153 blocks or 78,336 bytes) with the directory sum being smaller
than the physical sum, but larger than the logical sum. This brings us to
Question 3) Where does the Get Info come from? Is it different for files,
folders, and disks?
So anyhow, my next step is to examine the allocation bit map and try to
determine which blocks are in which directories so that I can weight the whole
thing properly, although I am probably working too hard at it. Since my goal
is to show the heaviest directories I can probably ignore the system overhead,
but it is annoying the hell out of me that I cannot account for all the disk
space.
Question summary: How does the Finder deal with Get Info requests? Are there
different algorithms for different entities (there should be, the info returned
is in different forms) and if so, what algorithms is it using for each type?
I guess this is all directed at Larry Rosenstein of Apple since I suspect he
is the only person willing to respond who has access to this information.
All in all I am now terribly confused and I think I will go home and have a
beer so that my brain will allow this confusion to leak out before the night
really begins.
Jon.
------------------------------
Date: Fri, 22 Aug 86 11:15:03 pdt
From: Larry Rosenstein <lsr%apple.csnet@CSNET-RELAY.ARPA>
Subject: Re: C+-
>>>From: PEABO (625)
>>Subject: RE: Aztec C future (Re: Msg 623)
>>Date: 18-AUG 04:04 Tools for Developers
>>
>>I've heard of C++, but what's C+-?
>>
C+- is a subset of C++ that Apple has defined (with advice from various
people). It is intended to be an extension of ANSI C that adds just the
object-oriented features of C++, so that this language could be used for
MacApp development in C. It also gives language developers an intermediate
stage between ANSI C and full C++. The syntax of C+- follows closely that
of C++.
Larry Rosenstein
Object Specialist
Apple Computer
AppleLink: Rosenstein1
UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.CSNET
------------------------------
Date: Fri, 22 Aug 86 17:20:40 pdt
From: fluke!inc@uw-beaver.arpa (Gary Benson)
Subject: Need help creating fonts
I need to create special type fonts on a Mac. I know I can go into MacPaint
and do all the doodling around I want, but what I'd REALLY like to do is
create the font and get it to display and printout via menu selection like
a normal one. Is there a way? Any help is appreciated. Forgive me if this is
an insanely naive posting: I'm trying to catch up!
Thanks for any assistance.
Gary Benson * John Fluke Mfg. Co. * PO Box C9090 * Everett WA * 98206
MS/232-E = = {allegra} {uw-beaver} !fluke!inc = = (206)356-5367
[ note from moderator: Fontastic by Altsys is at least one program especially
designed to ease the pain of making bitmap fonts for the Macintosh. DAVEG ]
------------------------------
Subject: Interlace and Dbase Mac
Date: Sat, 23 Aug 86 10:25:22 -0800
From: Kathleen Huddleston <gregory@ICSE.UCI.EDU>
Was anyone else shocked by the picture on the front page of this week's
InfoWorld? It showed a screen from the newly announced Dbase Mac from
Ashton Tate and it looked almost exactly like Interlace (soon to be
known as Reflex). We've all seen the pictures of the Interlace Overview
Window. DMac calls it the database 'structure' rather than overview,
but it looks exactly the same and reportedly, you create links in the
same manner--by drawing lines between linked fields.
I use Interlace, and like it very much. I don't know if there are any
law suits pending, but I suspect the Interlace developers never worried
about someone copying this unique way of representing and creating
relational links and so didn't get that type of protection. I think its
too bad.
On the other hand, it's great when good ideas get picked up and more
widely distributed and if we were always fighting legal battles, we could
never have the kind of software consistency that makes the Mac as good as
it is.
However, I do think the InfoWorld writer might have mentioned this similarity
in the article. Of course, the Ashton Tate product will sell for almost five
times as much as Interlace.
By the way, I hear there are really good enhancements to Interlace under
development at Borland and I hope they give Dbase Mac a real run for its
money.
------------------------------
Date: Sat, 23 Aug 86 13:46 PDT
From: PUGH%CCV.MFENET@LLL-MFE.ARPA
Subject: Micahdrive Whine
My Micahdrive has developed an annoying whine in the fan. It is somewhat
sporadic, but still enough to drive me completely insane within a matter of
hours. Is anyone else having troubles like this? I would like some stats
before going and complaining to the Micah people.
Jon
------------------------------
Date: Fri 22 Aug 86 20:59:29-PDT
From: Philip M. Pitner <PITNER@Sierra.Stanford.EDU>
Subject: MacIntosh + schematics?
Does anyone know where I can obtain a set of schematics for the MacPlus. I'm
specifically interested in the Memory bus motherboard pinout.
Thanks,
Phil
------------------------------
Subject: Dataframe screwholes
Date: Sun, 24 Aug 86 14:20:27 -0800
From: Kathleen Huddleston <gregory@ICSE.UCI.EDU>
The holes in the bottom of the dataframe can be used to attach a plate to
bolt the dataframe down to prevent it from tipping over which might
result in dire consequences.
I've been using a dataframe for about two weeks with no major problems. I
did have to replace the System Folder once when it crashed and failed to
reboot, but it worked OK. I still don't know why hard disks occasionally
seem to trash files (system or otherwise).
------------------------------
End of INFO-MAC Digest
**********************