steve@ms.uky.edu (Steve Ferry) (12/31/87)
I just bought a copy of Multifinder from my local dealer and I'm upset by the way it handles DA's. I use a Datadesk 101 keyboard with my MacPlus. If I understand correctly, I can no longer use the function keys because the 101-KEYS DA is in a separate layer from the programs. This problem also affects the Pop-up DA and I assume that it is also a problem for TEMPO users. Is there a workaround for this problem? Servant doesn't do this. (I have version .951 of Servant. Is there a release version available?). I apologize if this has already been discussed to death on the net. I have just gotten back from 8 months in Europe. If the issue has been done to death already, would some kind soul please mail me a summary of the discussion? Thanks. steve ferry steve@UKMA.BITNET
bill@ut-emx.UUCP (Bill Jefferys) (01/03/88)
In article <7965@j.ms.uky.edu> steve@ms.uky.edu (Steve Ferry) writes:
~
~ I just bought a copy of Multifinder from my local dealer
~and I'm upset by the way it handles DA's. I use a Datadesk
~101 keyboard with my MacPlus. If I understand correctly,
~I can no longer use the function keys because the 101-KEYS DA
~is in a separate layer from the programs.
As I learned when I had this problem, holding down the option
key when selecting the DA brings it up in the usual way.
More importantly, this behavior seems to me to be a failure of
systems design on the part of Apple. In general, MF ought to
behave in ways that are parallel to the way things work under the
old finder. Thus, it should have been set up to bring up the
DA in the ordinary way when it is selected in the ordinary
way, and to bring it up in a second partition (under the DA
handler) ONLY when the option key is held down. This would
be much less confusing and would be easier on those of us who,
for one reason or another, must switch between a MF and a non-MF
environment.
Apple, are you listening?
Bill Jefferysgoldman@apple.UUCP (Phil Goldman) (01/03/88)
In article <411@ut-emx.UUCP> bill@emx.UUCP (William H. Jefferys) writes: >In article <7965@j.ms.uky.edu> steve@ms.uky.edu (Steve Ferry) writes: >~ >~ I just bought a copy of Multifinder from my local dealer >~and I'm upset by the way it handles DA's. I use a Datadesk >~... > >More importantly, this behavior seems to me to be a failure of >systems design on the part of Apple. In general, MF ought to >behave in ways that are parallel to the way things work under the >old finder. >... This is definitely true, when the parallels are clear and the benefits outweigh the problems. In this case neither is so. The only benefit to having the default be to open in the layer is to allow for easier use of parasite DAs. It seems as though the number of non-parasitic DAs is far greater than the parasitic ones. In addition many of the parasitic ones are used with only one or a few applications (i.e. Spell Checkers for word processors, Click Art Effects for MacPaint, etc.). Therefore, the logical choice seemed to be what currently exists: normal open creates another layer, Font/DA moving a parasitic DA into an application's resource file is the easiest for the app- specific parasitic DAs. This leaves the category of DAs that are parasitic but not app-specific. Really, these should not be DAs at all, they should probably be INITs. If they need an interface then this should be a DA (which will have no problem at all existing in its own layer) or better yet an application. For a good example of this, take a look at the Intermail elctronic mail system, which combines an INIT and a DA. The INIT allows for notification in any layer, but the DA interface stays in the DA Handler layer. The primary reason for keeping the DAs in a separate layer is that many applications simply cannot handle having a DA in its memory partition. This is a very difficult (read impossible) job for developers who wish to do comprehensive memory management. There is simple no way to handle a DA since it has arbitrary memory requirements at arbitrary times. The only real possibility is to increase the SIZE of every single application, since any application might be subject to the memory requirements of the DA. This would be a huge waste of memory, which is already a scarce resource. Therefore, the only real solution is to separate the DA from the app. There are also obvious benefits to separating the DAs. For example a DA such as the alarm clock will stay open even if the app that it was originally opened from is quit. Also, it is a great deal easier to keep track of a DA window since it is grouped with all other DAs, rather than spliced into app's window list. Hopefully the developers that have created these DAs will soon have a chance to switch to INITs. Also, we hope to add support for inter-process communication, so that these products could be written simply as apps. This supports the desired ultimate end, because the application model is clean and easy to support (from the point of view of the developer and of Apple) while the DA model is not. Of course, if the need is great enough there are ways for us to better support the non-app-specific parasitic DAs in the short run. Why don't all of you out there in net-land let us know how often you use such DAs? The current belief here is that they are not used that often. > >Apple, are you listening? > >Bill Jefferys Yes, we're always listening. Always. Merry Christmas. -Phil Goldman Apple Computer
pollock@usfvax2.UUCP (Wayne Pollock) (01/05/88)
First of all, thanks, Phil, for the detailed response; its always nice
to know that people at Apple really listen!
As to you query about "parasitic" DAs, I believe they are more common
than you think; I often use my spelling checker in conjuction with my
terminal emulator, and even with my text editor. So installing it in my
word processor wouldn't work. In addition to spelling checkers, there are
other word related tools, art grabbers, journal makers, work loggers,
and some useful but older DAs which won't work unless opened in the
application's memory space.
As you suggested, future evolution of the mac should make this a non-issue;
most of the problematic DAs will be rewritten as Inits or CDEVs or simply
as applications. In the meantime, judging by the discussion here, this is
a problem for many users; a better answer than the option key trick is
needed.
It seems to me the whole issue can be simply resolved. Macintosh
designer's had the tremendous foresight to structure files into seperate
pieces. They knew that there would be additions/changes and they provided
a nice mechanism to allow for them.
Why not add a resource type, recognized by the system software, that would
tell the system where to install a DA? A few lines of code in the DA
opening sequence, a technote telling people what resource to add to DAs
to modify the behavior, and viola! the problem is gone.
For example, the presence of an owned resouce 'DAH ' in a DA could cause
the DA to be opened by the DA handler; otherwise use the default
(application memory space). If you prefer, use 'DAAP' to instruct the
system to put the DA in the application's space have use the DA handler
by default. And of course the option key trick would still be available
as an overide.)
I have this same suggestion for 'SIZE' resources; it should be possible to
put a SIZE resource in a document, which would override the SIZE in the
application (which would be used as a default). As you pointed out, memory
is a scarce resource it it is a shame to waste it by having a spreadsheet
program request enought memory for a large spreadsheet when all I'm using
is an itty-bitty one.
A smart application could put the SIZE resource in each document it
creates, and adjust it as the document grows and/or shrinks. This ought
to work whenever the application is started by double-clicking one of its
documents; naturally the default SIZE would be used if the application
were launched directly.
Wayne Pollock (The MAD Scientist) pollock@usfvax2.usf.edu.UUCP
Usenet: ...!{ihnp4, cbatt}!codas!usfvax2!pollock
GEnie: W.POLLOCKanson@elrond.CalComp.COM (Ed Anson) (01/06/88)
In article <937@usfvax2.UUCP> pollock@usfvax2.usf.edu.UUCP (Wayne Pollock) writes: >First of all, thanks, Phil, for the detailed response; its always nice >to know that people at Apple really listen! I agree! >I have this same suggestion for 'SIZE' resources; it should be possible to >put a SIZE resource in a document, which would override the SIZE in the >application (which would be used as a default). As you pointed out, memory >is a scarce resource it it is a shame to waste it by having a spreadsheet >program request enought memory for a large spreadsheet when all I'm using >is an itty-bitty one. I second the motion. This problem (together with the lack of print spooling) is the main reason I find myself flipping back and forth between Finder and MF. Most of the time, I use Excel with tiny spreadsheets, together with some other applications. It would be unworkable to give Excel more than its normal memory partition, since most of that is unused. But I occasionally open a dozen largish spreadsheets at a time. This just doesn't work under MF, because the partition is too small. Although Wayne's suggestion is not a perfect solution in my case, it can be made to work. And I can't think of a better one. BTW: Adding a SIZE resource to a document shouldn't require a resource editor. Perhaps the existing "Get Info" mechanism could be extended to work with documents. -- ===================================================================== Ed Anson, Calcomp Display Products Division, Hudson NH 03051 (603) 885-8712, anson@elrond.CalComp.COM
kaufman@Shasta.STANFORD.EDU (Marc Kaufman) (01/08/88)
In article <1948@elrond.CalComp.COM> anson@elrond.UUCP (Ed Anson) writes: .>I have this same suggestion for 'SIZE' resources; it should be possible to .>put a SIZE resource in a document, which would override the SIZE in the .>application (which would be used as a default)... > I second the motion. This problem (together with the lack of print > spooling) is the main reason I find myself flipping back and forth between > Finder and MF... I have a similar problem, but from the other side. I am writing a print driver that wants to build a pixel image of the page in the MAC, then send it to the device. I think it is unfriendly to ask applications to include an additional 1 or 2 Megabytes in the SIZE resource, just so I can lay out the page (high resolution pages, in color). Since the MAC is nominally a "single user" machine, why not allow an application to request a non- contiguous memory allocation. I know that there are potential fragmentation problems, but we are probably not launching arbitrary user tasks while this extra memory is in use, and in any event the process can request just what it needs -- which is more efficient than guessing at 'SIZE' time. Marc Kaufman (kaufman@Shasta.stanford.edu)
dorner@uxc.cso.uiuc.edu (01/08/88)
>I have this same suggestion for 'SIZE' resources; it should be possible to >put a SIZE resource in a document, which would override the SIZE in the >application (which would be used as a default). As you pointed out, memory >is a scarce resource it it is a shame to waste it by having a spreadsheet >program request enought memory for a large spreadsheet when all I'm using >is an itty-bitty one. Under Multifinder, programs can load in a small partition, then ask for more if they need it, right? So, assuming developers implement this, the next round of program updates ought to make the abovementioned feature unnecessary. ---- Steve Dorner, U of Illinois Computing Services Office Internet: dorner@uxc.cso.uiuc.edu UUCP: ihnp4!uiucuxc!dorner IfUMust: (217) 333-3339
lawrence@bbn.COM (Gabriel Lawrence) (01/09/88)
kaufman@Shasta.stanford.edu (Marc Kaufman) writes: >anson@elrond.UUCP (Ed Anson) writes: > >.>I have this same suggestion for 'SIZE' resources; it should be possible to >.>put a SIZE resource in a document, which would override the SIZE in the >.>application (which would be used as a default)... > >> I second the motion. This problem (together with the lack of print >> spooling) is the main reason I find myself flipping back and forth between >> Finder and MF... > >I have a similar problem, but from the other side. I am writing a print >driver that wants to build a pixel image of the page in the MAC, then send >it to the device. I think it is unfriendly to ask applications to include >an additional 1 or 2 Megabytes in the SIZE resource, just so I can lay >out the page (high resolution pages, in color). Since the MAC is nominally >a "single user" machine, why not allow an application to request a non- >contiguous memory allocation. I know that there are potential fragmentation >problems, but we are probably not launching arbitrary user tasks while this >extra memory is in use, and in any event the process can request just what >it needs -- which is more efficient than guessing at 'SIZE' time. Hmmm... Either I'm missing something or Microsoft et al didn't read their MultiFinder-friendly technical documentation very thoroughly. The documentation plainly states that an application should pre-allocate space, via the SIZE resource, enough room for the application to perform comfortably in. Space for sizable documents or tasks requiring additional memory (such as pre-print imaging) can be allocated by use of any one of the new memory manager temporary allocation procedure calls. Call me silly but I assumed that the new temporary memory allocation calls were written specifically for the purpose of keeping the SIZE resource requirements reasonable. It would also seem to me that if applications handled this mechanism correctly, it would obviate the need for documents to carry around their own SIZE resource. An application could easily open a document, determine it's size and then allocate additional memory before reading the data into memory. Please, if I'm incorrect, someone kindly enlighten me. =Gabriel Lawrence= =BBN Communications= USENET: ...!harvard!bbn!ccv!lawrence INTERNET: lawrence@BBN.COM
goldman@apple.UUCP (Phil Goldman) (01/09/88)
In article <2388@Shasta.STANFORD.EDU> kaufman@Shasta.stanford.edu (Marc Kaufman) writes: >...I think it is unfriendly to ask applications to include >an additional 1 or 2 Megabytes in the SIZE resource, just so I can lay >out the page (high resolution pages, in color). Since the MAC is nominally >a "single user" machine, why not allow an application to request a non- >contiguous memory allocation. I know that there are potential fragmentation >problems, but we are probably not launching arbitrary user tasks while this >extra memory is in use, and in any event the process can request just what >it needs -- which is more efficient than guessing at 'SIZE' time. > This is possible using the MultiFinder dynamic memory calls. In fact, this is a much preferred method for handling transient memory requests. -Phil Goldman Apple Computer
pollock@usfvax2.UUCP (Wayne Pollock) (01/23/88)
In article <174400093@uxc.cso.uiuc.edu> dorner@uxc.cso.uiuc.edu writes: >>I have this same suggestion for 'SIZE' resources; it should be possible to >>put a SIZE resource in a document, which would override the SIZE in the >>application (which would be used as a default). ... > >Under Multifinder, programs can load in a small partition, then ask for more >if they need it, right? So, assuming developers implement this, the next >round of program updates ought to make the abovementioned feature unnecessary. Sure, for new applications. Do you have any idea how much macintosh software already exists? A whole lot! Me, I'd rather have the ability to put a SIZE resource in a document I use frequently than wait for all my favorite applications to be revised by the developers! (After all, my suggestion isn't incompatable with yours.) Wayne Pollock (The MAD Scientist) pollock@usfvax2.usf.edu.UUCP Usenet: ...!{ihnp4, cbatt}!codas!usfvax2!pollock GEnie: W.POLLOCK
pollock@usfvax2.UUCP (Wayne Pollock) (01/23/88)
PS Don't forget that many people will not be using multifinder, but with
their smaller macs will be using switcher! So a SIZE resource is still
important.
Wayne Pollock (The MAD Scientist) pollock@usfvax2.usf.edu.UUCP
Usenet: ...!{ihnp4, cbatt}!codas!usfvax2!pollockjcc@ut-emx.UUCP (Chris Cooley) (01/26/88)
In article <940@usfvax2.UUCP>, pollock@usfvax2.UUCP (Wayne Pollock) writes: > Sure, for new applications. Do you have any idea how much macintosh software > already exists? A whole lot! Me, I'd rather have the ability to put a SIZE > resource in a document I use frequently than wait for all my favorite > applications to be revised by the developers! (After all, my suggestion isn't > incompatable with yours.) > > Wayne Pollock (The MAD Scientist) pollock@usfvax2.usf.edu.UUCP > Usenet: ...!{ihnp4, cbatt}!codas!usfvax2!pollock > GEnie: W.POLLOCK I think I've seen just the thing. There's a small application (PD or Shareware) that lets you select what goes in the SIZE resource, and if there's something there already, it displays those sizes. By some of the things posted here, I think this is a good candidate for the first piece of software that I post here. (Drat. I was hoping to first post some of MY work... >sniff<) I'll go ahead and post it, if I'm able. /---------------------------------v------------------------------\ ( J. Chris Cooley |[mailpaths under construction] ) (( Univ. of Texas Comp. Center | jcc@ut-emx.UUCP )) (( Austin, TX 78712 | jcc@emx.cc.utexas.edu )) ( 512/471-3241 x417 | ) \---------------------------------^------------------------------/ \Disclaimer: You think THEY agree with THESE opinions? Hah!/ \--------------------------------------------------------/
goldman@apple.UUCP (Phil Goldman) (01/27/88)
In article <941@usfvax2.UUCP> pollock@usfvax2.usf.edu.UUCP (Wayne Pollock) writes: >PS Don't forget that many people will not be using multifinder, but with >their smaller macs will be using switcher! So a SIZE resource is still >important. This is a common misunderstanding. Although Apple recommends that you use Finder 6.0 along with MultiFinder, it is possible to use any of the smaller Finder replacement programs in existence. In such a configuration MultiFinder uses up *less* memory than Switcher (for a variety of reasons), but still provides all of its usual services, such as multiple layers, background processing, etc. Therefore, there is no valid reason to use Switcher, unless you are tied to an old system that cannot support MultiFinder.. If there is enough interest, I will post a finder replacement written by David Shayer of the SQA Tools group at Apple that runs in 18K. Howeve, after using it, I think that most users will become frustrated at not having the complete set of Finder services available. -Phil Goldman Apple Computer
pollock@usfvax2.UUCP (Wayne Pollock) (02/03/88)
In article <7276@apple.UUCP> goldman@apple.UUCP (Phil Goldman) writes: >This is a common misunderstanding. Although Apple recommends that you use >Finder 6.0 along with MultiFinder, it is possible to use any of the smaller >Finder replacement programs in existence. ... I think you misunderstand me; by small computer I mean that there are many people using 128K and 512K and 512KE Macintoshes (hard to believe, but true). These people can not run multifinder, regardless of how much memory you can squeeze out of finder. These people will run switcher (unless they're so strapped for memory they just run finder). So SIZE resources do matter. Wayne Pollock (The MAD Scientist) pollock@usfvax2.usf.edu.UUCP Usenet: ...!{ihnp4, cbatt}!codas!usfvax2!pollock GEnie: W.POLLOCK
goldman@apple.UUCP (Phil Goldman) (02/05/88)
In article <947@usfvax2.UUCP> pollock@usfvax2.usf.edu.UUCP (Wayne Pollock) writes: >I think you misunderstand me; by small computer I mean that there are >many people using 128K and 512K and 512KE Macintoshes (hard to believe, >but true). These people can not run multifinder, regardless of how much >memory you can squeeze out of finder. These people will run switcher >(unless they're so strapped for memory they just run finder). So SIZE >resources do matter. I can understand just running the Finder, but I believe that the intelligent 512KE user can run MultiFinder and have more memory available for applications than they would using Switcher. Of course, MultiFinder will not run on machines with old ROMs, but those people really should buy the ROM upgrade pretty soon if they ever intend to; I hear they're getting scarce. Anyway, it may turn out that Switcher will let you run 1 "big" app that is larger in size than that possible w/ MF (but I'm not sure even that is true). However, the big win with MultiFinder is that it shares those large system resources such as fonts, so that each app does not need its own copy. Therefore, the SIZE resources for apps running with MultiFinder can be a lot smaller than with Switcher. The confusion is probably that many people tried the apps with the SIZEs set for Switcher, when they really didn't need to be that big (just wasting memory). Of course, to do all this it is necessary to have a very small Finder replacement. -Phil Goldman Apple Computer
isle@eleazar.Dartmouth.EDU (Ken Hancock) (02/07/88)
In article <7332@apple.UUCP> goldman@apple.UUCP (Phil Goldman) writes: > >Of course, to do all this it is necessary to have a very small Finder >replacement. What would you recommend? If one has DiskTop, the Finder isn't really necessary anyway... Ken -- Ken Hancock UUCP: isle@eleazar.dartmouth.edu BITNET: isle@eleazar.dartmouth.edu DISCLAIMER: If people weren't so sue-happy, I wouldn't need one!