[mod.mac] Delphi Mac Digest V3 #11

SHULMAN@RED.RUTGERS.EDU.UUCP (02/15/87)

Delphi Mac Digest        Sunday, 15 February 1987      Volume 3 : Issue 11

Today's Topics:
     RE: draw-grab
     RE: LaserSpeed -> WOW (4 messages)
     Mac carrying cases
     System 3.3 and MacXL
     Lightspeed C and Macsbug symbols
     MPW C Doc and MPW Tools (4 messages)
     Re: Fortran Problem (2 messages)
     New HELP Resource type. (3 messages)
     Looking for Music Tutor
     Serious ROM 'feature' causes problems wi
     TMON with FPD (2 messages)
     Mac Zap v4.5
     cricket draw
     Investigations into Memory Usage (3 messages)

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

From: JDSCHNITZER
Subject: RE: draw-grab (Re: Msg 17168)
Date: 8-FEB-10:30: Mousing Around

If it's a "library" of MacDraw files that you extract from, then definately try
PictureBase.  It's cheap and provides a DA PictureBase Retriever in addtion to
the application.

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

From: BWD
Subject: RE: LaserSpeed -> WOW (Re: Msg 17138)
Date: 8-FEB-20:18: Business Mac

I have been using it too and am also quite impressed.  Unfortunately I use some
fonts that were created with Fontographer which under normal circumstances are
downloaded to the LaserWriter automatically.  Using LaserSpeed no downloading
occurs and the letters are displayed in one of the Laser Fonts, Helvetica I
think.  If that problem was fixed, I would use it all the time.

Brian

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

From: STEVEMALLER
Subject: RE: LaserSpeed -> WOW (Re: Msg 17182)
Date: 10-FEB 18:03 Business Mac

The documentation clearly states that you should use a "downloader" program to
set up the LaserWriter first...

Steve

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

From: MADMACS
Subject: RE: LaserSpeed -> WOW (Re: Msg 17253)
Date: 14-FEB 22:00 Business Mac

Do you know if LaserSpeed works with PageMaker?  (This is really for Steve
Maller, I guess, since he started this thread, I believe). The beta 0.97??
version of SuperLaserSpool does _not_ fully.  That is, it will print a PM file,
but it uses the regular laserwriter driver and does not load Aldus Prep.  The
result is not acceptable.

TO ALL: I am trying to advise a local small business as to the best
spooler that they can buy that will work with (1) LaserWriter and a
Linotronic (which uses the LW driver so should be ok) (2) Downloaded
fonts (3) PageMaker, Word, Draw, Write, (especially PM) and is robust
enough not to cause delays re-booting and recovering lost files.

Any ideas?  I would really appreciate your input. -Doug

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

From: MACINTOUCH
Subject: RE: LaserSpeed -> WOW (Re: Msg 17308)
Date: 14-FEB 22:03 Business Mac

Doug,
   I'll jump in here, because I've been using LaserSpeed extensively.  It
works fine with PageMaker and all the other applications I've tried, although
I haven't used downloaded fonts.  It has been remarkably free from the
bugs and annoyances we'd seen with previous laser spoolers.

Ric Ford

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

From: HALL
Subject: Mac carrying cases
Date: 9-FEB-23:11: Hardware & Peripherals

What's the best Mac carrying case around (Mac+, that is), how much
does it cost, and where's the best place to get it?  Is MacTotes still
one of the better ones?  Thanks, Brian

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

From: JSTIFF
Subject: System 3.3 and MacXL
Date: 10-FEB 01:41 Bugs & Features

Well, Apple has finally done it to us die-hard MacXL (old Lisa) owners.
 The new System (Version 3.3 which is being distributed as part of the
AppleShare file server software) will not work with the MacXL.  This is even
confirmed in the AppleShare manual!  Does anyone have any insight into why the
new system file cannot work with the MacXL or as to why Apple made this rather
significant policy decision?

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

From: RCONGDON
Subject: Lightspeed C and Macsbug symbols
Date: 8-FEB-22:05: Programming Techniques

I haven't seen this mentioned anywhere but it may be old news. If you
have the "Macsbug Symbols" option checked for a project you only get
symbols for functions that declare local variables. I understand that
Macsbug symbols assume LINK/UNLK pairs and of course if the stack
isn't used there's no need for the LINK/UNLK but it would be nice if
they put the LINK/UNLK and the symbol in anyway (at least as an
option).

I know this is a minor quibble but it had me mystified for a bit...

--bob "hoping for a REAL Lightspeed C debugger" congdon

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

From: JEFFS
Subject: MPW C Doc and MPW Tools
Date: 10-FEB 07:29 Macintosh Developers

How come the MPW C manual doesn't describe the ToolLibs.o library and
how to interface with it?  How would I know what to do to write a tool
in C? While looking through the MPW Pascal manual at work I found that
*it* had a chapter on it.  Are tools not supposed to be written in C?
Does Apple/APDA *assume* that you will buy Pascal if you want to write
a tool?  Mind you, I have no intentions at this time to write a tool,
I'm just upset that I can't if I wanted to using the documentation for
MPW C I have at home.

                                               Jeff

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

From: BRECHER
Subject: RE: MPW C Doc and MPW Tools (Re: Msg 1257)
Date: 10-FEB 10:04 Macintosh Developers

Don't panic.  All the info (except maybe the cursor control stuff,
which is going to change anyway) is there: in the Shell manual, and in
the Standard Library chapter of the C manual.  The C names don't have
an "IE" prefix.  Some of the stuff -- e.g., the argv/argc facility --
doesn't require special routines in C.

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

From: LOGICHACK
Subject: RE: MPW C Doc and MPW Tools (Re: Msg 1258)
Date: 13-FEB 01:53 Macintosh Developers

What do you mean the cursor control stuff is going to change?

Paul :)

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

From: BRECHER
Subject: RE: MPW C Doc and MPW Tools (Re: Msg 1260)
Date: 13-FEB 07:49 Macintosh Developers

I mean it will be generalized to use resources, so you can design your own
animated cursors.

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

From: Maloy
Subject: Re: Fortran Problem
Date: 11-FEB 11:15 Network Digests

Re: A. REMY MALAN's FORTRAN problem

  The problem is not with the MS FORTRAN compiler, but with your code. You have
a very subtle type mismatch error.  If you select option "L" in MS FORTRAN 2.2
the next time you compile and examine the .LST file created, you'll note that
FOOB is REAL*4 in the main program.  You did not give a type to FOOB in module
TEST, so REAL*4 is default.  Unfortunately, FOOB is a REAL*8 function, as you
know.
  The solution is to add the line "REAL*8 FOOB" in the main program
(or modify the existing line to read "REAL*8 SUM,FOOB".  As far as
other compilers are concerned, they are probably acting the same way;
it's just that converting from REAL*4 to REAL8* on some computers is
simply a matter of adding some low order zeroes to make a total of 8
bytes.  On the Mac, however, floating point arithmetic is performed
using the proposed IEEE standard-- REAL*8 exponent fields are quite
different than REAL*4 (see Appendix F in the MS FORTRAN manual) so
that converting to double precision requires more than just "tacking
on some zeroes."  If the number you're converting isn't "really"
REAL*4 you get some strange answers.
   For instance, when I realized the type mismatch, I uploaded your
source file to a VAX computer and compiled with the /LIST option.
FOOB was REAL*4 in the main program and REAL*8 in the FUNCTION, as
expected.  However, the program "appears" to be working correctly, as
SUM = 25.0000 is printed. The type mismatch is still there, though, so
I recompiled with a /G_FLOAT option on the VAX in hopes of causing the
error. (G_FLOATing point is similar to REAL*8 on the Mac in that the
exponent field is a different size than REAL*4.)  As expected, the
program printed a value other than 25.00: "SUM = 0.8476562500".
     I recommend explicitly typing every FUNCTION and VARIABLE in FORTRAN
programs so that errors such as these won't occur.
         Bill Maloy 601-688-5572

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

From: SPERRAZZA
Subject: RE: Re: Fortran Problem (Re: Msg 17287)
Date: 14-FEB 20:52 Network Digests

MS-FORTRAN 3.31 (just recently superseded by 4.0) for MS-DOS machines
did not support IMPLICIT NONE. Of course, it was in many other ways a
lousy compiler, so this is not surprising. Io not know if 4.0 supports
IMPLICIT NONE, as I have not yet upgraded. I agree that using it often
means the saving of days of work during the testing phase.

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

From: PALAIS
Subject: New HELP Resource type.
Date: 12-FEB 11:43 Programming

I have a suggestion for a new standard Resource Type, to be called
HELP. Each resource of type HELP would be a single str255. Any number
of HELP resources could be added to an application (or to the Resource
Fork of a document). Each HELP resource would give help on using some
feature of the appl ication, and would have a mnemonic name referring
to that feature.  An applicati on with HELP resources would put up a
HELP menu on the menu bar using AddResMenu , so all the available HELP
item names would appear as items on this menu. When a user chooses an
item from this menu, a new HELP Manager would put up a dialog box
displaying the associated HELP string. I see at least two advantages :
   % There would be a uniform user interface to on-line documentation.
   %  It would become a piece of cake for developers to add basic documentation
       to new applications (using say REdit or ResEdit), SO THEY WOULD BE
        MORE LIKELY TO DO IT. The present method of attaching
documentation to About...  screens is very un Mac-like in my
opinion...everyone does it differently, you donUt even know if its
there if, like many users you donUt bother to pull down the Apple m
enu, and it takes one more special effort on the part of a developer.

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

From: DONBYRD
Subject: RE: New HELP Resource type. (Re: Msg 17262)
Date: 13-FEB 06:58 Programming

Interesting idea, and the should be a uniform way to invoke help.
Regarding your particulars, I don't think an STR255 gives enough
flexibility. I think Microsoft WORD already uses HELP resources for
its Help facility, though I have no idea how.  A friend of mine is
developing an application that uses a scheme a lot like what you
suggest, but he has way more than 255 characters per item, so he uses
some other simple text representation, not STR255, and he has some
typographic control in it as well.

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

From: PEABO
Subject: RE: New HELP Resource type. (Re: Msg 17262)
Date: 12-FEB 12:35 Programming

It's a good idea except that one Str255 probably isn't enough.  Something I've
been thinking of doing is to define a STR# resource to match each dialog I have
in my program, and correlate the strings in the STR# with the item numbers in
the dialog.  I haven't pursued it too far though; it's just a thought about ho
to do context sensitive help.

peter

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

From: MACINTOUCH
Subject: Looking for Music Tutor (Re: Msg 17254)
Date: 12-FEB 22:55 Network Digests

To: Wahl.ES@Xerox.COM
Subject: Looking for Music Tutor

Listen, from Imaga (PO Box 638, Middletown, CT  06457; 203-347-5909)
is an excellent ear training program.  It lists for $69, and unfortunately,
is copy perverted.

Ric Ford, "MacInTouch" newsletter

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

From: PEABO
Subject: Serious ROM 'feature' causes problems wi (Re: Msg 17270)
Date: 12-FEB 23:08 Network Digests

>Date: Tue, 10 Feb 87 18:07:41 PST
>From: <DAVEG@slacvm.bitnet>
>Reply-to: DAVEG%SLACVM.BITNET@forsythe.stanford.edu
>Subject: Serious ROM 'feature' causes problems with multiple stacks
   ...
>   OK, so what I find is that at least one place in the ROM takes the
>current value of the stack pointer, subtracts the value at HEAPEND (to
>'determine' the amount of 'free' space remaining on the stack) and if it
>is large enough, uses that space for something!!!!! In the above multiple
>stack scenario one finds that if you are using (for example) the stack
>which is the highest in memory, this ROM routine will calculate lots of
>'free' space between SP and HeapEnd and use it! This clobbers my other
>stacks quite nicely.
   ...
>    I know this is longwinded and hopefully not too confusing to those
>who are familar with programming the Mac.  Basically I am hoping (A) to
>get some hints about how others have implemented multiple stacks and (B)
>ideas for workarounds and (C) does anyone else think that calculating
>free stack space this way is goofy or is it just me?

This strategy is good programming style, if you ask me.  (1) you told the
ROM it was OK to use the space (because the area between heapend and current
SP is the available stack space), (2) it is a way to program an algorithm
which probably functions when tight on storage, but which functions faster
when it can save more information about what it's doing (lots of graphics
algorithms are like that), and (3) it uses space in a way that doesn't cause
long term problems by purging stuff from the heap, which would be the other
place it could get temporary storage.

I think what you are going to have to do is to diddle the heap when you
switch stacks.  If you are reasonably lucky, this will only require changing
a few words here and there.  Allocate your extra stacks in the original heap
and do MoveHHi on each one and lock it.  Now you have the stacks allocated
in the correct place in memory and all you have to do is adjust the heap
zone so that heapend always points to the bottom of the active stack and the
heap is always self-consistent, including whichever locked blocks happen to
be below the stack.  The ones above the stack are protected by virtue of
looking like legitimate stack allocations.

Your biggest difficulty may be in proving that whatever you have to diddle
is fully described by a published interface.  I suspect that it is.  As a
byproduct of this, you can arrange the sniffer to give you a bomb if it
discovers one of your stacks has grown into the one below it.

peter                          "In any context, half of all references
PEABO @ DELPHI                  are local and half are global."

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

From: DDUNHAM
Subject: TMON with FPD
Date: 12-FEB 21:25 Tools for Developers

Yay!  I finally got the "experimental version" of  "TMON - Universal," which
runs on a Radius FPD (and presumably other size screens, as well as 68020s).
Contact ICOM Simulations if you need this.

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

From: LOGICHACK
Subject: RE: TMON with FPD (Re: Msg 1259)
Date: 13-FEB 01:54 Tools for Developers

How does it use the screen?  Do you have the option of using the Mac Screen for
debugging?

Paul :)

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

From: IVANOVIC
Subject: Mac Zap v4.5
Date: 14-FEB 00:55 Programming

I just got today my upgrade to v4.5 of Mac Zap -- and I like what I've got. The
primary reason I upgraded was to be able to read physical blocks on my hard
disk, and that I can do.  Everything seems to work.  The windows not updating
perfectly has been fixed, and in general, a good program has been made to work
better.

There is SCSI support for finding lost files (deleted ones) and for displaying
the volume allocation map graphically.  The mouse turns into a cross hair when
over the display, and the block number is displayed.  If a file is selected,
then only it's allocated blocks are displayed.  Pretty sexy, if you ask me.

I also got Les Herbst's "Macintosh Floppy and Hard Disk MFS and HFS
Disk Structures" book.  It's 61 pages long and it contains information
and discussion about disks and servers.  Nothing exceptionally new,
but it's all in one place and organized.  Worth $15?  Yeah, maybe.
The discussion in the Fedit+ manual is better in many ways.

                                        -- Vladimir

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

From: JIMH
Subject: cricket draw
Date: 14-FEB 01:10 Business Mac

All you who have been having problems with cricket draw 1.1 will be
mailed out next week to all registered owners. they assure me all
major bugs are fixed! jim

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

From: IVANOVIC
Subject: Investigations into Memory Usage
Date: 14-FEB 03:06 Programming

I spent some time trying to figure out who was using what in memory because I
like to run with lots of specialized code, like debuggers (TMON), macro
facilities (Tempo), disk caches (TurboCharger), pseudo-multitasking (Switcher),
etc.  I was having problems, so I tried to figure out who was stepping on whose
toes.  Appended are my results.

There are gaps in my knowledge.  For example, I have NO idea how TurboCharger
works.  (I use it without Quick Quit and it is better behaved.)  Others are
encouraged to contribute what they know.

...........................................................................

  Mac+ Memory Usage
   * Base Configuration
      + System 3.2 from HD20 Startup diskette.
      + 128K v3 ROM
      + 2MB memory by Levco clip-on.
      + Boot Block Version = $12
      + Sound buffer size = $300
      + Screen buffer size = $5600
      + Jump table and application parameter size = $238
      + Application globals and QuickDraw globals size = $D56
      + Stack size = $80A2
      + Application heap size = $1E 4BD0
      + System heap size = $B700
   * Apple RAM cache
      + Selected size = 128K
      + Installs itself in high memory directly below the screen buffer.
      + Modifies
         - Lowers BufPtr by the size of the cache.
      + Notes
         - Not a "write-through" cache; flushed only when
            - another block replaces it (LRU)
            - a volume flush is done
            - the application terminates.
         - Code loaded above BufPtr by INIT 35 resource
         - Cannot be removed except by reboot.
         - Cannot be installed except at boot time, i.e. Control panel must
           be set prior to boot.
         - Limited choice of sizes. From 32K to 1.5M with increments of 32K
           for 32-128K, 64K for 128-512K, 128K for 512-1M and 512K to 1.5M.
         - See Tech Note #81 for details.
   * System Heap Size
      + Configured by modifying an entry in the boot disk's boot block.
      + Version 1.2 of the Boot Data has the 512K system heap size at
        (indicated) $C000 and the Boot Block Version=$12.  Actual size is $B700.
      + Boot Block Version from $12 to $15 only.
         - System heap grows by $900 to value stated in boot block.
         - The application heap shrinks by $800 and gets bumped up by the
           growing system heap.
      + Boot Block Version=$15 and System Heap Size=$D000.
         - Corresponding increase in System Heap. ApplZone increased by
           appropriate amount.
      + Same  for System Heap Size=$E000.
      + Modifies
         - For change to Boot Block Version, ApplZone upped by $900 and
           HeapEnd upped by $100.
         - For change in system heap size in boot block, equal change in
           ApplZone.
   * RAMSafe 1.1
      + Selected size = 1024K (= 1 MB)
      + Installs itself in high memory, but leaves the sound and screen
        buffers where they are.
      + MemTop and BufPtr are set equal to 1MB.
      + Modifies
         - BufPtr lowered by selected size of (the RAM disk minus the size
           of the sound and screen buffers). $1F A700 - ($10 0000 - $30 - $5600)
           = $F FD30
         - MemTop lowered by the selected size.
      + Notes
         - Has no removal option.
         - Shutdown-proof (uses a modified PROM which prevents clearing of
            memory on reboot), but not powerdown-proof.
         - The size of the area reserved is the selected size minus the
           size of the sound and screen buffers, i.e. $10 0000 - ( $300 + $5600)
           = $F A700 = 1001K.
         - The RAM disk itself indicates a size of 975K plus 8K for the
           desktop, or 983K total.
         - Only 5 sizes to choose from: 512K 768K 1024K 1280K and 1536K.
   * MaxRAM 2.3
      + Selected size = 1024K
      + Installs itself in high memory below the sound and screen buffers.
      + Modifies
         - BufPtr lowered by the selected size plus an extra 8 bytes.
           ($10 0000 + $8 = $10 0008)
      + Notes
         - RAM disk is 997K with 8K used = 1005K.
      + Remove returns everything to its previous state.
      + Size selection is has a 1K adjustablity.
   * RAMStart 1.3
      + Selected size = 1024K
      + Installs itself in high memory just below the sound and screen
        buffers.
      + Modifies
         - BufPtr is lowered by 1024K exactly.
      + Notes
         - RAM disk has 1000K available with 8K used.  Hence 16K is used
           for the driver and data.
         - Size is adjustable in 1K increments.
         - Removal restores previous state.
   * TurboCharger 2.0 Rev D
      + Installs itself in memory somewhere somehow.
      + Modifies
         - BufPtr
            - Definitions
               - Memory left over = modified BufPtr - size selected
            - 512K size  -> $8 5470
               - $17 5290 used = 1492K
            - 768K size  -> $C 5580
               - $13 5180 used = 1236K
            - 1024K size -> $10 4C40
               - $F 5AC0 used =  982K
            - 1280K size -> $14 5590
               - $B 5170 used =  724K
            - turned off -> $1F A700 = 2025K
      + Notes
         - Auto Buffer Sizing was turned off
         - Removal returns values to normal state.
         - The addresses below BufPtr are the normal distance apart, e.g.
           the size of the system stack is always $80A2.
         - In the 512K case, the application limit and the application heap
           end were within $4C of each other.
         - A choice of 32K either crashes or hangs the Mac.
   * Tempo 1.1b
      + Installs itself in high memory below the screen and sound buffers.
        Jillions of resources are added to the system file.
      + Modifies
         - BufPtr is lowered by $1B1E.
      + Notes
         - Removal does not adjust BufPtr, but does remove the resources
           from the system file.
         - Uses at least 1052 bytes of system heap.
         - Installs 78 167 bytes into the system file.  Removal leaves 1452
           bytes behind (vestigial resources.)
   * MacsBug 5.2
      + Installs itself in high memory.
      + See "Inside Switcher" for details.
      + Modifies
         - BufPtr - lowers it by 44 940 bytes ($AF8C)
   * TMON 2.585
      + Can be installed either in the system heap or in high memory.
      + Modifies
         - [In system heap] HeapEnd increases by size of (TMON - 4 bytes).
         - [In high memory] BufPtr is lowered by size of (TMON - 11 bytes).
      + Notes
         - Maximum TMON size with EUA 685 is $12E2A or 77 354 bytes as
           calculated by TMON's Monitor size menu item.
         - If both TMON and MacsBug are installed, TMON wins.
   * Switcher 5.0.1
      + See "Inside Switcher" for details
............................................................................

Worse than leaving out information is presenting incorrect information.  Please
DO correct any errors.

Many, many thanks to Julian Vrieslander (eacj%batcomputer@cu-arpa.cs.cornell.)
*that's ".edu" for his excellent MacDraw Mac+ Memory Map.

                                                -- Vladimir

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

From: PEABO
Subject: RE: Investigations into Memory Usage (Re: Msg 17291)
Date: 14-FEB 04:34 Programming

Thanks for the investigation!

Because of the problems with Quick Quit, I don't use TurboCharger on my hard
disk system.  I use it on my Mac 512K Floppy system all the time though, and it
works pretty well for the limited applications I use it with (MacTerminal and
DA's mostly).

peter

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

From: MACINTOUCH
Subject: RE: Investigations into Memory Usage (Re: Msg 17294)
Date: 14-FEB 11:24 Programming

I'm using Turbo with the 2.5MB Mac Plus and the DataFrame hard disk, and, for
me, it's a very efficient way to use the extra RAM.  I've turned off Quick Quit
and I'm careful using it with TOPS, but it's been working fine with a variety
of normal word processing, graphics, and telecomm. applications.

Ric

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

End of Delphi Mac Digest
************************
-------