HDTenEightyP/NetNews huggingface dataset:
From: rpomeroy@aunext1.amd.com (Ron Pomeroy x(Coop))
Newsgroups: comp.sys.mac.advocacy
Subject: Re: Mac multitasking?
Date: 23 Dec 92 16:49:24 GMT
Reply-To: rpomeroy@aunext1.amd.com
Distribution: usa
Organization: Advanced Micro Devices, Inc.; Austin, Texas

In article <1992Dec21.081420.9450@cubetech.com> andrew@cubetech.com writes:
>>In article <kcn21p@rpi.edu> johnsd2@vccnw01.its.rpi.edu.its1 writes:
>>>In article 16157@cubetech.com, andrew@cubetech.com (Andrew Loewenstern)  
writes:
>>>>The kernel is as single object.  Following me so far?  You request
>>>>services by sending messages containing other objects (mainly mach
>>>>ports and threads).  When you request something from mach, say create
>>>>a new thread, you aren't just invoking a function call.  You are
>>>>creating a mach message and sending it to the kernel along with your
>>>>task object and the thread object you want to represent the new
>>>>thread.  The kernel creates the new thread and puts it into the thread
>>>>object.
>>>
>>>This doesn't look like it is object oriented, it looks like you
>>>are sticking objecty names on it. But see below...
>>>
>>>>This isn't like objects in the AppKit.  Objective-C objects are very
>>>>different from mach objects, and Objective-C messages are very
>>>>different from mach messages.
>>>
>>>How bout this: Mac applications are object oriented. They sit there
>>>and respond to messages sent to them from teh OS (or other apps);
>>>such as "mouse down" or "update window".
>>>
>>>Is that a valid characterization? If not, why not?
>>>
>>>>Additionally, you can augment the kernel with "loadable kernel
>>>>servers" that provide additional kernel services.  Again, you access
>>>>the services by sending messages to the kernel object.
>>>
>>>Hmmm.. how is this substatially different from saying that the MacOS
>>>recieves messages (in the form of trap calls); you can load packages
>>>which will do the same thing with added functionality.
>>
>>Yes, you could say that a Mac application is a single object to the
>>kernel.  I guess we could call parts of the Mac OS "object oriented."
>>The point I am trying to make is not "Mach is OO and thus is so much
>>better because Macintosh is not."  The point I'm trying to make is
>>that for the kernel it doesn't matter.  For things that you aren't
>>going to put into your app, it doesn't really matter.
>>
>>*******I have never, ever, heard a single argument as to why a
>>*kernel* that Larry Rosenstein would call "Object-Oriented" (i.e.
>>written in smalltalk or obj-c or whatever) is better, either in
>>functionality or usuability, to the user or the vast majority
>>application developers, than a modern kernel like Mach.*******
>>
>>If anyone here has valid arguments against this, please send me
>>E-MAIL.  I am going out of town tomorrow and I definitely don't want
>>to miss it.
>>


Me too.

"Oh how miss being able to subclass and instantiate the MachKernel class" ;-)  
:-) :-0

--
Ronald Pomeroy		[Objective-Cruntime: [Smalltalk runtime]];
Advanced Micro Devices	[self dream-on];
CAM Applications Group
rpomeroy@aunext1.amd.com (NeXTmail preferred)
From: ibhan@husc10.harvard.edu (Ishir Bhan)
Newsgroups: comp.sys.mac.advocacy
Subject: Re: illegal mac emulation
Date: 28 Dec 92 22:09:15 GMT

<CTLCC@CUNYVM.BITNET> writes:

>The bad part about emplant is that you use a copy of the roms and not the roms
>themselves. So most Amiga users are pirating the roms.  As for the Emplant.
>The price on it is about $250.00. It works with Amiga 2xxx,3xxx and 4xxx.
>It also works in color. So it is a threat.

Last I heard, it didn't work at all in color.  Have you got it working?
-- 
               -  Ishir Bhan -  ibhan@husc.harvard.edu  - 
                                     - - - 
           "The sky and the impossible explode..." -The Cure
Newsgroups: comp.sys.mac.advocacy
From: funches@plains (Ariel Funches)
Subject: Soft AT
Date: Wed, 30 Dec 1992 09:07:34 GMT
Organization: North Dakota Higher Education Computing Network
X-Newsreader: Tin 1.1 PL4


Does anyone have the _demo_ version of Soft AT from
sumex-aim.stanford.edu? drop me a line, please

-Ariel
Newsgroups: comp.sys.mac.advocacy
Subject: Re: illegal mac emulation
From: <CTLCC@CUNYVM.BITNET>
Date: Monday, 28 Dec 1992 00:46:31 EST
Organization: City University of New York/ University Computer Center

The bad part about emplant is that you use a copy of the roms and not the roms
themselves. So most Amiga users are pirating the roms.  As for the Emplant.
The price on it is about $250.00. It works with Amiga 2xxx,3xxx and 4xxx.
It also works in color. So it is a threat.
Newsgroups: comp.sys.mac.advocacy
From: pbrowne@micor.ocunix.on.ca (Pat Browne)
Subject: Unix Xdump (xwd) to Mac Converter
Organization: M.B. Cormier INC., Orleans (Ont)
Date: Wed, 30 Dec 1992 04:28:32 GMT

Greetings

We require  a procedure (or program ) that will allow us to convert a file
produced by an X-Window "xwd" command (on an HP-9000) platform to "pict"
format such that it can be used by any Macintosh program. This is being used
to prepare a user manual which requries snapshots of the various windows used
by the application.
Any code or information would be appreciated.
Thanks in advance

V. Adomaitis/P. Browne

-----------------------------------------------------------------------------
pbrowne (Pat Browne)
pbrowne@micor.ocunix.on.ca

Ottawa Ontario, Canada
-- 
-----------------------------------------------------------------------------
pbrowne (Pat Browne)
pbrowne@micor.ocunix.on.ca
From: soubyran@ERE.UMontreal.CA (Soubyran Richard)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Performance tests...
Date: 25 Dec 92 18:01:06 GMT
Organization: Universite de Montreal


Hello!

We are December 25th... and here I am on my computer... forgetting
about wife and kids... but I think it is important for me!!!

I have read in the THINK Pascal oop Manual (page 24) that oop is
not really suited for highly algorithmic applications... It is not
suited for computational programs... Is there anyone that could
post performance tests comparing oop pascal and procedural pascal
for a (moderated) highly computational program? What about C
compared to Pascal? What about oop C compared to oop Pascal?

I thank you all in advance for the answers and I wish you ALL a
Merry XMas and a great new Year with alll the best you want!

Richard Soubyran
soubyran@alize.ere.umontreal.ca
From: SW0169@AppleLink.Apple.COM (Cross Software,Helsingborg,SE,IDV)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Happy New OODLing...
Date: 30 Dec 92 17:10:00 GMT
Organization: AppleLink Gateway

HAPPY NEW YEAR
all great colleagues!
 
...and a happy OODLing 1993!
 
Bo Klintberg, Cross Software AB
From: RSD@AppleLink.Apple.COM (Research SW Design, D Goldman,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Takeover - QA
Date: 4 Jan 93 00:14:00 GMT
Organization: AppleLink Gateway

We are ALL familiar with small and "obvious" bug fixes that end up with
horrendous side effects elsewhere.
 
Nevertheless, I think that Bernadette and others are WAY off-base to conclude
that ALL bug fixes require 8 person-weeks of multiplatform testing before
release.
 
In my "TEditText Bug" message I gave a very specific example of a very concrete
bug. I also presented the English-language version of a very specific one-line
fix.
 
 
In this particular case, I suggested that an EditText should set a particular
field of its floating TEView when the latter is created. Please note the
following:
 
1) The floating TEView is used ONLY by TEditText. Anything you do to the
fPreferOutline field of the floating TEView is GUARANTEED to not have distant
side-effects.
 
2) There is only ONE floating TEView at a time. Anything you do to it will only
affect the CURRENT edit-text field. This is GUARANTEED.
 
3) There is only ONE place where the floating TEView is ever installed. This is
the only place where this bug needs to be fixed.
 
4) My proposed change affects only on-screen appearance. It cannot POSSIBLY
cause a crash or any other unexpected behaviors.
 
 
If one of the above statements is incorrect, please tell me and I will shut up.
If not, though, I stand by my assertion that this is a perfect example of a bug
fix that can be verified "by sight".
 
-- Dave Goldman
   Research Software Design
 
Newsgroups: comp.sys.mac.oop.macapp3
From: misra@fsg.com (Mark Israel - Fusion Boston)
Subject: Re: Bedrock News
Organization: Fusion Systems Group, Inc.
Date: Mon, 21 Dec 1992 14:45:26 GMT

Any news on beta testing Bedrock?  I would love to get may hands on a copy to
test out for several clients.  Many have large installed base of mostly Macs a
few with a 40/40/20 split (PC/Mac/Workstation).

I myself have used MacApp and Borlands OWL as well as Mircosofts MFC.  MacApp
is the best thing going.

Mark.
-- 
---------------------------------------------------------------------------
Mark A. Israel
Fusion Sytems Group
misra@fsg.com        Voice: (617) 542-6130      FAX: (617) 542-6248
From: D6431@AppleLink.Apple.COM (OptImage Interactive Svcs,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: AppleEvent source for MacApp
Date: 22 Dec 92 17:46:00 GMT
Organization: AppleLink Gateway

Hello
 
I'm trying to get my MacApp Application to respond to apple events.  Does
anyone know of a sample app (with source code) that is  written in MacApp that
does simple apple event handling??  I have access to apple link and the
developer CDs. Or could you send it to me if you have something.  The official
documentation is weak.  I know how to process regular apple events in C but not
in MacApp.
 
Thanx
 
Jay Bartot
 
Newsgroups: comp.sys.mac.oop.macapp3
From: bcohen@scherzo.mentorg.com (Speaker-to-Managers)
Subject: Re: Apple support for cfront 3.0 ??
Date: Tue, 29 Dec 1992 22:31:52 GMT
Organization: ElectroPolitical Engineering Enterprises
Keywords: 
Followup-To: 

In article <ksand-011292181712@wintermute.apple.com> Kent Sandvik,
> ksand@apple.com writes:
> >That is the case, and we presented the compiler at this year's
> >WWDC conference. I can't say 100% about the feature set, because
> >it depends on what we and Lucid provides to the final product. However
> >I'm optimistic about templates, less about exception handling.
> 

Um ... before you write off a Cfront 3.0 stopgap, remember that

a) the definition of exception handling has only just settled down, and
   will probably unsettle again as soon as there's an implementation to
   find problems with (and Cfront 3.0 does NOT have exceptions; that's
   for Cfront 4.0, so that's not a differentiating factor)

b) The definition of templates is in the process of changing (i.e. the
   ANSI standards committee has started to discuss modifying the current
   definition in the working document, which is what's in 3.0 and any
   other existing implementations).  Granted. Lucid has good
   representation on the committee (take a bow, Jerry), but there's sure
   to be some concern about the tradeoff between schedules and waiting
   for the consensus of the committee.
------------------------------------------------------------------------
Bruce Cohen, Mentor Graphics Corpooration | email: Bruce_Cohen@mentorg.com
8005 SW Boeckman Road                     | phone: (503)685-1808
Wilsonville, OR 97070-7777                |
From: V0645@AppleLink.Apple.COM (Tandem, Gary Campbell,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Seasons Greetings
Date: 24 Dec 92 01:52:00 GMT
Organization: AppleLink Gateway

Seasons greetings to all MacApp'ers,
 
Thanks for the, help, the conversation, the ideas and may you
have a happy new year.
 
 
cheers,
Gary Campbell
V0645
Tandem Computers
From: SIGMUND@NORA.HD.UIB.NO
Newsgroups: comp.sys.mac.oop.macapp3
Subject: TWindow, a problem and a bug
Date: 1 Jan 93 20:30:00 GMT
Organization: AppleLink Gateway

From: sigmund@nora.hd.uib.no
To: MACAPP3TECH$@applelink.apple.com
Cc: achiqui@roman.uib.no
 
Dear MacAppers,
 
Working with multiple monitors connected has revealed a problem with MacApp
3.0.1 and also what I believe are a couple of bugs.
 
The problem:
 
Members of TWindow: Center and Zoom, are two large functions that call
this->GetMaxIntersectedDevice.  That means they are hardcoded to be
directed to the device that has the largest area in common with the window.
 One of my windows needs to be directed towards the device with a video
board connected, and we can imagine occasions where a window should be
directed to the deepest device, or the main device.
 
It would be better if there was a "GetPreferredDevice" function that Center
and Zoom would call instead.  TWindow::GetPreferredDevice could simply call
GetMaxIntersectedDevice, and subclasses could call something else.
 
The first bug:
 
TWindow::Center doesn't work if GetMaxIntersectedDevice returns any other
device than the main screen.  As theFrame is calculated, Center only pays
attention to the device's size, not its position.  As a result the window
is placed on the main device, in a position where it would have been
centered on the correct device.
 
The second bug:
 
TWindow::Center doesn't really trust GetMaxIntersectedDevice to account for
menubar and adds GetMBarHeight to theFrame.top.  This compensates for bug
#1 when dealing with the main device, but when bug #1 is corrected, the
window will be placed 20 pixels (at least here in Norway) too low on any
device.
 
I would suggest the following fix to both bugs in TWindow::Center, where
theFrame.top and theFrame.left are calculated.
 
Take this:
 
if (horizontally)
    theFrame.left = (screenSize.h - contentSize.h + fContentRegionInset.h)
/ 2;
if (forDialog)
    // Put it in the top third of the screen
    theFrame.top = ((screenSize.v - contentSize.v + fContentRegionInset.v)
/ 3)
                                                          +
GetMBarHeight();
else if (vertically)
    theFrame.top = ((screenSize.v - contentSize.v + fContentRegionInset.v)
/ 2)
                                                          +
GetMBarHeight();
 
And change to this:
 
if (horizontally)
    theFrame.left = (screenSize.h - contentSize.h + fContentRegionInset.h)
/ 2
                                                          +
screenRect.left;
if (forDialog)
    // Put it in the top third of the screen
    theFrame.top = (screenSize.v - contentSize.v + fContentRegionInset.v) /
3
                                                          + screenRect.top;
else if (vertically)
    theFrame.top = (screenSize.v - contentSize.v + fContentRegionInset.v) /
2
                                                          + screenRect.top;
 
 
This works for me, but please correct me if I am wrong or if anybody has a
better solution.
 
        Regards,
        Sigmund Tveit
        Humanistisk Datasenter
        Norway
From: BISHOP.ANTR@AppleLink.Apple.COM (Antrim Corp, John Bishop,APD)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: TPopup not drawing properl
Date: 30 Dec 92 23:55:00 GMT
Organization: AppleLink Gateway

Ken:
 
Boy - if you get an answer to this popup question, you're my hero.  Please see
the MacApp Development discussion on ALink concerning this problem.  Several
have tried to get an answer to this and it's just died in the MacAppTech
archives.  I tried again last month, and have no answer yet.
 
There are several problems with TPopups that I understand better, like making
sure that the same popup in two windows must have unique Menu ID's, contructed
on the fly, even when their originating resource is the same (like two
different windows with a "FontSize" popup).  If the popups are dynamic (change
programmatically), you must override any of TPopups methods which count on the
resource ID and Menu ID to be identical - not a simple task.  Further, unless
you want MacApp to mess with your popups, you must give them Menu ID's outside
of MacApp's "service" range - that is, greater than 64.  Finally, when you're
all done, you have to figure out why you can't control the graying (or
ungraying) of the popups properly.  I have no philisophical problem with a
popup in the background going gray, just that redrawing it should make it black
(ie: on activation).  I have exhausted myself trying to force redrawing at the
proper times, and like you, have found myself at the Toolbox call, still
drawing incorrectly.  Many months ago, Chris Knepper (at Apple, I think)
indicated lots of problems with TPopup in MacApp (bugs he called them) and
indicated they wouldn't be fixed and had to be worked around...  Well, I've
been trying to "work around" these problems for months to no avail.  Makes me
think I should get out my Borland Frameworks and spend my time on Combo Boxes!!
 
Anyway, if you get a better response than I did, please pass my link address
along so I can get some help.  They call me "Mr. Popup" around here... sounds a
lot like "Mr. Potato Head" to me.
 
John Bishop
Antrim Corporation
From: ksand@apple.com (Kent Sandvik )
Subject: Re: Galaxy?
Date: Mon, 28 Dec 1992 00:07:03 GMT
Organization: (Evil Eye Creature from Mars, Inc.)
Followup-To: comp.sys.mac.oop.macapp3

In article <1992Dec27.060847.7998@netcom.com>, knee@netcom.com (Mark
Lanett) wrote:
> 
> ALGER@AppleLink.Apple.COM (Alger, Jeff,VCA) writes:
> 
> >Fellow OOPers,
> > 
> >This is getting pretty confusing: Bedrock, Component Workshop, Dylan, OOPC,
> >Camelot, Galaxy, CLOS, Smalltalk (the language that refuses to die!), and who
> 
> Hmmm. New-framework-of-the-week month it seems. What's Galaxy?

Hehehe, and what about the Mac port of Garnet? And what about other
interesting announcements at next year's MADACon? I agree, this will
become a year of frameworks wars, and that's good because competition
will (as evolution :-)) produce better species, sorry, frameworks.

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
Newsgroups: comp.sys.mac.oop.macapp3
From: samk@microsoft.com (Sam Kho)
Subject: Re: Re2: Bedrock News
Date: 23 Dec 92 10:20:30 GMT
Organization: Microsoft Corporation

In article <9212181621.AA26899@odin.mda.uth.tmc.edu> DRAPER@ODIN.MDA.UTH.TMC.EDU writes:
>>I think the comments about what the
>>development environment ought to be are pointing right to Component Workshop.
>>I've seen it demonstrated, and it seems to be frialy immature, but with amaz
>ing
>>potential.  I hope it gets the market it deserves.
> 
>I'm very interested in Component Workshop.  Could you (or someone else
>perhaps) elaborate on its content and structure.  They (the people who
>wrote it) claim that it's very similar to MacApp.  Is anyone out there
>using it?
> 

who makes CW?

  - sam -
From: JOLICOEUR.B@AppleLink.Apple.COM (Jolicoeur, Bernadette)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: * Takeover Proposal *
Date: 22 Dec 92 01:42:00 GMT
Organization: AppleLink Gateway

I have been sitting here the last few days, in silence, reading the links that
have been "flying" across the net concerning Bedrock.  There has been alot of
"interesting" information and misinformation.  I think that you can expect to
see an "official" response sometime soon.  What I do feel qualified to comment
on is the Apple commitment to the Bedrock project.
 
> Questions about WHICH former MacApp creators are helping create Bedrock. (All
> of the names I recognize from the past 3 years of MacAppTech$ and MADA
> conference reports now have "Taligent" in their e-mail addresses, not
> "Symantec".)
 
Currently, there are eight Apple employees working on the Bedrock project at
Symantec.  Seven of these people, including Lonnie Millet and myself, worked on
MacApp 3.0 and 3.0.1.  Additionally, there is a team at Apple that is
addressing current MacApp concerns and transition strategies.  DTS and
Developer University also have dedicated MacApp/Bedrock resources.
 
Just my opinion (sprinkled with some facts),
Bernadette Jolicoeur
Bedrock SQA Manager
From: DEWAELE.W@AppleLink.Apple.COM (De Waele Willy - Gent,BE,IHD)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Re: Descendent in another unit
Date: 3 Jan 93 13:46:00 GMT
Organization: AppleLink Gateway

Hi Bill,
 
First at all ... Happy NewYear to you and all MacAppers ...
 
I had the same problem some time ago and submitted it to the group on 26 sep 92
and was discussed until 30 sep 92. Perhaps it is on ETO #9, if not i can
include it as an enclosure.
 
And reading the answers from Jeff Barbose i think you have a "Circular
References", if you got the msg *basic class TFooA not found*.
I found only uno solution: the 2 classes in the smame .h file.
 
Regards,
Willy
From: MADA@AppleLink.Apple.COM (MADA Admin, Steve Mann,PAS)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: RE: FrameWorks Wars & MADACON
Date: 24 Dec 92 22:55:00 GMT
Organization: AppleLink Gateway

Jeff:
 
We've already got something in the works along the lines of what you suggest
for MADACON '93.
 
You (and everyone else out there) could help out by submitting a list of
critical questions you would like answered, or topics you would like addressed,
a list that can be covered by six or more vendors in a 2-3 hour session and
still allow "plenty of time for Q&A."
 
Steve Mann
From: RSD@AppleLink.Apple.COM (Research SW Design, D Goldman,PRT)
Newsgroups: comp.sys.mac.oop.macapp3
Subject: Takeover - Scope
Date: 4 Jan 93 00:12:00 GMT
Organization: AppleLink Gateway


 
----------------------------------------------------------------------------
An organization capable of supporting MacApp
properly would have to include at a bare minimum two programmers (one only and
you are at the whim of sickness, vacation, and the attractions of greener
pastures elsewhere), one documentation person, one QA person (two would be
better) and at least one full-time manager (better two, one technical and one
business).  And this is bare bones; it assumes, among other things, that tech
support is provided by the programmers, QA, and documentation folks; that
secretarial & etc. are part of some existing business structure; and that
training is provided by third parties.
----------------------------------------------------------------------------
 
Jeff --
 
Your idea of "supporting MacApp properly" is NOT AT ALL what I proposed in my
original message of this branching thread. What I DID propose was:
 
    I'm *not* proposing that MADA create MacApp 4.0. But wouldn't it be
    nice if there were SOMEBODY reviewing all of the bug reports and
    discussions on MacAppTech$ who would then actually change the MacApp
    source code accordingly?
 
Now, on a separate branch of this thread there is a discussion of how much
effort is needed to make a bug fix to MacApp. But if one accepts for a moment
that SOME percentage of bug fixes can be installed by a competent programmer --
working in conjunction with all of the developers on MacAppTech$ [why do all of
these discussions insist that all bug work and QA needs to be done in a
vacuum???] -- then to accomplish what I did propose would require a programmer.
Two, if you prefer. Period.
 
No documentation person. We're fixing bugs here, not creating a new system.
 
No separate QA people. That's the bulk of the programmer's job: take a bug-fix
already worked out on MacAppTech$ (or in Apple's existing bug doc!) and study
and test it. Put up a proposed fix on MacAppTech$ and let other brave souls try
it out. Put it on the next CD as a beta version.
 
No separate tech support function. If tech support means a place to get your
questions answered, the best place is currently MacAppTech$. If tech support
means a place to get MacApp bugs fixed, then we do not have any official tech
support at present.
 
No manager.
 
I agree that secretarial support comes from the existing structure, and that
training is not an issue.
 
 
Somebody used the phrase "keeping MacApp on life-support". That's what I'm
after. Right now the patient is bleeding from many small wounds, and Apple's
best response is to offer us periodic updates of a first aid manual (the Bug
Doc). And assure us that a healthier patient will be coming next year, along
with better health insurance (from a third party payer).
 
Why not transfer our current patient to a nurse who can read the first aid
manual and actually apply a few bandages?
 
-- Dave Goldman
   Research Software Design