HDTenEightyP/NetNews huggingface dataset:
From: DEWAELE.W@AppleLink.Apple.COM (De Waele Willy - Gent,BE,IHD)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: * Takeover Proposal *
Date: 26 Dec 92 00:31:00 GMT
Organization: AppleLink Gateway

Hi Robert and all MacApp 3.0 lovers,
 
Robert, receiving your link (on Xmas) is encouraging ...
 
> MADA could not undertake a project of that scope without a significant
increase ...
 
All is depending on the amount of a separate fee for the members subcribing the
MacApp upgrade.
IF (!) Apple will cease maintenance of MacApp, MADA is in the best position to
coordinate the bug fixes, submitted and tested by members.
Indeed we can submit implementation of new features also to MacApp.
The new versions of MacApp can be distributed on a CD (personally i will
subcribe!) or/and ETO (there are allmost no differences between ETO #8 and #9).
 
> So how can MacApp live on? It probably can't as the commercial framework that
it is today. But it would be a shame to let the technology wither and
die.
 
As i mention in my previous link, Apple should upgrade MacApp with bug fixes
and new features as QuickTime, OSL, AppleScript, QuickDraw GX ....
Indeed it would be a big shame if Apple will 'drag MacApp into Trash'!!!!
MacApp is very good and allmost complete, and used by a lot of developers.
BTW i have experimented a while with MS C++ 7.0. I added a lot of basic coding
to my subclasses to make it complete!
 
> This simple act would likely make MacApp the overnight favorite framework
among students and tiny developers.
> MacApp would become a learning tool for aspiring object-oriented Mac
programmers
 
A lot of students and developers (*tiny* and others) are developing without a
framework because working flexible with a framework, a fast Mac with minimum 16
Mb and a *huge* harddisk is a must, which means a *big* investment for a
student (plus the cost of subcribing the software).
MacApp (and other frameworks) aren't easy, it take some time (a few months?)
learning OOD, OOP and understanding the structure of the framework (where and
how to overwrite) by *browsing* the framework code.
BTW i learned a lot of *tricks* for my non-MacApp applications.
 
---
 
Something else to consider: what about the cost of
    - the conversion of a lot of MacApp applications
    - learning a new framework
    - fixing first version bugs
    - overhead of a multi-platform framework.
 
We know that Apple is reading these links, by sending links to the group is the
only way to convince Apple to keep MacApp as our favorite Mac framework.
 
I give my answer on Eric's title in one of the issues of FrameWorks 'Is MacApp
3.0 Dead?' No way, but it is still stagnant, and that is also a shame!!!!
 
Xmas (without snow) Regards
Willy
 
ps: still learning MacApp ...
From: RSD@AppleLink.Apple.COM (Research SW Design, D Goldman,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: No offense!
Date: 4 Jan 93 00:10:00 GMT
Organization: AppleLink Gateway

Just to forestall any misunderstandings...
 
Although my links lately have been rather down on Apple, I would not want any
of the Apple people who have actually worked on MacApp to be offended.
 
I think that MacApp is great, and that all of you, past and present, have done
a great job. I thank you personally, and only wish that your employer would
provide consistent and adequate support for your efforts, and learn the word
"commitment".
 
-- Dave Goldman
   Research Software Design
From: AARON@GAMMA.COM
Newsgroups: comp.sys.mac.oop.macapp3
Subject: PowerPC + MacApp future
Date: 28 Dec 92 22:04:00 GMT
Organization: AppleLink Gateway

From: aaron@gamma.com (Aaron Rosenbaum)
To: MacApp3Tech$@applelink.apple.com
 
Having seen emulation technology in action at WWDC (*not* under
non-disclosure) and having seen the tools available for porting, I
feel that my company will not be at a specific disadvantage with a
MacApp based program.  It really is quite good - not SoftPC like at
all.
 
Any performance disadvantage I have will be more than out weighed by
time-to-market.  No matter what productivity gains various frameworks
in beta might have, they can't beat 25K lines of code already
written!
 
Aaron Rosenbaum
Gamma inc.
From: D4133@AppleLink.Apple.COM (CSTech, Michael Swiercz,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Removal from Mailing List
Date: 27 Dec 92 21:53:00 GMT
Organization: AppleLink Gateway

I would like to be removed from the MacApp3Tech$ and MacApp2Tech$ mailing
lists. The frequency of mail is just too overwhelming and interfers with normal
business. I wouls rather view the messaged by downloading the archives.
 
Thank you,
Michael Wil. Swiercz
From: WVUCENIC@AppleLink.Apple.COM (No Bugs SW, Wayne Vucenic,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: Bedrock News
Date: 22 Dec 92 16:58:00 GMT
Organization: AppleLink Gateway

Harry,
 
> Does anyone know who at Apple or Symantec is involved with establishing
> licensing strategies for Bedrock? An e-mail address would be great.
 
I think the appropriate person would be Steve Levine, the Bedrock Product
Marketing Manager at Symantec.  His AppleLink address is LEVINE.STEVE
 
Wayne
From: ALGER@AppleLink.Apple.COM (Alger, Jeff,VCA)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Performance tests...
Date: 28 Dec 92 18:15:00 GMT
Organization: AppleLink Gateway

Richard,
 
Sigh.  I wish this old saw about OOP performance would just go away.  Here is
the truth:
 
1. OOP programs are considerably smaller than non-OOP programs (1/4 to 1/10,
depending on whose study you read).  In addition to direct performance
benefits (i.e., less swapping) this means it is easier to get your mind around
the entire program.  The result is usually better algorithms, which will always
swamp any language-derived factor.
 
2. OOP languages allow a compiler, carefully crafted and optimized, to handle
this sort of logic (please excuse me dropping into C rather than Pascal):
 
switch (aBlob->fType) {
case kTypeA: ...
case kTypeB: ...
...
}
 
Anyone ever look at the code produced by your average C or Pascal compiler for
this sort of conditional logic?  It isn't pretty and it also isn't fast.  Yet
this sort of branching is all over the place in procedural code.  A compiler
will almost always do better than a programmer in such circumstances.  Put
another way, in large part OOP compilers take on the task of writing code you
yourself would otherwise have to write but they do it FASTER and SMALLER, not
slower and bigger.
 
3. If you really want speed, use C++, not Pascal.  I'm not going to debate the
merits of the two languages here other than to note that Pascal's dispatching
scheme is more compact but slower.  One of the explicit design objectives of
C++ was to be as efficient as C unless you use polymorphism, and even then to
use the fastest dispatch scheme of all the major OOP approaches.  That is, you
can recast a C program as a C++ program with non-virtual methods and have
IDENTICAL performance characteristics but considerably better-structured code.
And if you use polymorphism, C++ will run at least as fast as anything else.
As an indication, the switch-case logic above would be dispatched with (I
think) two extra machine instructions per case compared to simple function
calls and many, many times faster than a real switch-case.
 
It is unfortunate that so many people in the MacApp community have been blinded
by MacApp's relative slowness and size (there are valid reasons for both, but
due to how much MacApp does) into thinking OOP generally is slow and big when
generally the opposite is true.
 
Regards,
Jeff Alger
SBM International
From: PARKS.W@AppleLink.Apple.COM (Parks, William,APD)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: DrawString in OffScreen
Date: 29 Dec 92 07:49:00 GMT
Organization: AppleLink Gateway

Hello
 
    I am trying to draw a resource picture, and have been having trouble with
DrawString("this text").
 
    I am using a offScreen GraphPortfor the initial drawing. Then I CopyBits
from one OffScreen graphPort to another with a open Picture. The line drawing
is transferred but not the DrawString calls. The picture with line drawing but
without the strings is saved.
 
    Both OffScreen Ports have the same size rects.
 
    Any ideas???
 
 
   GetPort(savePort);
   SetRect(theRect, 0, 4, 208, 248);
   this->ViewToQDRect(theRect, theQDRect);
   if(CreateOffscreenBitMap(&offscreen,&theQDRect))
   {
   SetPort(offscreen);
 
   PenSize(3,3);
 
   MoveTo(0,5);
   LineTo(205,5);
   MoveTo(0,244);
   LineTo(205,244);
 
   MoveTo(0,5);
   LineTo(0,244);
 
   MoveTo(205,5);
   LineTo(205,244);
 
   PenSize(1,1);
 
   TextFace(bold);
   TextFont(3);
   TextSize(9);
 
   MoveTo(14,18);
   DrawString("This is it here");
   //DrawString(fRTDocument->fWCellName[0]);   //Segs
   MoveTo(100,18);
   DrawString("0");//Percent
   MoveTo(115,18);
   DrawString("%");
   MoveTo(0,21);
   LineTo(207,21);
 
   if(CreateOffscreenBitMap(&offscreen2,&theQDRect))
   {
   //BMWindPic = NULL;
   BMWindPic = NULL;
   oldState = HGetState((Handle)BMWindPic);
   HNoPurge((Handle)BMWindPic);
   SetPort(offscreen2);
   BMWindPic = OpenPicture(theQDRect);
   CopyBits( offscreen->portBits, offscreen2->portBits, offscreen->portRect,
offscreen2->portRect, srcCopy, nil);
   ClosePicture();
   }
   DestroyOffscreenBitMap(offscreen);
   DestroyOffscreenBitMap(offscreen2);
 
   SetPort(savePort);
 
   //resPictName = "PictResFile";
   curResFileNum = CurResFile();
   UseResFile(curResFileNum);
 
   //Removes Old Resource Picture (The RT Chart Pict)
   tempPicHandle = GetPicture(kRTChartAppPict);
   FailNILResource((Handle)tempPicHandle); // was FailResError();
   oldTempState = HGetState((Handle)tempPicHandle);
   HNoPurge((Handle)tempPicHandle);//Locks handle
   RmveResource((Handle)tempPicHandle);
   HSetState((Handle)tempPicHandle, oldTempState); //UnLocks handle
   UpdateResFile(curResFileNum);
 
   //Writes New Resource Picture
   BMWindP = Handle(BMWindPic);
   AddResource(BMWindP, 'PICT', kRTChartAppPict, "screenPic");
   ChangedResource(BMWindP);
   WriteResource(BMWindP);
   UpdateResFile(curResFileNum);
 
   HSetState((Handle)BMWindPic, oldState);
 
Thanks,
  Bill Parks
From: GER.XSE0097@AppleLink.Apple.COM (Germany - Proficomp, M Greve,IDV)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Sourcebug error
Date: 3 Jan 93 17:01:00 GMT
Organization: AppleLink Gateway

Oh yes,
SourceBug's a nasty beast sometimes. It seems to be coupled with bad .sym/dump
files -- don't ask me how they get bad.
Everytime SourceBug does strange things to me, I throw away my complete object
folder and recompile. If this does not help, I throw it again in the trash,
along with _all_ MacApp objects, .syms and _.dump_ files and recompile again
(don't forget the dump files -- or you may need an additional recompile). I
personally think this is caused by this [censored] linker. Maybe there will be
a new set of development tools in the future -- 'til then, trash your
dumps'n'objects sometimes.
-Christoph
P.S: NO! No! I don't want to start another MPW Tools flame war!
From: DEWAELE.W@AppleLink.Apple.COM (De Waele Willy - Gent,BE,IHD)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Takeover Example
Date: 27 Dec 92 23:42:00 GMT
Organization: AppleLink Gateway

Hi Dave,
 
I'm complete agree with your scenario, i prefer 3b, because
    1. Apple is the owner of MacApp.
    2. Everyone who is subscribing the ETO receive new updatings as it should
       be.
 
But ...
    1. Will Apple support in the future MacApp? I don't have seen any official
       statement.
    2. Is MADA agree?
 
I think the best is we wait until after NewYear (there are a lot of people
taking holiday during year-end).
 
Regards
Willy
 
ps: WE (group) should do something about this!
From: ksand@apple.com (Kent Sandvik )
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Re2: * Takeover Proposal *
Date: 28 Dec 92 21:46:45 GMT
Followup-To: comp.sys.mac.oop.macapp3
Organization: (Evil Eye Creature from Mars, Inc.)

In article <1992Dec28.194659.21936@netcom.com>, nagle@netcom.com (John
Nagle) wrote:
> ksand@apple.com (Kent Sandvik ) writes:
> >Well, I've been involved with PowerPC for a long time, and the
> >platform will run existing binaries in emulation mode (quite well
> >and fast based on the current tests we've done), as well
> >as have a new native API that is a refinement of the current one so
> >there's not a lot of work concerning a port to PowerPC.
> 
>        Remember, Apple claims Mac PowerBooks will run DOS programs, with
> fine print at the bottom of the ad saying you need an emulation program
> such as Soft PC.  Performance is comparable to PCs of 1985 vintage.
> That's "emulation mode", as Apple markets it today.
> 
>        So Apple's strategy for the 90s is an all-new machine, an all-new
> application interface, and a "penalty box" (a la that of Microsoft Windows) 
> for running obsolete (old Mac) applications.  
> 
>        With a change that big, the user has to face a major conversion.
> So there's a choice: convert to Apple's new line, or convert to something
> else.  

I've been in this business for a long time, and one thing is sure,
if you release a new platform, forget any ideas today that you could 
start from a plain state. You need apps from day one, both new and
old ones. And that's the strategy with PowerPC, and I' still amazed
how well everything works, but just wait for the end result. Unfortunately
I'm not allowed to speak about the current environment, but I'm really
hyped. The end users will *not* see a big penalty in using PowerPC
concerned with the 68k Macs. Remember, we are selling stuff to home
and office use, and not to UNIX administrators :-).

This is the same story with Windows and other platforms, MSoft
tells developers to use the Win32 mode so stuff will run under NT.
I don't see any differences in our strategy. 

Anyway, wait and see before you start critisizing; this reminds
me of Republicans that are already complaining about the presidency
of Clinton :-).

Just another issue concerning food for thought. Does it really
make sense to speed up network connections, for instance? And 
what are the real bottlenecks of the Macintosh today?

Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.		
"Don't just do something!  Stand there!"  -- Mystery Science Theater 3000
From: SDOBBS@TRIVIA.COGINST.UWF.EDU
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Sourcebug error
Date: 1 Jan 93 03:36:00 GMT
Organization: AppleLink Gateway

I am trying to debug my code in SourceBug, and whenever I try to look at
some of my code, it shows me code from "fonts.h".  Has anyone else
encountered this before?
 
Steven Dobbs <sdobbs@ai.uwf.edu>
Institute For Human and Machine Cognition
University of West Florida
Pensacola, Florida
 
Man will occasionally stumble upon the truth, but most of the
time he will pick himself up and continue on.
From: RSD@AppleLink.Apple.COM (Research SW Design, D Goldman,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Takeover Example
Date: 27 Dec 92 21:20:00 GMT
Organization: AppleLink Gateway

Dear MacApp'ers --
 
Regarding my accompanying link ("TEditText Bug")...
 
I would speculate that this is a bug whose fix will:
 
(a) involve a very slight change to the MacApp code;
(b) easily be seen to not have distant side-effects;
(c) at best show up in an Apple bug doc, and that only if we're unexpectedly
lucky (Kent says he's being transfered to another engineering department!);
(d) belong in MacApp 3.0.2 (which there is no indication we will ever see Apple
create or distribute).
 
If Apple supported MacApp 3.0, then this is what would happen now:
(1) Apple confirms and repairs this very small and easy bug.
(2) The fix is made to MacApp 3.0.2, which is distributed on ETO #10.
 
Since Apple no longer supports MacApp 3.0 [Go ahead: prove me wrong! Follow
the above 2 steps.], let us suppose that MADA buys it. Then here is the
scenario:
 
(1) I, or someone else, figures out the fix and posts it here. One or two other
active MacApp'ers who could be personally affected by this bug check to confirm
that the fix looks right to them.
 
(2) MADA's hired, full-time (if necessary) MacApp maintainer examines the
proposed fix, and if all still agree that it looks okay, makes the change to
the MADA master copy of MacApp.
 
(3a) The revised MADA master is distributed on the next quarterly MADA MacApp
CD-ROM, to which those of us who are actively using MacApp have subscribed.
 
-or-
 
(3b) The revised MADA master is distributed on Apple's ETO #10. (Apple paying
part of our ETO subscription price [the part previously going to support MacApp
support] to MADA as a licensing fee.)
 
 
-- Dave Goldman
   Research Software Design
 
Newsgroups: comp.sys.mac.oop.macapp3
From: ksand@apple.com (Kent Sandvik )
Subject: Re: Re2: * Takeover Proposal *
Date: Mon, 28 Dec 1992 00:04:14 GMT
Organization: (Evil Eye Creature from Mars, Inc.)
Followup-To: comp.sys.mac.oop.macapp3

In article <1992Dec26.022347.9730@netcom.com>, nagle@netcom.com (John
Nagle) wrote:
>       It's almost as if Apple were killing off the Mac, like they
> killed off the Lisa.  Is Scully really betting the company on 
> Power PC, the "strategic alliance" with IBM, and "personal digital
> assistants"?  Some published interviews indicate that he is thinking
> along those lines.  

Well, I've been involved with PowerPC for a long time, and the
platform will run existing binaries in emulation mode (quite well
and fast based on the current tests we've done), as well
as have a new native API that is a refinement of the current one so
there's not a lot of work concerning a port to PowerPC.

I just wanted to tone down the idea that our switch to PowerPC will
somehow obsolete the current and future application base. In other
words expect the Mac to be alive for another 10-20 years or more.

Cheers,
Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.		
"Don't just do something!  Stand there!"  -- Mystery Science Theater 3000
From: WVUCENIC@AppleLink.Apple.COM (No Bugs SW, Wayne Vucenic,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: * Takeover Proposal *
Date: 21 Dec 92 18:31:00 GMT
Organization: AppleLink Gateway

Dave,
 
Your proposal sounds good to me, and I'd certainly be willing to pay a
reasonable amount to someone who would maintain MacApp.  (I think this could
probably be done with less than one full time person.)
 
> A LOT of the bug reports are trivial little fixes, with no worries about
> distant side-effects, so why should every MacApp developer always have to
> individually modify his/her MacApp source?
 
Absolutely!  As I read through the "Known Bugs" document, I kept getting
annoyed that, contrary to all of Apple's brave pronouncements along the lines
of "We'll continue to support MacApp until after everyone has migrated to
Bedrock", the reality is that Apple can't even manage to find a few days to
have someone apply these trivial fixes, so we won't all have to do it
individually.
 
Wayne Vucenic
No Bugs Software
"Mac Contract Programming in Silicon Valley since 1986"
From: NOR0154@AppleLink.Apple.COM (DATEC A/S,STORAS,NO,IVC)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re- Re- TPopup problem..
Date: 21 Dec 92 09:29:00 GMT
Organization: AppleLink Gateway

Attn: MacApp3 Technical Support
SentBy: Bjorn Olav Erland
 
Date   21-12-92
Subject    Re- Re- TPopup problem..
From   Bjorn Olav Erland
To MacApp3 Technical Support
 
                      Re: Re: TPopup problem..
Chris,
 
tanks for your help !
 
 I had copied the popup, and the id and the resource id did not match !
 
Bjorn
From: RSD@AppleLink.Apple.COM (Research SW Design, D Goldman,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: TEditText Bug
Date: 27 Dec 92 21:23:00 GMT
Organization: AppleLink Gateway

Dear MacApp'ers --
 
I've wasted enough time on this for tonight, so I'll invite any of you who have
dealt with this to help me...
 
It looks like our old friend the floating TEView is NEVER set to prefer outline
fonts. Even if in ViewEdit you have told the TEditText to "Prefer Outline
Fonts".
 
The result of this inconsistency: Make a TEditText field that uses 9-point
Geneva, and prefers outline fonts. Type something into this TEditText field
(or, more accurately, into its floating TEView). Move to another field, so that
the floating TEView goes away. (The text on the screen at this point is that
which the floating TEView drew, using a non-outline font.) Cover up part of the
TEditText field with some other window. Then uncover the TEditText field. Now
the TEditText object redraws the missing text, using an outline font. Since the
two versions of 9-point Geneva have slightly different metrics (at least on my
System 7.0 machine), the two parts of the text are noticeably out of alignment
with each other!
 
I would submit that this is a small bug in MacApp. In the accompanying link
("Takeover Example") I will use its fix (which is the part that I'm not going
to spend more time on tonight -- your suggestions or corrections are invited)
as an illustration of MacApp support/ownership issues.
 
-- Dave Goldman
   Research Software Design
 
P.S. The work-around for now, of course, is to go back to ViewEdit and uncheck
"Prefer Outline Fonts".
 
P.P.S. All right, I couldn't help myself! The fix should probably be to have
TEditText::InstallFloatingTEView set the floating TEView's fPreferOutline field
to this->fPreferOutline. (Perhaps TTEView should have a mutator method to do
this. At the moment you can only set TTEView::fPreferOutline via ViewEdit!)
From: RSD@AppleLink.Apple.COM (Research SW Design, D Goldman,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: TEditText P.S.
Date: 27 Dec 92 21:21:00 GMT
Organization: AppleLink Gateway

By the way, despite the occasional inquiry here, I've never seen an explanation
of the point of all this floating TEView business in the first place (as
opposed to having TEditText simply be a subclass of TTEView). The memory
savings per instantiation are small, but the increased code complexity is VERY
high.
 
[Since Apple actively supports MacApp 3.0, I look forward to any *current*
Apple MacApp engineer answering this question.]
 
 
-- Dave ("Sounding Particularly Cynical At 2 AM") Goldman
   Research Software Design
From: RSD@AppleLink.Apple.COM (Research SW Design, D Goldman,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Performance tests...
Date: 27 Dec 92 02:44:00 GMT
Organization: AppleLink Gateway

Richard --
 
It's really not an Either-Or situation.
 
There is no such thing as a "highly computational application" -- there are,
however, applications that include *pieces* that are highly computational.
 
This means that you can write your application in an OOP framework, and gain
all of the usual advantages of that. Then if you have some highly computational
sections to write, feel free to do them as straight Pascal or C (whichever
you're more comfortable with; performance differences usually relate more to
the efficiency of your particular compiler [and the cleverness of your
particular programmers] than to language choice). Many strictly computational
tasks will not benefit by an artificial recasting into an object-oriented
metaphor.
 
As long as you can plug in performance-critical modules written in straight C,
Pascal, assembler, or whatever, you should pick your framework on criteria
other than performance.
 
-- Dave Goldman
   Research Software Design