tonyrich@titanic.cs.wisc.edu (Anthony Rich) (06/08/90)
THE EVIDENCE AND ACCUSATION. I recently reported that Edit 2.1 was crashing reliably on my Mac II under 6.0.5. Others reported problems under 6.0.4, but it had worked okay for me under 6.0.4. On my machine, the crashes under 6.0.5 occurred even if I turned off all inits using the Init cdev, and when it crashed, my hard disk was rendered unbootable (but repairable using SUM II). THE DENIAL. However, I recently heard that another person WAS using Edit 2.1 reliably under 6.0.5, on a IIci. So I did some more testing. THE INVESTIGATION. I found that Edit worked fine when I booted from a floppy that had only a minimal copy of System 6.0.5 on it. So I put that new, virgin 6.0.5 System folder on my hard disk and started dragging the inits and cdevs from my old System folder into it one at a time: Suitcase II, On Cue, etc. After each addition, I rebooted and edited something with Edit 2.1 to see if the newcomer caused Edit to crash. Finally Edit began crashing again, but when I pulled the most recent addition out of the System folder, Edit STILL crashed! Then I noticed it edited small files OK but crashed on larger ones. I pulled more things out of the System folder and then Edit could handle the larger files too. THE NEW SUSPECT. With some further experimentation I think I now see the problem. (I'm not all that familiar with Mac internals, so somebody please correct me if I'm wrong.) As I understand it, inits and cdevs occupy an an area of memory called the system heap; apparently it's an area of limited size. Edit 2.1 appears to start crashing when the addition of inits/cdevs reduces the amount of free space in the system heap below some threshold. It doesn't seem to matter which inits/cdevs are in there; it's the amount of system heap that's left over for Edit to use that matters. And apparently just "disabling" the inits/cdevs doesn't do the trick, you have to actually remove them from the System folder. I did a "Get Info" on Edit and saw that its suggested and actual application memory size (not the same thing as the system heap size) was 224K; hoping for the best, I tried increasing that to 512K, and for a while I thought that fixed things, but it didn't; I still got crashes. SOLVING THE CRIME. Over in comp.sys.mac.system, someone mentioned that if you buy Disktop, you also get a program called HeapFixer which allows the maximum size of the system heap to be increased. Another user reported that after using HeapFixer nearly all of his system bombs went away. But many of us won't want to buy Disktop just to get HeapFixer. Someone also said they thought HeapFixer was available separately through some user groups with the permission of CE Software. 1. Can anyone confirm whether HeapFixer is available separately (hopefully free) with CE's blessing, and if so, where it's available? Could it be posted to the sumex and Rice archives? 2. Does anyone know of an easy way to increase the size of the system heap, like using ResEdit to change its maximum size somewhere? THE CONFESSION. I got Edit 2.1 from a local PD/Shareware collection a LONG time ago and have been using it gratis, but I understand now that it is copyrighted and sold by Consulair. If someone would send me Consulair's address, I'd like to make restitution. (I *do* pay for the shareware and commercial software I use. It's harder on the wallet but easier on the conscience. :^) -- ----------------------------------------- | EMAIL: tonyrich@titanic.cs.wisc.edu | | Disclaimer: I speak only for myself. | -----------------------------------------
francis@tut.cis.ohio-state.edu (RD Francis) (06/08/90)
In article <10566@spool.cs.wisc.edu> tonyrich@titanic.cs.wisc.edu (Anthony Rich) writes: >THE NEW SUSPECT. >With some further experimentation I think I now see the problem. (I'm not >all that familiar with Mac internals, so somebody please correct me if I'm >wrong.) As I understand it, inits and cdevs occupy an an area of memory >called the system heap; apparently it's an area of limited size. Edit 2.1 >appears to start crashing when the addition of inits/cdevs reduces the >amount of free space in the system heap below some threshold. It doesn't >seem to matter which inits/cdevs are in there; it's the amount of system >heap that's left over for Edit to use that matters. And apparently just >"disabling" the inits/cdevs doesn't do the trick, you have to actually >remove them from the System folder. > >I did a "Get Info" on Edit and saw that its suggested and actual application >memory size (not the same thing as the system heap size) was 224K; hoping for >the best, I tried increasing that to 512K, and for a while I thought that >fixed things, but it didn't; I still got crashes. Quick question: are you running under Multi-Finder? If so, then you haven't found a solution to your problem. Under Multi-Finder, programs grab a chunk of memory and keep it. In general, if the memory needed isn't available, the program won't launch. Finally, the system heap is separate, so it wouldn't be having an effect on Edit However, if you are not using Multi-Finder, then applications, when launched grab all available space. If all available space is less than that 224K recommended figure, Edit may not complain.However, as soon as it starts wanting more memory, it may well just up and die. Increasing the system heap in these circumstances, will only reduce the amount of available memory even more. Check how much memory isn't taken up by the System in the About Finder dialog; that should help. -- R David Francis francis@cis.ohio-state.edu
philip@Pescadero.Stanford.EDU (Philip Machanick) (06/09/90)
In article <10566@spool.cs.wisc.edu>, tonyrich@titanic.cs.wisc.edu (Anthony Rich) writes: > I got Edit 2.1 from a local PD/Shareware collection a LONG time ago > and have been using it gratis, but I understand now that it is copyrighted > and sold by Consulair. If someone would send me Consulair's address, > I'd like to make restitution. (I *do* pay for the shareware and commercial > software I use. It's harder on the wallet but easier on the conscience. :^) The following comes from my copy of the Consulair 68000 development system: Consulair Corp. PO Box 2192 Ketchum ID 83340 (208) 726-5846 fax (208) 726-1401 I think these guys are missing out on significant extra sales by not unbundling Edit from their development system. If it was really cheap (the whole development system is around $90), many people wanting a simple editor with tabs, multiple windows and no limit on file length would use it (the current version is 6.0 - I haven't used it a lot, so I don't know if it's a any better than 2.1). Philip Machanick philip@pescadero.stanford.edu
barrey@ka.excelan.com (Barrey Jewall) (06/09/90)
In article <10566@spool.cs.wisc.edu> tonyrich@titanic.cs.wisc.edu (Anthony Rich) writes: [in part] >THE CONFESSION. >I got Edit 2.1 from a local PD/Shareware collection a LONG time ago >and have been using it gratis, but I understand now that it is copyrighted >and sold by Consulair. If someone would send me Consulair's address, >I'd like to make restitution. (I *do* pay for the shareware and commercial >software I use. It's harder on the wallet but easier on the conscience. :^) >-- >----------------------------------------- >| EMAIL: tonyrich@titanic.cs.wisc.edu | >| Disclaimer: I speak only for myself. | >----------------------------------------- I would be interested in consulair's address also, so I can find out about upgrading my ORIGINAL copy of MDS (complete w/ 2 mac debugger and cable) Thanks- Barrey barrey@novell.COM
Adam.Frix@p2.f200.n226.z1.FIDONET.ORG (Adam Frix) (06/11/90)
(stuff about investigating why Edit 2.1 crashes deleted) > SOLVING THE CRIME. > Over in comp.sys.mac.system, someone mentioned that if you buy Disktop, > you also get a program called HeapFixer which allows the maximum size of > the system heap to be increased. Another user reported that after using > HeapFixer nearly all of his system bombs went away. But many of us won't > want to buy Disktop just to get HeapFixer. Someone also said they thought > HeapFixer was available separately through some user groups with the > permission of CE Software. > > 1. Can anyone confirm whether HeapFixer is available separately > (hopefully free) with CE's blessing, and if so, where it's available? > Could it be posted to the sumex and Rice archives? HeapFixer has been posted in the CESoftware data library in CompuServe for some time now. I can't imagine them objecting to it being posted to archives, but maybe someone should check. > ----------------------------------------- > I EMAIL: tonyrich@titanic.cs.wisc.edu I > I Disclaimer: I speak only for myself. I > ----------------------------------------- --Adam-- -- Adam Frix via cmhGate - Net 226 fido<=>uucp gateway Col, OH UUCP: ...!osu-cis!n8emr!cmhgate!200.2!Adam.Frix INET: Adam.Frix@p2.f200.n226.z1.FIDONET.ORG
ephraim@think.com (Ephraim Vishniac) (06/11/90)
In article <1377@excelan.COM> barrey@ka.excelan.com (Barrey Jewall) writes: >I would be interested in consulair's address also, so I can find out about >upgrading my ORIGINAL copy of MDS (complete w/ 2 mac debugger and cable) Consulair Corp. P.O. Box 2192 Ketchum, ID 83340 (208) 726-5846 I called a few weeks ago and asked about upgrades for MDS owners. The lady who answered the phone explained that there are two alternatives. For $50, you can get the "current" version of CDS. No 68020/030/881 support, isn't guaranteed to work under Multifinder. For $130 (full list price) you can get their "new" 68020/030 assember. She explained that it's not available as an upgrade because "it's really a new product." I took the bait. Since I've got lots of old MDS code that I still tinker with, and I can't live without Multifinder, I bought the "new" package. It sucks. The "new" CDS is the old CDS with support the new 020/030 opcodes. Any honest company would sell it as a minor upgrade. It doesn't crash under Multifinder (that I've seen), but the Linker still draws directly in the screen and wipes out underlying windows. The assembler has some new "optimizations," but at least one of them is wrong. I called Bill Duvall about it ten days ago; no fix yet. Edit has no new features, unless you count not crashing. The Transfer menu doesn't work under Multifinder. The manual hints at this without coming right out and saying so, but Duvall confirmed that it doesn't work and it's not going to. -- Ephraim Vishniac ephraim@think.com ThinkingCorp@applelink.apple.com Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142 One of the flaws in the anarchic bopper society was the ease with which such crazed rumors could spread.
jwwalker@usceast.UUCP (Jim Walker) (06/12/90)
In article <56446.2673B578@cmhgate.FIDONET.ORG> Adam.Frix@p2.f200.n226.z1.FIDONET.ORG (Adam Frix) writes: [stuff deleted...] |HeapFixer has been posted in the CESoftware data library in CompuServe for |some time now. I can't imagine them objecting to it being posted to |archives, but maybe someone should check. I can imagine that they would object. Although they can't stop anyone from downloading it from their CIS forum, I have read on CIS that they consider Heapfixer to be "only for CE customers." -- Jim Walker jwwalker@usceast.cs.scarolina.edu 76367.2271@compuserve.com
Michael.Burton@p3.f200.n226.z1.FIDONET.ORG (Michael Burton) (06/13/90)
Responding to a message from Anthony Rich about problems with Edit 2.1, R David Francis wrote: > Finally, the system heap is separate, so it wouldn't be having an > effect on Edit Not necessarily true. The system heap is separate from an application's heap, but virtually every application program calls upon the system for services. If the system runs out of memory in its own heap, every application is likely to suffer. I don't know whether increasing the size of the system heap will help solve Anthony's problem, but it's a reasonable thing to try. -- Michael Burton via cmhGate - Net 226 fido<=>uucp gateway Col, OH UUCP: ...!osu-cis!n8emr!cmhgate!200.3!Michael.Burton INET: Michael.Burton@p3.f200.n226.z1.FIDONET.ORG