shulman@topaz.RUTGERS.EDU (Jeff Shulman) (08/09/86)
Delphi Mac Digest Saturday, 9 August 1986 Volume 2 : Issue 35
Today's Topics:
RE: List Manager LDEF (Re: Msg 491)
RE: List Manager LDEF (Re: Msg 493)
RE: List Manager LDEF (Re: Msg 497)
RE: List Manager LDEF (Re: Msg 490)
Resource forks in text documents
RE: Resource forks in text documents (Re: Msg 494)
RE: Resource forks in text documents (Re: Msg 494)
RE: zoom box zooming (Re: Msg 481)
RE: zoom box zooming (Re: Msg 496)
Undo
RE: Undo
RE: system dialogs (Re: Msg 488)
RE: system dialogs (Re: Msg 488)
RE: system dialogs (Re: Msg 488)
C ambiguity?
RE: C ambiguity? (Re: Msg 504)
RE: C ambiguity? (Re: Msg 506)
RE: C ambiguity? (Re: Msg 513)
RE: C ambiguity? (Re: Msg 520)
switcher bug?
RE: switcher bug? (Re: Msg 505)
editor features
RE: editor features (Re: Msg 514)
RE: editor features (Re: Msg 515)
RE: editor features (Re: Msg 521)
RE: editor features (Re: Msg 521)
RE: editor features (Re: Msg 522)
RE: Ruggedized MacIntosh
LightSpeed C vs. TML Pascal
RE: LightSpeed C vs. TML Pascal (Re: Msg 11394)
RE: Best 'C'? (Re: Msg 11385)
RE: Best 'C'? (Re: Msg 11385)
RE: Best 'C'? (Re: Msg 11400)
RE: Best 'C'? (Re: Msg 11400)
RE: Best 'C'? (Re: Msg 11449)
RE: Best 'C'? (Re: Msg 11455)
RE: Best 'C'? (Re: Msg 11461)
RE: Best 'C'? (Re: Msg 11449)
RE: LW Cartridges
RE: LW Cartridges
RE: Cricket Draw (Re: Msg 11249)
packet radio
RE: 9600 baud terminal emulator (Re: Msg 11381)
RE: Cricket Draw (Re: Msg 11450)
RE: Public Domain Software Request
Very Weird Problem
-----------------------------------------------------------------------
From: MARSHG (493)
Subject: RE: List Manager LDEF (Re: Msg 491)
Date: 6-AUG-00:09: Developers' Corner
There's a "bug" in the list manager that, depending on your development system,
may or may not bite you. In the original list manager distribution, selflags
was defined as a byte. In the new distribution, it's a signed byte. With
structure alignment, the list manager expects the pad byte that's thrown in to
be sign extended. Since the lOnlyOne bit is the high bit in selflags, the pad
byte must be 1 filled (set to -1) for lOnlyOne to really work.
If you do that, you will only be able to select one cell. WARNING- you can
force more than one cell to be selected with lsetselect even with onlyone set.
Hope it helps...
Marsh Gosnell
------------------------------
From: DWB (497)
Subject: RE: List Manager LDEF (Re: Msg 493)
Date: 6-AUG-01:55: Developers' Corner
Are you sure about this? My copy of the List Manager documentation
lists selFlags as the first of two bytes, the other being the Boolean
"Active" If that is really the case, then there shouldn't be any pad
bytes generated. The analogous situation might, however, exist with
the high order bit of listFlags, but since the high order bit isn't
defined to have any meaning that hardly matters.
David
------------------------------
From: MARSHG (503)
Subject: RE: List Manager LDEF (Re: Msg 497)
Date: 6-AUG-20:51: Developers' Corner
selflags is supposed to be a "signed byte". Setting lOnlyOne is supposed to
sign extend the pad byte. As a regular "byte", it doesn't. Believe me on this
one, I got the answer from tech support.
Marsh
------------------------------
From: LOGICHACK (525)
Subject: RE: List Manager LDEF (Re: Msg 490)
Date: 8-AUG-03:14: Developers' Corner
I don't know about the scaling but the cache definitely uses the pram copy in
the globals area. I did some stuff with it months ago because I was writing a
game that used both screens so I did this nasty: I save the screen memory
someplae and then turned the cache off. When I exit, I restore the memory and
turned the cache back on. Talk about a hack!!
Did anybody ever notice that the standard LDEF will hide its scroll bars when
its window is deactived? This is per IM but funny thing is Finder breaks the
rule and I like the empty scrollbar better. I worked around it but its pretty
ugly. If anyone has comments or a clean solution, please let the list
programming world know.
Paul :)
------------------------------
From: MARSHG (494)
Subject: Resource forks in text documents
Date: 6-AUG-00:13: Programming Techniques
I'm working on a project where I'll need to add a resource fork (and a few
resources) to text documents that ordinarily don't have a resource fork. Does
anybody know of any applications that will get into trouble if they find a
resource fork? Do I have to worry about the application throwing the resource
fork away on me?
Thanks in advance.
Marsh
------------------------------
From: ASMCOR (502)
Subject: RE: Resource forks in text documents (Re: Msg 494)
Date: 6-AUG-03:40: Programming Techniques
Marsh -
I have done this without problem in the past -- I believe MDS Edit
does it, in fact, storing info on fonts etc. Unless the file is
deleted, I don't think the resource fork would be removed, although I
suppose some application might change or overwrite the resources. I'm
interested to see what others have to say about this, too. Jan
------------------------------
From: DDUNHAM (516)
Subject: RE: Resource forks in text documents (Re: Msg 494)
Date: 7-AUG-21:53: Programming Techniques
I'm pretty sure that QUED throws out your resource fork.
miniWRITER installs its own resources; I've never seen any program have trouble
because they're there.
------------------------------
From: DWB (496)
Subject: RE: zoom box zooming (Re: Msg 481)
Date: 6-AUG-01:39: Programming Techniques
Personally, if they're going to put in zoomrects they really ought to
have a way of turning them off. If you remember back a ways, there
was a lot of discussion about how to turn zoomrects off in Finder
1.1g. I believe that there is currently a flag in the LAYO resource
which controls whether or not it is done. Problem is that doing it
takes time (albeit marginal) which could be better spent doing
something else.
David
------------------------------
From: DDUNHAM (518)
Subject: RE: zoom box zooming (Re: Msg 496)
Date: 7-AUG-21:54: Programming Techniques
I can't imagine why anyone would want to turn off zoomrects. I remember
selecting 8 folders and choosing Open back in Finder 1.0, just to see all the
zooming.
------------------------------
From: DDUNHAM (519)
Subject: Undo
Date: 7-AUG-21:54: Programming Techniques
I will be going to MacWorld Expo, Boston. See you there.
My philosophy of Undo: All Mac programs have it. Or else they're not
really Mac programs.
Or do you want me to tell you how to do it? I'm to embarrassed by the way I do
it now, I've been too lazy to do it right (partly because the Note Pad DA tries
to do it right and has a bug).
------------------------------
From: LOGICHACK (523)
Subject: RE: Undo
Date: 8-AUG-03:04: Programming Techniques
Ric:
What really gets me is that they could have put in an Undo item at no cost to
the program. I think having a dimmed undo item is MUCH better than not having
any. Did they think people were not going to notice this deficiency just by no
having the menu there?
Where I come from, this is called lame. L-A-M-E!
Paul :)
------------------------------
From: ASMCOR (501)
Subject: RE: system dialogs (Re: Msg 488)
Date: 6-AUG-03:36: Programming Techniques
You need to know the item number of the button, then use HiliteControl
to change it's appearance. You can get a handle to the control with
GetDItem by passing it the item number, dialog pointer, etc. Only
problem is that with PrJobDialog the package usually handles putting
up the dialog itself and you never get to see it. So, you'll have to
pre-load the dialog, change it, and then call PrJobDialog and see what
happens. It may be that your changes will be over-ridden, I haven't
tried this. That's what I'd try first, though. Anyone else got a
clever idea? Jan
------------------------------
From: DDUNHAM (510)
Subject: RE: system dialogs (Re: Msg 488)
Date: 7-AUG-03:27: Programming Techniques
You'll need to call PrDlgMain(print_rec,MyJobInit) instead of PrJobDialog()
where
pascal TPPrDlg MyJobInit();
Lew Rollins gave me the details; apparently these are undocumented features
Apple is writing a Tech Note about. Aztec C does include PrDlgMain() in its
library, but not TPPrDlg.
(that's pascal TPPrDlg MyJobInit() with a space)
------------------------------
From: LOFTUSBECKER (511)
Subject: RE: system dialogs (Re: Msg 488)
Date: 7-AUG-06:49: Programming Techniques
Did you try using ResEd on the dialog to disable the button? Or do you
mean you want to do that from a working program? (Get the resource, use
HiliteControl, I think, to disable it, make it unpurgeable while you use
it, and go).
- Lofty
------------------------------
From: JOSEF (504)
Subject: C ambiguity?
Date: 6-AUG-21:27: Programming Techniques
I managed to generate an assignment expression the other day that
behaves differently depending on which compiler I'm using. I realize
this is farily easy to do in C, but I'm wondering whether one or
possibly both are correct. Here is the problem: in the expression
*p++ = *p
is the assignment supposed to take place before the pointer is
incremented, or is this left up to the compiler? The results will of
course be different for the two cases. I carefully perused Harbison &
Steele but could find no unambiguous answer. My cross-compiler at work
does it one way(assignment first) and LightSpeedC the other(increment
first). I suspect this decision is left up to the compiler (which
means I'm being what Harbison & Steele refer to as a "too-clever
programmer").
------------------------------
From: RANDOM (506)
Subject: RE: C ambiguity? (Re: Msg 504)
Date: 6-AUG-22:31: Programming Techniques
The assignment is done to *p, not p++, but the ambiguous part is the
right side; is the value of *p taken before or after p is incremented?
K&R explicitly mention the fact that ambiguous expressions like this
are possible in C. Yes, it is left up to the compiler, and therefore
expressions like this must not be used. I wonder if the ANSI standard
is going to eliminate these kinds of expressions (by establishing an
order of evaluation or something like this).
------------------------------
From: JOSEF (513)
Subject: RE: C ambiguity? (Re: Msg 506)
Date: 7-AUG-21:45: Programming Techniques
After carefully rereaing the chapter on expressions in H&S, I decided
that the correct sequence would be increment, then assignment. This
means that the cross compiler I have on our 11/70 blew it again! I
say again cause we have had numerous little obnoxious problems like
this. Just last week I discovered the damn thing won't let you
declare anything unsigned long!
------------------------------
From: PEABO (520)
Subject: RE: C ambiguity? (Re: Msg 513)
Date: 8-AUG-00:57: Programming Techniques
Unsigned long is not in K&R. Many modern C compilers support unsigned as a
modifier for any integer type, but the original unsigned is a kind of integer,
not a modifier.
K&R says that using ++ or -- in expressions that involve more than one instance
of the lvalue being ++'d or --'d is non-portable. Therefore, it is not
surprising that you would get indeterminate results. Too bad your compiler
doesn't diagnose it, but if you have lint available, you would probably find
that flagged as bad C code.
peter
------------------------------
From: JOSEF (532)
Subject: RE: C ambiguity? (Re: Msg 520)
Date: 8-AUG-21:07: Programming Techniques
Sure enuf--Lint even flagged it twice! However, based on my interpretation of
Harbison & Steele's chapter on expressions, I still believe that the correct
order of evaluation is increment first, then assignment.
Joe
------------------------------
From: JOSEF (505)
Subject: switcher bug?
Date: 6-AUG-21:28: Programming Techniques
I was using LightSpeedC under Switcher 5.0B3 today when I got an "Application
Terminated due to System Error" message. I had allocated 512K to LSC, and was
just in the process of exiting from the application that I was running. I am
presuming that this is a Switcher bug. Anybody got any other thoughts on the
matter?
Joe
------------------------------
From: PEABO (508)
Subject: RE: switcher bug? (Re: Msg 505)
Date: 6-AUG-23:55: Programming Techniques
According to MER, who just answered that question for me, the solution
is to use the COnfigure and Install menu ans specify Permanent when
configuring a slot for switcher. At her advice, I used 512K as the
size of the slot, and it works just fine.
peter
------------------------------
From: JOSEF (514)
Subject: editor features
Date: 7-AUG-21:46: Tools for Developers
I discovered a rather nifty feature in the LightSpeedC editor today
that I haven't noticed in any of the other editors (not even QUED!):
Triple clicking on any line will select the entire line--much easier
than dragging down exactly one line in the left margin.
I have also noticed that double clicking on a word in QUED also selects the
space following that word, which is probably the right thing to do in most
cases. Aren't editors wonderful!!
Speaking of QUED, does anyone know what's different in 1.4 and also what their
upgrade policy is? (I still have 1.3.)
Joe
------------------------------
From: DDUNHAM (515)
Subject: RE: editor features (Re: Msg 514)
Date: 7-AUG-21:53: Tools for Developers
Triple clicking could be nice; I don't use anything that supports it.
QUED is WRONG about selecting the space following a word! The most
common editing operation is to rephrase something. To do this, you
change one word for another. Double-click the word to change, type
the new one. Simple in MacWrite or miniWRITER. But in QUED, you need
to pay attention to the context. If the word precedes punctuation,
your job is over. If it doesn't, you'll have to insert the space.
It's especially bad in QUED because you're likely to have inline comments
preceded by tabs. If you select the last word before the comment, you'll get
all the tabs, too, and have to re-enter them. A real pain.
The only time one could make a case for selecting the space is if you delete a
lot. It isn't relevant in QUED, but check the discussion in the User Interface
chapter of IM on intelligent Cut & Paste.
------------------------------
From: PEABO (521)
Subject: RE: editor features (Re: Msg 515)
Date: 8-AUG-01:05: Tools for Developers
Doesn't MS-WORD select the space after the word on a double-click? It's been a
little while since I did any major editing in WORD, so I have forgotten, but it
is a pain to recreate the space after.
peter
------------------------------
From: CHUQ (522)
Subject: RE: editor features (Re: Msg 521)
Date: 8-AUG-01:59: Tools for Developers
Yes, WORD does select the space on double click, if there is no competing
punctuation to stop it. This makes perfect sense in a word processor, and it
keeps me from going insane when I'm trying to write. It'd drive me buggy if I
was programming, though. Fortunately, I don't use WORD to do programs.
chuq
------------------------------
From: DDUNHAM (537)
Subject: RE: editor features (Re: Msg 521)
Date: 9-AUG-00:12: Tools for Developers
If so, yet another reason I don't use Word. PageMaker also does it, and it
really annoys me (luckily I don't do a lot of text editing in PageMaker [I have
other things I want to do, too :-)]).
------------------------------
From: DDUNHAM (538)
Subject: RE: editor features (Re: Msg 522)
Date: 9-AUG-00:12: Tools for Developers
So you delete more than you retype? Getting the space drives me up
the wall equally in PageMaker and QUED. Especially since two of the
programs I use most are Acta and miniWRITER, which use TextEdit, which
does not select whitespace. I think this (the fact that the ROM
doesn't) is the single most important reason why Word et al are
_wrong_.
------------------------------
From: MACINTOUCH (11427)
Subject: RE: Ruggedized MacIntosh
Date: 8-AUG-09:53: Network Digests
To:Peggy_B._Thomas.OsbuSouth"@Xerox.COM
Subject: Ruggedized MacIntosh
There was a re-packaged Macintosh sold by a company called "Colby" some time
ago. I don't know if it's still being sold, but it might be a more rugged
Mac than Apple's. There is also a discussion here on Delphi about military
"Tempest" Macs.
Ric
------------------------------
From: HALL (11394)
Subject: LightSpeed C vs. TML Pascal
Date: 8-AUG-00:24: Programming
I've been considering buying a development system, and the choice is between
LightSpeed C and TML Pascal (version 2.0, of course). The question is, which is
best overall? How do they compare in ease of use, development time, code
efficiency, (Well, you get the idea)....
Brian
------------------------------
From: PEABO (11396)
Subject: RE: LightSpeed C vs. TML Pascal (Re: Msg 11394)
Date: 8-AUG-00:45: Programming
I'd take a look at Lightspeed Pascal. (That's PASCAL, not C).
Usually people choose their langauge before their development system.
If you don't care whether you are using C or Pascal, you probably
haven't used them enough to develop a preference yet. (My opinion.)
So rather than compare Lightspeed C vs. TML Pascal, I would think
you'd want to compare Lightspeed Pascal vs. TML Pascal, or Lightspeed
C vs. some other C compiler, after figuring out which langauge you
feel best with.
peter
------------------------------
From: PEABO (11395)
Subject: RE: Best 'C'? (Re: Msg 11385)
Date: 8-AUG-00:40: Programming
Quickest and easiest for development: LightspeedC wins this one hands down.
Most powerful? Well, LightspeedC is not bad, but there are other
excellent C compilers, including MANX, Megamax, and Consulair (though
people are opinionated about all of these). A rising star of the
horizon is the Apple Macintosh Programmer's Workshop (MPW) which will
be available soon and which uses Greenhills C. We don't yet have a
definitive answer on how good the code is coming out of the MPW C.
peter
------------------------------
From: CHUQ (11400)
Subject: RE: Best 'C'? (Re: Msg 11385)
Date: 8-AUG-01:52: Programming
I bought Mac C 1.0 centuries ago. I upgraded it to 1.5, then to 4.0. I loved
it. If you want to do it, Mac C can do it for you. Last week, I threw it off
my disks and bought LightSpeed C.
Why? I'm in lust. Mac C is a workhorse. It makes few assumptions,
and does the job real nice. It is expensive as hell. HFS upgrade
would have cost me about half as much as buying LightSpeed C cost, and
Consulair seems to upgrade about three times a year. That gets
expensive...
Also, Mac C is NOT INTEGRATED. You load the editor. You edit. You save. You
transfer to the C compiler. You compile. Maybe you transfer to the linker and
link. You transfer to the program. It bombs. You start the editor. Iterate
infinitely. Starting and exiting programs, even with transfer menus that skip
the finder, is slow, pronounced mindbugging.
Exec sucks. Even MDS make doesn't really help like it should. If all you want
is a Unix style environment that runs likka dog, Mac C is fine).
LightSpeed, you boot the program. You open files, edit them. You hit
command- m. It makes everything you changed. It remembers which
include files go with which programs, and remake everything you need.
You hit command-r. It links and transfers, testing the program. When
you are done, you're back in LSC. The compiler is FAST. I mean,
we're talking blink and you miss it. The linking is pretty much
non-existant, although I'm hacking my way through a port of Hack from
Unix and with something like 25,000+ lines of code in 30 some files,
even LSC slows down. Imagine that in Mac C, though.
For all this wonderfulness, you DO give up some things. You can't add
random utilities. You can't choose your own editor (no big deal, I vi
at work and I use Mac Word the rest of the time, so the editor doesn't
bother me). It doesn't have HFS support yet officially, but I guess
it is around here somewhere as a project.
You also pay $130 instead of $400 for the silly thing.
It isn't the compiler with the most brawn, but it is the single most productive
thing to hit the Mac market to date. I can hack things together so much faster
it isn't possible to explain it in ways that don't sound like marketing hype.
I Like LSC, if that weren't obvious.
About Apple's MPW, two things that I'm probably not supposed to know,
from people beating on it. The code generation for the C compiler is
supposed to be astounding -- Greenhills is a first class compiler
house, from personal experience on big machines. Second, the sucker
is aimed at professional developers, and will have every bell and
whistle tyou could imagine, and then some. You'll pay for it, though
-- Mac C may well be a down payment for MPW when they are through.
Some people I know who have been working with MPW say it will blow
away everything you've ever seen, including LSC -- they should know,
they wrote a best selling C book for the Mac. If you're willing to
put out the bucks, wait for MPW, coming this fall, last I heard.
If not, buy LightSpeed, and hope they bring out their own object interface one
of these minutes, or grab a package like Transkel. Object Pascal is going to
make programming the Mac fun again, at least for Pascal programmers.
chuq
------------------------------
From: PEABO (11429)
Subject: RE: Best 'C'? (Re: Msg 11400)
Date: 8-AUG-10:05: Programming
Unless MPW C bankrupts me, I am hoping to get the best of both worlds
by using LSC as a fast development tool, and then using MPW C for the
"last compile" <grinning>. It has been a myth of choice for computer
programmers for centuries that the way to go is a fast compiler for
development and a heavy duty optimizer for production ...
peter
------------------------------
From: MCOHEN (11449)
Subject: RE: Best 'C'? (Re: Msg 11400)
Date: 8-AUG-18:48: Programming
I'm also using Consulair C now (currently V4.5) and I've been thinking
about switching to Lightspeed C *BUT* it has one fatal flaw (at least
as far as I'm concerned): you can't use inline assembler or integrate
assembler modules easily (I've heard their RelConvert program chokes
on Mac C format REL files). I'm currently working with a MIDI driver
and lots of low-level stuff which can't be done easily in C. Also, I
just bought MacExpress in Consulair C format. Does Lightspeed intend
to support assembly language in the future? If they do, I will switch.
- Mike
------------------------------
From: PEABO (11455)
Subject: RE: Best 'C'? (Re: Msg 11449)
Date: 8-AUG-20:06: Programming
There is a rumor floating around about a September upgrade that includes
assembly langauge. ALSO, a rumor floating around about an enhanced TMON with
hooks into several popular compilers (to get info about the symbolic names of
procedure locals) due Real Soon Now. We'll keep an eye out this week at the
show for such goodies!
peter
------------------------------
From: VINDICATOR (11461)
Subject: RE: Best 'C'? (Re: Msg 11455)
Date: 8-AUG-21:01: Programming
I love Lightspeed, but before that I used Megamax a lot, and I still
think it's an excellent package. The new upgrade to 3.0 supports HFS,
etc., so if you don't want to buy Lightspeed (which you should) and if
you want assembly support, I'd try Megamax. It's also cheaper than Mac
C, but then, what isn't?
------------------------------
From: JEFFS (11469)
Subject: RE: Best 'C'? (Re: Msg 11461)
Date: 8-AUG-21:46: Programming
But have you *seen* the upgrade? I haven't and I sent in my disks way back in
March!
Jeff
------------------------------
From: JOSEF (11486)
Subject: RE: Best 'C'? (Re: Msg 11449)
Date: 9-AUG-01:52: Programming
I've used LSC's RelConvert to convert Mac C .rel files with no problems
whatsoever. Would be interested in knowing what kind of problems you have heard
about.
Joe
------------------------------
From: MOUSEKETEER (11459)
Subject: RE: LW Cartridges
Date: 8-AUG-20:28: Programming
I hadn't heard of any carts being filled to less than capacity...and
not getting at least 2000 sheets through would be very strange, I
think (unless the sheets have a tremendous amount of black in them,
which could eat toner at a very advanced rate....try black paper and
do the drawing in white...grin).
Maybe someone who has been through more carts than I has other experiences?
Alf
NOTE NOTE NOTE: The new Macworld has a letter from someone discussing how to
arrange your sheets from WORD in the Laserwriter to print on both sides. FROM
ASKING QUESTIONS ABOUT, THIS IS BAD MOJO!
The Canon engine is rated at around a 10% duty cycle for double-sided copies,
but no-problem printing requires more like 5%, or preferably none at all. If
you need stuff done double-sided, take it to a copy shop and use their Kodak.
------------------------------
From: MACINTOUCH (11499)
Subject: RE: LW Cartridges
Date: 9-AUG-08:28: Programming
Hey, what's the scoop?! I've been running double-sided almost
continually to save money on paper. I had real minor thoughts about
problems, but haven't encountered any. What _exactly_ happens in this
mode that doesn't in the other? (No, Rick, we _can't_ buy a copier!)
Ric
------------------------------
From: MACMAG (11450)
Subject: RE: Cricket Draw (Re: Msg 11249)
Date: 8-AUG-19:33: Business Mac
Although I haven't seen the program, someone here bought it and says it's the
best "plotter" program you can buy today. (aka. Cricket Draw)
RICH.
------------------------------
From: OPPENHEIM (11457)
Subject: packet radio
Date: 8-AUG-20:17: Hardware & Peripherals
Since the Zilog SCC chip is used in some amateur packet controllers
for SDLC communications, has anyone done anything to harness the Mac
for this task? Another coup for the Mac, with all the drones slaving
to make the PC do the work in software.
------------------------------
From: YVES (11466)
Subject: RE: 9600 baud terminal emulator (Re: Msg 11381)
Date: 8-AUG-21:18: Telecommunicating
Yes, you're right: the big screens just have a new Bitmap definition
(address, rowbytes and rectangle). Unfortunately I had to use some
very tricky programming to become that fast and that meant assuming
the size of the screen. However, when Apple comes out with a new size
of screen, I will modify the programs to be compatible with both
(people with MegaScreens STILL have the standard screen if they don't
boot the special disk). This until the Mac becomes fast enough to
handle 19200 baud by itself (I'm thinking 68020). At that time, any
terminal program will do... -- Yves
------------------------------
From: RICKLEPAGE (11472)
Subject: RE: Cricket Draw (Re: Msg 11450)
Date: 8-AUG-22:37: Business Mac
this is an entirely different program -- Cricket Graph is the graphing program.
Cricket Draw wont even be shown officially till the expo and won't be sold till
at least the end of the year.
Rick
------------------------------
From: DDUNHAM (11479)
Subject: RE: Public Domain Software Request
Date: 9-AUG-00:05: Network Digests
>From: binde@topaz.rutgers.edu (Beth Binde)
>Subject: Public Domain Software Request
miniWRITER is not a public domain word processor (I don't know of any --
MacWrite is NOT), but it is a shareware text processor. It is the only such
desk accessory which supports Undo. You can contact us about a site license (
the shareware fee is normally $12) :
Maitreya Design
POB 1480
Goleta, CA 93118
805/968-7578 (do NOT call before noon Pacific)
Good luck trying to find free software...I think you're going to need it.
------------------------------
From: LOFTUSBECKER (542)
Subject: Very Weird Problem
Date: 9-AUG-02:42: Programming Techniques
All right, this is a real mystery to me. Anyone have any ideas?
On my Mac (512K with new ROMs), I found out, moving the hex
number $28EFFFF to register A0 caused an immediate mouse freeze.
Some experimentation helped me determine (1) this doesn't happen when
the same number is moved to register D0 or A1 (I haven't tried all
registers); (2) it happens whether the number is loaded directly into
A0, or whether it is moved there from D0 or A1; and (3) in fact the
critical bit seems to be Bit 23 ($800000): just moving $800000 into
register A0 will cause the freeze.
I've done almost all my experimenting with TMON (but not all,
a little bit with the minidebugger in ROM). The mouse freeze happens
100% of the time in TMON, and I have duplicated it with the mini-
debugger (entering 207C 028E FFFF A9F4 into memory locations
following 0000 and then setting the program counter to 0 and telling
the little debugger to G will do it).
IS THIS COMMON TO ALL MACS? Or is there something strange,
very strange, about mine? Can anyone replicate the problem? Does
anyone have any idea what the hell is going on? Is it a bug in TMON?
(Very puzzled) -- Lofty.
------------------------------
End of Delphi Mac Digest
************************