HDTenEightyP/NetNews huggingface dataset:
From: MARX.PETER@AppleLink.Apple.COM (Marx, Peter,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: more ETO griping...
Date: 11 Jan 93 17:19:00 GMT
Organization: AppleLink Gateway

Ed -
 
Actually, I am old enough to remember both Microsoft and Borland producing
tools for Macintosh development. The Microsoft stuff wasn't all that wonderful
(it still isn't on the Windows platform) and Borland didn't have much success
competing with everyone else.
 
Just to really throw sand back at you, Symantec (actually, Think) is probably
more commonly used than Apple's tools.
 
I am not sure where you are coming from with your "disagreements." And I don't
see the anti-trust issues. I do see some foolishness, though.
 
Finally, regarding your last comment - "People need to stop complaining about
what Apple doesn't do, and simply do it themselves" - you CANNOT possibly mean
that all of us need to go out and write our own quirky class libraries and
development tools...?!
From: NAVARRETE@AppleLink.Apple.COM (Navarrete, Ed)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: Takeover - QA
Date: 4 Jan 93 21:43:00 GMT
Organization: AppleLink Gateway

Dave,
 
I agree with Jesse and Bern.  A problem we have in DTS is when developers
report bugs which are NOT MacApp bugs.  A huge effort is taken to verify each
one of these.
 
Also Apple DOES have a team working to solve some of these problems.  For
example the Open Bugs Doc & Archives on E.T.O. 9.  These documents take a chunk
of man hours to maintain.
 
I would also love to see a rev of MacApp.  Would this rev contain crasher ONLY
(These tend not be easy cosmetic bugs fixes like some bugs in TEditText) or
maybe just fix the easy ones (who defines easy).
 
Ed Navarrete/DTS
Apple Computer, Inc.
 
Newsgroups: comp.sys.mac.oop.macapp3
From: Chris_Knepper@taligent.com (Chris Knepper)
Subject: Component Workshop
Followup-To: comp.sys.mac.oop.macapp3
Organization: Taligent, Inc.
Date: Thu, 7 Jan 1993 22:20:55 GMT

Anyone know what the system requirements are for CW 1.0?

Ram requirements? disk size? processor?

Also, are the generated applications compatible with Sys 6?

-Chris

+-------------------------+
| Chris Knepper           | Internet: chris_knepper@taligent.com
| Taligent, Inc.          | Phone: (408) 974-7344
| 10355 N. DeAnza Blvd.   | CIS: 76347,1757
| Cupertino, CA  95014    +
+ The ideas expressed herein are mine, mine, mine!
From: COMPONENT@AppleLink.Apple.COM (Component Software, S Ballard,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: COMPONENT SOFTWARE intos
Date: 4 Jan 93 17:35:00 GMT
Organization: AppleLink Gateway

Attn:
Attn:
SentBy: Jennifer Johnson
 
Regarding:                    COMPONENT SOFTWARE intos Component Proponent_
Component Software Corporation introduces the
 Component Proponent Program
 
We are looking for a few good Mac programmers to join our new Component
Proponent Program. Use the fastest development environment available to drive
new business for your consulting company and help us create add-on components,
tools, and sample code. We'll even help you sell your Components to other
Component Workshop(tm) developers worldwide so you can earn some money. After
all, your success is our success.
 
Here's how it works. You get
 
o a single-user license for Component Workshop at a greatly reduced price -
$495 (that's 80% off the list price of $2,495) and unlimited access to our
Bulletin Board System for technical tips, threads with other developers and
file-in's for minor bug fixes.
 
o 120 days of FREE maintenance and significant discounts off annual
maintenance contracts, training, add-on products and upgrades. (You need to
build either sample code or a Component for the BBS within 120 days to qualify
for further discounts).
 
o special access to our Bulletin Board for marketing your Components.
 
Component Workshop is the first "OBJECTS ONLY" dynamic development environment
based on C++. We take the definition of object-oriented programming seriously
and deliver maintainable, easily ported, easy to extend applications which are
built out of reusable parts. Incremental compilation, garbage collection, and
an application framwork ensure that you will develop applications faster than
ever before.
 
Component Workshop is based on C++ and uses a subset of the AT&T's 2.1 C++
standard. You may give up some C++ syntax, but you get back your weekends and
will earn a reputation as someone who delivers NEW APPLICATIONS early -
instead of promises for next year.
 
If you'd like to rapidly grow your business and make a little cash building
reusable Components, join us NOW and start using the most talked about new
development environment available. Call us today at 617/862-9700 and say "I
want to be a Component Proponent!" three times fast.
 
Please note:  COMPONENT WORKSHOP requires a Macintosh IIci or better with a
MC68030 or x040 processor running at 33MHz, System 7, a M68881 floating point
coprocessor, at least 25 Mbytes of hard disk space and 16 Mbytes of physical
memory (20 Mbytes are recommended) and MPW C(tm) for development.
 
These prices are valid in the U.S. only and do not include shipping charges.
 
 
Newsgroups: comp.sys.mac.oop.macapp3
From: mikey@wicat.com (Michael D. Rossetti)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: ETO Griping, Not Real issue
Date: 12 Jan 93 15:37:12 GMT
Organization: Jostens Learning Corporation
X-Useragent: Nuntius v1.1

ETO & MacApp Friends,

I think ETO has been a good value and I like the MPW environment very
much.  I really don't think there's better development environment
around.  Certainly not in the PC/Windows world.  The integration of tools
is as good as can be found in UNIX.  New tools are easy to incorporate. 
The scripting beats anything else I've ever seen and I, personally, would
never use Component Workshop if it took away my MPW scripting.  (I would
like to see AppleScript built into development products as soon as
possible, though; which, if Component Workshop supported, might actually
reduce the need for MPW.)  SADE is scriptable, too, and after one figures
out how it works it becomes a mighty fine tool.  Blah.  Blah.

ETO, as a subscription service is a good deal; a little steep on the
sign-up side but very reasonable on the annual fee.  Who else provides
such a plethora of choices and tools?  Not Borland, Microsoft or
Symantec.  Why their early developer programs for just one new technology
usually costs as much as the annual ETO subscription fee.

Of course we are all anxious about the upcoming changes in the
development tools vis-a-vis Bedrock, PowerPC, Newton, etc.  None of us
know whether these environments are going to be supported by ETO and a
statement from Apple clarifying the situation would be nice.  

In lieu of such a commitment it is human nature to expect the worst. 
What's the worst?  "Apple announces a new or several new ETO-like
programs for each intended environment the cost of which will likely put
the opportunity to develop for any or all environments out of range. 
And!  None of the environments are consistent with each other."

And I believe it's true that there's trouble in River City.  I have
personal knowledge that this uncertainty has caused a number of Macintosh
developers to switch their efforts to Windows.  Apple used to be renown
for their open communication with developers; they knew developers were
key to their success.  I'm beginning to wonder if they understand how
important their developers still are.

So what's my point?  It's not ETO that's flawed.  It's the whole Apple
'thing' that's in question.

When will we know what to really expect?  Probably not before the WWDC in
May.  I urge those who care to go to the various feedback sessions with
some emphasis on the very last session of the conference: "Fry the VPs"
and make specific comments and ask direct questions.

These are my personal opinions only.

Michael D. Rossetti                Internet:       mikey@wicat.com
Jostens Learning Corporation       AppleLink:      WICAT
WICAT Division                     CompuServe:     71102,475
1875 South State Street            America OnLine: ROSSETTI
Orem, Utah  84059-0539  USA        (801) 223-3285
From: JWBAXTER@HALCYON.HALCYON.COM
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Component Workshop
Date: 8 Jan 93 07:40:00 GMT
Organization: AppleLink Gateway

From: jwbaxter@halcyon.halcyon.com
To: KNEE@NETCOM.COM
Cc: MACAPP3TECH$@applelink.apple.com
 
Mark,
   I suspect Think C would be fine for compiling extruded applications.
But...at least for now...if you want to write C routines for inclusion with
your code, in the environment, you need MPW C.  You actually link your code
into their startup application.
 
Chris, et al,
   I run Component Workshop on a 20 meg IIci.  Since I like to be able to
run other stuff, too (like ResEdit, or whatever), and since I have become
dependent on having Frontier (Eddy award and all) running most of the time,
I run 20 meg real memory, 26 or 27 meg virtual (depending on how much room
is available on the hard disk at the time).  In steady state, no paging
goes on in that configuration.
 
   Speed is not overwhelming...I may finally be "forced" to give my IIci a
cache card.
 
   Hardware floating point is required (or a software emulation, third
party, thereof).
 
   I like it.
   --John
 
--------------
John W. Baxter   jwbaxter@halcyon.com   [BAXTER.JOHN on AppleLink, from
AppleLink only.]
From: AHMANN@AppleLink.Apple.COM (IDS Financial Svcs, D Ahmann,SDA,AM)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Help, TTearOffMenuView
Date: 11 Jan 93 19:43:00 GMT
Organization: AppleLink Gateway

Hello,
I need some help with the UMenuView and UTearOffMenuView units. I've created a
subclass of TTearOffMenuView with several subviews. The menu is showing and
tearing off, and is the correct size, but none of the subviews are drawn. Could
someone explain the process of creating a tear off palette, or at least point
me to where it is documented a little better than the header files. The problem
seems to be with the view not thinking it is visible. GetDrawableQDRect keeps
returning an empty rectangle. I know I'm just missing something simple, so any
help from someone who has done it would be greatly appreciated.
 
Thanks,
Doug Ahmann
IDS Financial Services, Inc.
 
Newsgroups: comp.sys.mac.oop.macapp3
From: nagle@netcom.com (John Nagle)
Subject: Re: Total Chaos
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Sat, 9 Jan 1993 18:35:02 GMT

ksand@apple.com (Kent Sandvik ) writes:
>The PowerPC chip will be used for personal, office level computers by
>Apple, and in high end workstations by IBM. This is a nice and clear
>separation, and it's actually a win-win situation for both parts.

       There is no such 'clear separation'.  Sun workstations now start
at prices well below high-end Macs.  If there is a real separation in
future, it's going to be between portables and desktop machines.
It's a classic IBM ploy to try to make such distinctions stick by
marketing means and by crippling the low-end machines.  When I hear something
like the above, I expect to see "low end" machines crippled by limited
expansion capability.  

>PowerOpen is for the 'Open Systems People', while MacOS for PowerPC
>is for the rest of us :-). Another win-win, if you think open systems
>is the way to go, go for PowerOpen. If you like the MacOS environment,
>you got it.

        Using software emulation.  Right.  As Kent has previously admitted,
the new machines will run the Mac OS in a software emulator, something like
Soft PC, and the "real PowerPC environment" will have a different 
API and GUI.  Sounds like A/UX.

        It's sad.  If Apple had come out with a protected-mode MacOS with
multiprocessor support (difficult, but possible) kicked Motorola into 
building faster M68xxx CPUs and saturated the educational market with 
low-end Macs equipped with built-in CD-ROM drives, Apple could have 
retained its leadership position.  But, with top management choosing a 
"strategic alliance" with IBM, a classic tar pit, as Apple's future, one can 
only expect decline.
 
					John Nagle
From: ERIC_BERDAHL@TALIGENT.COM
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: pure virtual member func
Date: 11 Jan 93 13:05:00 GMT
Organization: AppleLink Gateway

From: "Eric Berdahl" <Eric_Berdahl@taligent.com>
To: SANTADOG@ISYS.KING.AC.UK,
     "MacApp 3 Technical Discussion" <MACAPP3TECH$@AppleLink.Apple.COM>
 
        Reply to:   RE>pure virtual member functio
Hmm, there seems to be a simple problem, but I can't tell exactly which one i
s biting you.
 
There are two TIPCommand classes in the FotomatApp package. The one in FotoAp
p inherits from TServerCommand. The one in AEImage inherits from TClientComma
nd. They are not interchangable. From your citation of TIPCommand, I assume t
hat you are trying to compile AEImage. However, DoImageProcessing is a method
 of FotoApp's TIPCommand class, so obviously the compiler is seeing that class.
 
Is a puzzlement, said the King.
 
I would suggest getting the latest version of FotoApp, which has been revved
to fix some problems in older versions, one of which (I think) is the one you
're seeing. In early versions of FotoApp, I made DoImageProcessing pure virtu
al so C++ developers could get compile-time checking that they have implement
ed this method. I also gave it an implementation that would call SubClassResp
onsibility at runtime so Object Pascal developers would get checking too. As
newer compilers came online, that needed to be revved for the error you see.
 
The latest version of FotomatApp should be dated something like April, 1992,
and I think its in the MacApp3Tech$ archives (on ETO and AppleLink).
 
Hope this helps,
Eric
FotoApp author
eric_berdahl@taligent.com
From: DRAPER@ODIN.MDA.UTH.TMC.EDU
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Re2: more ETO griping...
Date: 11 Jan 93 20:58:00 GMT
Organization: AppleLink Gateway

Peter,
 
>Actually, I am old enough to remember both Microsoft and Borland producing
>tools for Macintosh development.
 
I think it takes a great leap of the imagination to consider Microsoft's
entries as *development tools*.  QuickBASIC != QuickC | C version 5.x.
Borland's implementation of TurboPascal was fairly popular among many of my
friends in its day.  But, it was almost abandoned from the beginning by
Borland.  Was it ever a *development tool*?  Where is TurboC++?  What about
it's class library?  What about debuggers?  Where are the real _TOOLS_.
 
>Just to really throw sand back at you, Symantec (actually, Think) is probably
>more commonly used than Apple's tools.
 
So?
 
>I am not sure where you are coming from with your "disagreements." And I don't
>see the anti-trust issues. I do see some foolishness, though.
 
The only thing I disagree with is this statement:
 
>I just wonder why Apple doesn't put EVERYTHING into a subscription service
>(e.g. a high-end Partner program) and COMMIT to making everything available
>there. I don't understand why Apple doesn't see this in their interest. To m
ake
>themselves dependent upon third parties for the development tools is rather
>foolish in my opinion. Why did they do MacApp to begin with?!
 
Why?  I think it's time that Apple started backing off. I think its time to
let other developers besides Symantec into the fray.  I don't think it's
foolish for Apple to allow others to become part of a "total solution" for
the developer.  That so called "dependance" can also be called
"opportunity" for third parties.  Third party success in a stagnant market
such as development tools is necessary for Apple to develop market share.
For the small amount they're giving up, they are creating valuable
opportunities for third parties.
 
 
>Finally, regarding your last comment - "People need to stop complaining about
>what Apple doesn't do, and simply do it themselves" - you CANNOT possibly mean
>that all of us need to go out and write our own quirky class libraries and
>development tools...?!
>
No I don't.  I meant the developer community as a whole producing tools for
itself, rather than waiting for Apple to get around to it for them.
 
 
      |E|J-  ED DRAPER
 rEpar|D|<-  Radiologic/Pathologic Institute
             The University of Texas M.D. Anderson Cancer Center
             draper@odin.mda.uth.tmc.edu
From: JWBAXTER@HALCYON.HALCYON.COM
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Total Chaos
Date: 11 Jan 93 08:11:00 GMT
Organization: AppleLink Gateway

From: jwbaxter@halcyon.halcyon.com
To: MACAPP3TECH$@applelink.apple.com
 
John,
   Emulation isn't necessarily going to produce slow running of Mac OS
applications on the new hardware.  I've seen instances in the past in which
such emulations on new hardware ran faster than the old machines did (NCR
315 emulated on the Criterion, as one example).  In this case, we have a
situation where a typical Mac OS application spends considerable time in
the toolbox routines.  The key ones of those can be (and, it is said, will
be) recoded in native code, giving a boost.
 
   On top of that, the 68000 is an emulator, anyhow.  The visible
instruction set is emulated by the microcode.  Shortly after the chip came
out, both NCR and IBM took a long look at re-microcoding it to run their
mainframe instruction sets (Criterion and 370).  Both concluded that there
wasn't quite enough silicon available (there was another problem...the
microcode was a one-man show, he was gone, and the "source" was only
slightly more organized than Woz's notes on the Apple ][ ROM).
 
   I don't know whether the 68020, 30, and 40 are also microcoded, or not.
 
   We won't know whether Mac OS running on the new machines is bad or not
until we see it.
 
--------------
John W. Baxter   jwbaxter@halcyon.com   [BAXTER.JOHN on AppleLink, from
AppleLink only.]
From: DRAPER@ODIN.MDA.UTH.TMC.EDU
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Quality of CW's Class Library
Date: 8 Jan 93 14:53:00 GMT
Organization: AppleLink Gateway

class library?
 
Is the architecture sound?
 
 
 
 
 
      |E|J-  ED DRAPER
 rEpar|D|<-  Radiologic/Pathologic Institute
             The University of Texas M.D. Anderson Cancer Center
             draper@odin.mda.uth.tmc.edu
From: ALGER@AppleLink.Apple.COM (Alger, Jeff,VCA)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re2: MA - Takeover or Death
Date: 7 Jan 93 17:48:00 GMT
Organization: AppleLink Gateway

Group,
 
I have a specific proposal that, though modest, is at least doable within the
confines of MADA's and everyone else's limitations.
 
1. In every issue of Frameworks print have a regular feature listing previously
unreported bugs in MacApp and suggested fixes or workarounds.  Also, summarize
(in very fine type) all previously reported bugs and indicate where to find the
fixes/workarounds, which leads to
 
2. MADA providing the complete set on every Frameworks diskette (thereby also
increasing the value of that electronic publication) and
 
3. The complete set should also be maintained on-line on an AppleLink
discussion board.
 
No one need make any representations and everyone is free to use or not use any
given fix or workaround.
 
This is NOT a solution to the overall QA/support issue, but it is a halfway
measure that could meet the needs of a large segment of the MacApp community
for little cost.  All it requires is someone volunteering to do the compilation
and posting.
 
Regards,
Jeff Alger
SBM International
From: GER.XSE0096@AppleLink.Apple.COM (Germany - Ciechowski Computer,IDV)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: ETO-expensive,toothless,ob
Date: 11 Jan 93 05:28:00 GMT
Organization: AppleLink Gateway

Peter,
 
 
you're absolutely right. In addition for a German developer there's still the
point left that we do not get an ETO when it becomes available but (in most
cases) about a month later.
 
I would at least delay the beginning of my next subscription.
 
 
Ingo Ciechowski
From: ksand@apple.com (Kent Sandvik )
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Link error
Date: 9 Jan 93 02:15:40 GMT
Followup-To: comp.sys.mac.oop.macapp3
Organization: (Evil Eye Creature from Mars, Inc.)

In article <726507650.6932436@AppleLink.Apple.COM>,
REDDEN@AppleLink.Apple.COM (Redden, Kevin) wrote:
> The problem with your third trial is probably that you did not use the
> -autobuild option to rebuild all of MacApp with -ModelFar on.

Before using Model far, try with the link -srtsg flag, that might do it!

Kent
-------------------
Kent Sandvik (UUCP: ....!apple!ksand; INTERNET: ksand@apple.com)
DISCLAIMER: Private activities on the Net.		
Predictions: Soon moving to Newton DTS, bye bye.
From: D0220@AppleLink.Apple.COM (American Zettler, David Every,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Griping...
Date: 11 Jan 93 17:30:00 GMT
Organization: AppleLink Gateway


    I hear a lot of bitching & moaning about ETO... I personally would like to
see "more, better, faster, etc."... but Apple has made a commitment to
developers by even having an ETO... and Apple is attempting to keep us
developers up to date. Most companies I have worked with do NOT distribute
betas of development tools, and keep us at all informed of future developments
(look at Sumantic... they haven't even publicly admitted there will be a
ThinkC++, yet if there isn't what will bedrock be based on?)...
 
    Since the majority of development products supported by Apple are on ETO,
it would be a safe bet that apple will support bedrock (in leue of MacApp) on
ETO... MPW 3.3, Toolserver, SourceServer are still on ETO and being updated.
 
    I would like to see apple license more technology from third parties,
allowing apple to give better support to developers, while not punishing 3rd
party development tools. (Maybe see if they could add tools like Icepick or
ObjectMaster if those companies wanted to add thier products)...
 
    Dave Every.